cf. is an abbreviation for the Latin word confer, meaning compare.

You may already have figured out that you can accomplish the assignments using seq and assign. The result (NULL) gets ignored, as the assignments get done as side-effects. It's slick, but not especially good.

> x[1], x[2], x[3] := 1, 2, 3:

> seq( assign(a[i],x[i]), i=1..3 );

> a[1], a[2], a[3];
                                    1, 2, 3

acer

I believe that the posted example actually did multiple sequential (rather than simultaneous) substitution.

This is simultaneous substitution,

> subs( {a=b, b=c}, [a,b] );
                                    [b, c]

And this is sequential substitution,

> subs( a=b, b=c, [a,b] );
                                    [c, c]

In your particular example, it might not have mattered. But the distinction can be useful.

acer

I believe that the posted example actually did multiple sequential (rather than simultaneous) substitution.

This is simultaneous substitution,

> subs( {a=b, b=c}, [a,b] );
                                    [b, c]

And this is sequential substitution,

> subs( a=b, b=c, [a,b] );
                                    [c, c]

In your particular example, it might not have mattered. But the distinction can be useful.

acer

The solve routine does not generally handle assumptions, in the sense that int does. It does however quite often call is internally, and so solve+assumptions sometimes has partial (and sometimes weird) effects.

What is more likely "supposed" to work is augmenting the assumptions as extra conditions. For example,

> solve({...., a>0}, ...);

Of course, it is still possible that it does not work, due to bugs/incompleteness/etc. The inequality solving capabilities seem to have been improving a little in recent releses, but are still not strong.

acer

The solve routine does not generally handle assumptions, in the sense that int does. It does however quite often call is internally, and so solve+assumptions sometimes has partial (and sometimes weird) effects.

What is more likely "supposed" to work is augmenting the assumptions as extra conditions. For example,

> solve({...., a>0}, ...);

Of course, it is still possible that it does not work, due to bugs/incompleteness/etc. The inequality solving capabilities seem to have been improving a little in recent releses, but are still not strong.

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

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