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

Yes, that was one of my points. If the universities/colleges have not taken the time to update their tutorials, then someone could (likely, relatively easily) do it for them.

acer

Interesting.

With the menu-driven Postscript exporter in Classic, `-p/2` produces plusminus Pi/2 when using the SYMBOL font, but works OK and produces -Pi/2 with the programmatic exporter. But `-3p/2` produces plusminus in both.

A curious bug. I'm glad that adding a space after the minus sign was some sort of workaround.

acer

Interesting.

With the menu-driven Postscript exporter in Classic, `-p/2` produces plusminus Pi/2 when using the SYMBOL font, but works OK and produces -Pi/2 with the programmatic exporter. But `-3p/2` produces plusminus in both.

A curious bug. I'm glad that adding a space after the minus sign was some sort of workaround.

acer

You're very welcome. You caught the fact that when using the plotsetup command  (to specify the "ps" driver) the extra space after the minus sign may not be necessary, yes?

My first try would be to use Maple's Standard interface. Robert Israel's reply seemed nice (as usual).

I didn't see where you might have written why you prefer to use Classic over Standard. I use Standard with Worksheets instead of Documents, and 1D Maple input instead of 2D Math input (as the global defaults for all new sessions, configurable under the Options menus) when I want to use a GUI.

acer

You're very welcome. You caught the fact that when using the plotsetup command  (to specify the "ps" driver) the extra space after the minus sign may not be necessary, yes?

My first try would be to use Maple's Standard interface. Robert Israel's reply seemed nice (as usual).

I didn't see where you might have written why you prefer to use Classic over Standard. I use Standard with Worksheets instead of Documents, and 1D Maple input instead of 2D Math input (as the global defaults for all new sessions, configurable under the Options menus) when I want to use a GUI.

acer