Clearly it cannot be the case that, "the probability would be 100% that the last student will sit in his own seat."

That's because the set of all possible seatings is finite and, with the given restrictions and scenario, it includes some seatings where the last student finds that his seat is already taken.

Clearly it cannot be the case that, "the probability would be 100% that the last student will sit in his own seat."

That's because the set of all possible seatings is finite and, with the given restrictions and scenario, it includes some seatings where the last student finds that his seat is already taken.

It the definition of `rect` is omitted after your restart.

> rect:=t->Heaviside(t+1/2)-Heaviside(t-1/2):

It the definition of `rect` is omitted after your restart.

> rect:=t->Heaviside(t+1/2)-Heaviside(t-1/2):

In your first example, you set up i1 as an operator. In that case, when you call i1(omega) things make sense. Also, i1 is real valued, and its floating-point evaluation produces a near-zero imaginary component in the range omega=-15..15.

> rect:=t->Heaviside(t+1/2)-Heaviside(t-1/2):

> i1:=omega->int(rect(t)*exp(-I*omega*t),t=-infinity..infinity):

> simplify(i1(omega)) assuming omega::real;
                                       omega
                                 2 sin(-----)
                                         2
                                 ------------
                                    omega

You can plot i1 successfully with these alternative commands.

plot(i1(omega), omega=-15..15);  # expression syntax

plot(i1, -15..15);  # operator syntax

plot('i1'(omega), omega=-15..15);  # delayed operator syntax

Now let's move on to your second example. You wrote it as follows.

> i1:=int(rect(t-1)*exp(-I*omega*t),t=-infinity..infinity);
                       exp(-1/2 I omega) I   exp(-3/2 I omega) I
               i1 := - ------------------- + -------------------
                              omega                 omega

In this case you didn't make i1 an operator. It's an expression. So you got into trouble when you invoked it as i1(omega), as if it were an operator, since that returned something not valid for your purpose.

Now, you might still try and plot this i1 expression, using the expression syntax for plot. But unfortunately, with rect(t-1) the result is not purely real. You can plot its real and its imaginary components separately.

plot(Re(i1), omega=-15..15);

plot(Im(i1), omega=-15..15);

Hope that helps some.

In your first example, you set up i1 as an operator. In that case, when you call i1(omega) things make sense. Also, i1 is real valued, and its floating-point evaluation produces a near-zero imaginary component in the range omega=-15..15.

> rect:=t->Heaviside(t+1/2)-Heaviside(t-1/2):

> i1:=omega->int(rect(t)*exp(-I*omega*t),t=-infinity..infinity):

> simplify(i1(omega)) assuming omega::real;
                                       omega
                                 2 sin(-----)
                                         2
                                 ------------
                                    omega

You can plot i1 successfully with these alternative commands.

plot(i1(omega), omega=-15..15);  # expression syntax

plot(i1, -15..15);  # operator syntax

plot('i1'(omega), omega=-15..15);  # delayed operator syntax

Now let's move on to your second example. You wrote it as follows.

> i1:=int(rect(t-1)*exp(-I*omega*t),t=-infinity..infinity);
                       exp(-1/2 I omega) I   exp(-3/2 I omega) I
               i1 := - ------------------- + -------------------
                              omega                 omega

In this case you didn't make i1 an operator. It's an expression. So you got into trouble when you invoked it as i1(omega), as if it were an operator, since that returned something not valid for your purpose.

Now, you might still try and plot this i1 expression, using the expression syntax for plot. But unfortunately, with rect(t-1) the result is not purely real. You can plot its real and its imaginary components separately.

plot(Re(i1), omega=-15..15);

plot(Im(i1), omega=-15..15);

Hope that helps some.

I'm referring to the "flag this" link that appears at the bottom of replies. It sits next to the "reply" link, and it appears to be a way to flag spam for the admin to see. I'd noticed that main forum posts and blog entries do not seem to have such "flag this" links.

Could you post the code, or upload it to this site using the green arrow above the editing box? That might be the easiest way to get the problem sorted.

You did quote 'procname', yes? Without quoting it, it would actually call itself over (and over...) instead of returning unevaluated.

Could you post the code, or upload it to this site using the green arrow above the editing box? That might be the easiest way to get the problem sorted.

You did quote 'procname', yes? Without quoting it, it would actually call itself over (and over...) instead of returning unevaluated.

Ah, you've surmised that the xxx in d<xxx is an element of argument w. That would generate an error about a missing argument, before making a complaint about being unable to figure out the inequality.

Maybe both bits need fixing, since he did invoke evalf(Int(F(1,2,3,d),d=1..2)) where F(1,2,3,d) will be evaluated up front. The other common workaround would be to call it as evalf(Int('F'(1,2,3,d),d=1..2)) in lieu of the 'procname' return.

I didn't mention it above, but in general it'd be better to have the outer proc (here, F)  be the one which returned unevaluated for nonnumeric arguments. In general, the outer proc might prematurely return the wrong "inner call" when supplied the symbolic arguments, so you'd want to guard against that.

Ah, you've surmised that the xxx in d<xxx is an element of argument w. That would generate an error about a missing argument, before making a complaint about being unable to figure out the inequality.

Maybe both bits need fixing, since he did invoke evalf(Int(F(1,2,3,d),d=1..2)) where F(1,2,3,d) will be evaluated up front. The other common workaround would be to call it as evalf(Int('F'(1,2,3,d),d=1..2)) in lieu of the 'procname' return.

I didn't mention it above, but in general it'd be better to have the outer proc (here, F)  be the one which returned unevaluated for nonnumeric arguments. In general, the outer proc might prematurely return the wrong "inner call" when supplied the symbolic arguments, so you'd want to guard against that.

> sol:=fsolve({x+y,x-cos(y)},{x,y});
                 sol := {x = 0.7390851332, y = -0.7390851332}

> usex := eval(x,sol);
                             usex := 0.7390851332

> x;
                                       x

> usex;
                                 0.7390851332

> usex, usey := eval(x,sol), eval(y,sol);
                   usex, usey := 0.7390851332, -0.7390851332

> x, y;
                                     x, y

> usex, usey;
                          0.7390851332, -0.7390851332

Try MultiSeries:-series() instead of series().

Try MultiSeries:-series() instead of series().

The gods giveth, and they take away.