I'm a little surprised, if this is what the OP truly wanted. The [2,2] entry of the final result has a factor of (f(x)-y) introduced into the numerator (to balance the power of lambda^2). I would have thought that (f[x]-z)*lambda was the desired result for that entry.

acer

I'm a little surprised, if this is what the OP truly wanted. The [2,2] entry of the final result has a factor of (f(x)-y) introduced into the numerator (to balance the power of lambda^2). I would have thought that (f[x]-z)*lambda was the desired result for that entry.

acer

Sorry if it wasn't clear. When I paste in a call to kernelopts(version) in a post here it is because I am running the code fragment in a particular version of Maple and I wish to illustrate that fact. But I can only do that because I have several old versions installed, and I must run them fully separately.

Running older versions entails having them fully and separately installed. And they require distinct license files.

Also, there is no way to have, say, Maple 13 emulate or use M12's kernel. Even the .mla libraries archives (interpreted code) cannot really be safely or properly run with forwardly or backwardly mismatched kernels.

acer

Sorry if it wasn't clear. When I paste in a call to kernelopts(version) in a post here it is because I am running the code fragment in a particular version of Maple and I wish to illustrate that fact. But I can only do that because I have several old versions installed, and I must run them fully separately.

Running older versions entails having them fully and separately installed. And they require distinct license files.

Also, there is no way to have, say, Maple 13 emulate or use M12's kernel. Even the .mla libraries archives (interpreted code) cannot really be safely or properly run with forwardly or backwardly mismatched kernels.

acer

Actually, no, I believe that LinearAlgebra is superior to linalg in several important respects.

The qualities you describe about unnassigned entries is something that I find myself  wanting only rarely.

acer

Actually, no, I believe that LinearAlgebra is superior to linalg in several important respects.

The qualities you describe about unnassigned entries is something that I find myself  wanting only rarely.

acer

Could you post the problematic example?

> M := matrix(1,2,[y*(f[x]-z)/(f(x)-y),z*(f[x]-z)/(f(x)-y)]):
> simplify(simplify(subs(f[x]=f[X],eval(M)),{(f[X]-z)/(f(x)-y)=lambda}));
                            [lambda y    z lambda]
 
> M := Matrix(1,2,[[y*(f[x]-z)/(f(x)-y),z*(f[x]-z)/(f(x)-y)]]):
> simplify(simplify(subs(f[x]=f[X], M),{(f[X]-z)/(f(x)-y)=lambda}));
                            [lambda y    z lambda]

acer

Could you post the problematic example?

> M := matrix(1,2,[y*(f[x]-z)/(f(x)-y),z*(f[x]-z)/(f(x)-y)]):
> simplify(simplify(subs(f[x]=f[X],eval(M)),{(f[X]-z)/(f(x)-y)=lambda}));
                            [lambda y    z lambda]
 
> M := Matrix(1,2,[[y*(f[x]-z)/(f(x)-y),z*(f[x]-z)/(f(x)-y)]]):
> simplify(simplify(subs(f[x]=f[X], M),{(f[X]-z)/(f(x)-y)=lambda}));
                            [lambda y    z lambda]

acer

That appears to be a regression, from M12 to M13.

> kernelopts(version);
            Maple 12.01, X86 64 LINUX, Sep 23 2008 Build ID 363216
 
> A := y*(f[x]-z)/(f(x)-y):
> simplify(simplify(A,{(f[x]-z)/(f(x)-y)=lambda}));
                                   lambda y

while,

> kernelopts(version);
            Maple 13.00, X86 64 LINUX, Feb 18 2009 Build ID 388356
 
> A := y*(f[x]-z)/(f(x)-y):
> simplify(simplify(A,{(f[x]-z)/(f(x)-y)=lambda}));
Error, (in Groebner:-SuggestVariableOrder) invalid argument
for sign, lcoeff or tcoeff

I will submit an SCR.

acer

That appears to be a regression, from M12 to M13.

> kernelopts(version);
            Maple 12.01, X86 64 LINUX, Sep 23 2008 Build ID 363216
 
> A := y*(f[x]-z)/(f(x)-y):
> simplify(simplify(A,{(f[x]-z)/(f(x)-y)=lambda}));
                                   lambda y

while,

> kernelopts(version);
            Maple 13.00, X86 64 LINUX, Feb 18 2009 Build ID 388356
 
> A := y*(f[x]-z)/(f(x)-y):
> simplify(simplify(A,{(f[x]-z)/(f(x)-y)=lambda}));
Error, (in Groebner:-SuggestVariableOrder) invalid argument
for sign, lcoeff or tcoeff

I will submit an SCR.

acer

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