And more generally, if one wishes to obtain P{X>x} for many other points x then integration is not necessary at each of them. One may instead compute a symbolic integral just once, to obtain a function of x, or simply use the CDF as Doug pointed out. And it may also be done for (as yet) unknown mean and variance.

> with( Statistics ):

> X := RandomVariable( Normal(m,s) ):

> PXms := int( PDF(X,t), t=x..infinity )
>   assuming m>0, m<infinity, s>0, s<infinity;
                                      1/2
                                     2    (-x + m)
                     PXms := 1/2 erf(-------------) + 1/2
                                          2 s

> Px := unapply(eval(PXms,[m=3,s=3]),x);
                                          1/2
                  Px := x -> 1/2 erf(1/6 2    (-x + 3)) + 1/2
 
> evalf(Px(0));
                                 0.8413447460

And, of course, this is the same as what one gets from the CDF,

> X := RandomVariable( Normal(m,s) ):

> 1-CDF(X,x);
                                        1/2
                                       2    (-x + m)
                         1/2 + 1/2 erf(-------------)
                                            2 s

acer

That reply is much more useful and instructive for the student.

There could be more pedagogical difference between VectorCalculus:-ArcLength and Student:-VectorCalculus:-ArcLength.

acer

That reply is much more useful and instructive for the student.

There could be more pedagogical difference between VectorCalculus:-ArcLength and Student:-VectorCalculus:-ArcLength.

acer

I would probably do it like this,

> F:=proc(L)
>   subsop(1=NULL,L);
> end proc:
> L:=[x,y,z,d];
                               L := [x, y, z, d]
 
> L:= F(L);
                                L := [y, z, d]
 
> L:= F(L);
                                  L := [z, d]
 
> L:= F(L);
                                   L := [d]
 
> L:= F(L);
                                    L := []

That keeps it as simple as possible, is easiest to understand, and is less confusing.

Doing it the other way, to bring about the change in L as a so-called side-effect on the name, can cause confusion. In a sense, it's deliberately subverting any protection Maple may otherwise give you about not having your procedure overwrite the formal parameter. As a general rule, you may not wish to do that unless it's necessary. For your example, the above way to overwrite L (explicitly, by the call to the proc) is more straightforward.

Way back in the day, before Maple allowed multiple assignments, some routines would use side-effects as a mechanism to fake multiple assignment. For example,

> f := proc(a,b)
>   b := 2*a;
>   3*a;
> end proc:

> x:=11:

> x := f(x,'y'):
> x,y;
                                    33, 22
 
> x := f(x,'y'):
> x,y;
                                    99, 66

The above procedure changes both x and y. There was a time, long ago, when that was one of the easier ways to do get that effect. Nowadays, it can be done much more simply with a multiple assignment,

> restart:

> f := proc(a)
>  3*a, 2*a;
> end proc:

> x:=11:

> x,y := f(x);
                                x, y := 33, 22
 
> x,y := f(x);
                                x, y := 99, 66

When using side effects, one can get confused the by quotes, by either forgetting them or inserting them when they are not wanted.

> restart:

> f := proc(a,b)
>   b := 2*a;
>   3*a;
> end proc:

> x:=11:

> x := f(11,y): # it works once, without quotes...
> x,y;
                                    33, 22
 
> x := f(11,y): # and now, the second time...
Error, (in f) illegal use of a formal parameter

And, doing it another way,

> f := proc(x::evaln)
>   x := 2*eval(x);
> end proc:

> x:=11:

> f(x):
> x;
                                      22
 
> f('x'):
Error, illegal use of an object as a name

And also, documenting its use for others is more involved if it's implemented in these ways.

acer

I would probably do it like this,

> F:=proc(L)
>   subsop(1=NULL,L);
> end proc:
> L:=[x,y,z,d];
                               L := [x, y, z, d]
 
> L:= F(L);
                                L := [y, z, d]
 
> L:= F(L);
                                  L := [z, d]
 
> L:= F(L);
                                   L := [d]
 
> L:= F(L);
                                    L := []

That keeps it as simple as possible, is easiest to understand, and is less confusing.

Doing it the other way, to bring about the change in L as a so-called side-effect on the name, can cause confusion. In a sense, it's deliberately subverting any protection Maple may otherwise give you about not having your procedure overwrite the formal parameter. As a general rule, you may not wish to do that unless it's necessary. For your example, the above way to overwrite L (explicitly, by the call to the proc) is more straightforward.

Way back in the day, before Maple allowed multiple assignments, some routines would use side-effects as a mechanism to fake multiple assignment. For example,

> f := proc(a,b)
>   b := 2*a;
>   3*a;
> end proc:

> x:=11:

> x := f(x,'y'):
> x,y;
                                    33, 22
 
> x := f(x,'y'):
> x,y;
                                    99, 66

The above procedure changes both x and y. There was a time, long ago, when that was one of the easier ways to do get that effect. Nowadays, it can be done much more simply with a multiple assignment,

> restart:

> f := proc(a)
>  3*a, 2*a;
> end proc:

> x:=11:

> x,y := f(x);
                                x, y := 33, 22
 
> x,y := f(x);
                                x, y := 99, 66

When using side effects, one can get confused the by quotes, by either forgetting them or inserting them when they are not wanted.

> restart:

> f := proc(a,b)
>   b := 2*a;
>   3*a;
> end proc:

> x:=11:

> x := f(11,y): # it works once, without quotes...
> x,y;
                                    33, 22
 
> x := f(11,y): # and now, the second time...
Error, (in f) illegal use of a formal parameter

And, doing it another way,

> f := proc(x::evaln)
>   x := 2*eval(x);
> end proc:

> x:=11:

> f(x):
> x;
                                      22
 
> f('x'):
Error, illegal use of an object as a name

And also, documenting its use for others is more involved if it's implemented in these ways.

acer

I disagree with most of what you've written. And that's OK with me.

The bit that sticks out most is the claim that the syntax if A=B then... could get a quite different new set of meanings and that this might not break a lot of existing users' code and worksheets.

acer

I disagree with most of what you've written. And that's OK with me.

The bit that sticks out most is the claim that the syntax if A=B then... could get a quite different new set of meanings and that this might not break a lot of existing users' code and worksheets.

acer

On the one hand, there is the question of consistency. What you describe would mean that the behaviour of if A=B then... would differ much more dramatically according to the types of objects A and B. To me, that would be more inconsistent.

And what else might follow logically, to accompany this? If `=`, then why not `<`, to strive for at least some consistency? That too can be taken as "mathematical", just like Matrix arithmetic. Should these next two behave the same?

> restart:
> assume(a>b):
> if a>b then boo else foo end if;
Error, cannot determine if this expression is true or false: b < a
> if is(a>b) then boo else foo end if;
                                      boo

And, how about automatic normalization or simplification? The following is just as "mathematical" as Matrix arithmetic, no? Should these behave the same?

> if sin(x)^2+cos(x)^2 = 1 then boo else foo end if;
                                      foo
 
> if simplify(sin(x)^2+cos(x)^2) = 1 then boo else foo end if;
                                      boo

If mathematical simplification were also handled by default in if A=B then..., then there'd have to also be a syntax to deliberately avoid it.

And, doesn't it matter that the proposal is backwards incompatible and would break a lot of users' previously authored code? I'm pretty sure that the change couldn't be accommodated by an automatic code-updating script. There are just too many strange ways to get a Matrix into a symbol -- the script would have a terrible time trying to figure out which instances of if A=B then... should be changed to the new identity-check for Matrices.

To me, implementing the suggested alternative would introduce arbitrariness and inconsistency, would slow Maple down, and would constitute major code backwards incompatibility.

I don't think that Maple's current behaviour is so bad. But parts of it could be documented much more clearly and comprehensively.

acer

On the one hand, there is the question of consistency. What you describe would mean that the behaviour of if A=B then... would differ much more dramatically according to the types of objects A and B. To me, that would be more inconsistent.

And what else might follow logically, to accompany this? If `=`, then why not `<`, to strive for at least some consistency? That too can be taken as "mathematical", just like Matrix arithmetic. Should these next two behave the same?

> restart:
> assume(a>b):
> if a>b then boo else foo end if;
Error, cannot determine if this expression is true or false: b < a
> if is(a>b) then boo else foo end if;
                                      boo

And, how about automatic normalization or simplification? The following is just as "mathematical" as Matrix arithmetic, no? Should these behave the same?

> if sin(x)^2+cos(x)^2 = 1 then boo else foo end if;
                                      foo
 
> if simplify(sin(x)^2+cos(x)^2) = 1 then boo else foo end if;
                                      boo

If mathematical simplification were also handled by default in if A=B then..., then there'd have to also be a syntax to deliberately avoid it.

And, doesn't it matter that the proposal is backwards incompatible and would break a lot of users' previously authored code? I'm pretty sure that the change couldn't be accommodated by an automatic code-updating script. There are just too many strange ways to get a Matrix into a symbol -- the script would have a terrible time trying to figure out which instances of if A=B then... should be changed to the new identity-check for Matrices.

To me, implementing the suggested alternative would introduce arbitrariness and inconsistency, would slow Maple down, and would constitute major code backwards incompatibility.

I don't think that Maple's current behaviour is so bad. But parts of it could be documented much more clearly and comprehensively.

acer

According to the original post, he apparently wants,

> S(X);
                            proc() 'X'[1] end proc

Presumably, that really is what he is after.

That won't happen for the S above. But with a few uneval quotes like in subs(K=''Y'',eval(T)) it could. Then it might be a question of whether he'd rather define it as proc(Y::uneval)... or as proc(Y::evaln)...

acer

According to the original post, he apparently wants,

> S(X);
                            proc() 'X'[1] end proc

Presumably, that really is what he is after.

That won't happen for the S above. But with a few uneval quotes like in subs(K=''Y'',eval(T)) it could. Then it might be a question of whether he'd rather define it as proc(Y::uneval)... or as proc(Y::evaln)...

acer

An excellent choice.

acer

The idea is that it's not necessary to reach and fix all the tutorials, to make an effect here. Not even most. Just some. The most "popular" ones, by google ranking, say. The one's which come up in the first 5 pages of google search results, say, would be a decent start.

Suggesting that all such tutorials in the world be edited, by anyone, would be a crazy idea. I wasn't suggesting that at all.

acer

The matrix/vector objects have last-name-eval, while Matrix/Vector objects do not. I don't see how this difference could not cause serious and possibly insurmountable difficulties in a wrapper approach.

It's also not just that people shouldn't use linalg because it's old syntax. It's also more awkward syntax. The idea is to show them the nicer, cleaner syntaxes. Wrapper approaches perpetuate things which are not pretty (LNE, evalm, `&*`, etc).

acer

I meant that Maplesoft might consider doing it. The tutorials, in particular, are mostly very elementary.

Of course, I do not know how many there are out there. But things get ranked in google for concrete reasons. The more high ranked linalg tutorials that get replaced with LinearAlgebra equivalents, then the better the first search results would become on average.

I just think that eight out of ten, as google search results pointing to the wrong packages, is a sign that some new action should be considered.

acer