Thanks for clarifying, Robert.

My principal concern with the shortcut function definition is however on the legibility side, rather than on ease of construction. If one creates such an object, then which underlying structure the 2D Math display represents (or is intended to parse as) may not be readily distiguishable by others who view or run it.

I may be trying it wrong, but I don't see how to preserve the choice, when saving to a .mw file. If I save, quit the GUI, relaunch and load the Document, then when running it the query is once again asked. (But, even if it were able to save the parsed meaning, I'd still much prefer a language where the parse meaning were always immediately visibly discernable without conversion to 1D.)

I don't see the Typesetting:-RuleAssistant under the Tools menu. Is the configuration set with it saved in any way, either along with the .mw file or as a global preference? It doesn't appear to be.

acer

The behaviour of the echoing of assigned values is different in Documents and in Worksheets of the Standard GUI. In a Worksheet, the assignments are fully echoed (eg. K:=45 gets displayed).

For the next one, x:=t->5*t^2-5*t, the situation is the same. It is consistent with those stated behaviours for each of those two environments. But look, even in a Worksheet where the full assignment gets echoed it displays as "x:=t->5*t^2-5*t" and not as "x(t)=5*t^2-5*t ". There are at least two things misguided about the suggestion of "x(t)=5*t^2-5*t ".

The first is that it shows an equation and not an assignment. Those are very different in Maple. When people type in an equation then they expect to see one displayed, and vice versa. If both assignments and equations got displayed as equations then there would be a senseless loss of veracity in the display.

A second problem is that it would further extend the unfortunate recent extension of function application syntax to denote a function definition. That's a new (and not well judged) behaviour of Maple, via 2D Math. Until recently, in the (only) 1D Maple language the syntax x(t) meant x applied at t. If x had not previously been assigned then assigning to x(t) would bring about an assignment to the entry t of the remember table of x. But now in the (new) 2D Math Maple language such an assignment can mean either remember table assignment or operator definition. In the 2D Math language, a disambiguation pop-up dialogue box appears when it is typed in, to allow one to choose. But after that, the two different inputs (not outputs) look the same. They print the same, there is no hover-over bubble or other visual cue to distinguish them. Yet those identical-looking inputs evoke very different context-menus, for example, since they are entirely different objects underneath.

Both problems have this in common: they would increase the degree to which displayed 2D Math is not uniquely true to the underlying  parsed meaning. There's  too much of that already in 2D Math, which is why it is not the right choice for writing maple programs of anything but the most simple sort.

I like 2D Math. It is great for using in Documents, hooking up live math content to embedded components, and all of that there. But it's not a good choice for programming. (One could write pages of closely argued points, detailing further why it's not the right choice for programming.) In a Document I'd sooner use the 1D code edit regions new to Maple 13, or use the toolbar's drop-down to choose 1D "Maple Input", or set libname to point to the location of a library file containing previously coded procedures.

acer

You seem to be making good progress.

> eval(y1,x=0);
                                      14
 
> eval(y2,x=0);
                                      -16

acer

You seem to be making good progress.

> eval(y1,x=0);
                                      14
 
> eval(y2,x=0);
                                      -16

acer

Your explanation for 1) doesn't look right.

Look up the definition of y-intercept, then apply separately to each of the equations.

acer

Your explanation for 1) doesn't look right.

Look up the definition of y-intercept, then apply separately to each of the equations.

acer

I get the escaped local `ee`, when running your .mws worksheet in Maple 12.00. That's a software bug. But in Maple 12.01 and Maple 13, the problematic simplify calls appear to work properly.

See here for the 12.02 point-release update, if you are in fact running 12.00.

acer

I get the escaped local `ee`, when running your .mws worksheet in Maple 12.00. That's a software bug. But in Maple 12.01 and Maple 13, the problematic simplify calls appear to work properly.

See here for the 12.02 point-release update, if you are in fact running 12.00.

acer

After assignment is done of a few values to some variables, this command is issued in your worksheet,

phi[2] := convert(SphericalY(lphi, mj+1/2, theta, phi), elementary);

Now, your Document had that in 2D Math input, so phi[2] appeared as typeset phi-subscript-2. But the important thing to notice is that, underneath that 2D Math typesetting, the subscripted object was really phi[2]. And since phi had not previously been assigned, then phi[2] is treated as a table reference.

So, the assignment to phi[2] creates a table phi, where the phi[2] table entry is an expression (radicals and trig) involving the name phi.

Then a repeated attempt is made, to convert that same SphericalY call, where phi is the last argument, to elementary functions. And the error is that too many levels of recursion happened.

Basically, a self-referencing of an entry of table phi to the table itself had been created. Some manipulation of this resulted in an infinite recursion (stopped when an internal limit was exceeded).

If one really needs to use both phi and subscripted phi in the same mathematical subcomputation, then the subscripted phi should be a distinct name and not a table reference. A subscripted but fully unique name can be inserted from the Layout palette, as a "subliteral". Or, a table reference can be converted in-place in the Document to a unique name using the right-click context menu, 2-D Math -> Convert To -> Atomic identifier.

acer

After assignment is done of a few values to some variables, this command is issued in your worksheet,

phi[2] := convert(SphericalY(lphi, mj+1/2, theta, phi), elementary);

Now, your Document had that in 2D Math input, so phi[2] appeared as typeset phi-subscript-2. But the important thing to notice is that, underneath that 2D Math typesetting, the subscripted object was really phi[2]. And since phi had not previously been assigned, then phi[2] is treated as a table reference.

So, the assignment to phi[2] creates a table phi, where the phi[2] table entry is an expression (radicals and trig) involving the name phi.

Then a repeated attempt is made, to convert that same SphericalY call, where phi is the last argument, to elementary functions. And the error is that too many levels of recursion happened.

Basically, a self-referencing of an entry of table phi to the table itself had been created. Some manipulation of this resulted in an infinite recursion (stopped when an internal limit was exceeded).

If one really needs to use both phi and subscripted phi in the same mathematical subcomputation, then the subscripted phi should be a distinct name and not a table reference. A subscripted but fully unique name can be inserted from the Layout palette, as a "subliteral". Or, a table reference can be converted in-place in the Document to a unique name using the right-click context menu, 2-D Math -> Convert To -> Atomic identifier.

acer

There used to be such a publication, named MapleTech. It was published by Birkhauser.

This and this link might help make some sense of it.

It seems like a decent idea, to petition Maplesoft to either resurrect that one, or start a new one.

acer

Both these plots worked for me,

> restart:

> with(plots):
> with(Units[Standard]):

> g2 := piecewise(t>0 and t<100, 10*Unit(m/s^2)*t*Unit(s),
>                 t>=100, 1000*Unit(m/s)-10*Unit(m/s^2)*(t-100)*Unit(s)):

> plot(unapply(g2, t), 0..200*Unit(s));
> plot(unapply(g2, t), 0..200*Unit(s), useunits=[Unit(s),Unit(m/s)]);

> kernelopts(version);
           Maple 13.00, X86 64 LINUX, Feb 18 2009 Build ID 388356

acer

Both these plots worked for me,

> restart:

> with(plots):
> with(Units[Standard]):

> g2 := piecewise(t>0 and t<100, 10*Unit(m/s^2)*t*Unit(s),
>                 t>=100, 1000*Unit(m/s)-10*Unit(m/s^2)*(t-100)*Unit(s)):

> plot(unapply(g2, t), 0..200*Unit(s));
> plot(unapply(g2, t), 0..200*Unit(s), useunits=[Unit(s),Unit(m/s)]);

> kernelopts(version);
           Maple 13.00, X86 64 LINUX, Feb 18 2009 Build ID 388356

acer

Use capitalized Matrix, not lowercase matrix.

acer

Use capitalized Matrix, not lowercase matrix.

acer