Nice.

Apologies, but I couldn't resist a small modification which (I think) works, and to make it a procedure. You are right, of course, that the centroid should lie in the least squares plane.

> Data:= Matrix([[1.33, 2.57, 2.24], [3.68, 5.27, 6.99],
>                [0.92, -0.98, 0.27], [-0.72, -0.74, 0.8],
>                [0.29, -0.31, -0.77], [-0.93, -0.2, -0.4],
>                [0.69, 0.44, 0.67]]):
>
> LineFit := proc(data::Matrix)
>   local n,Avg,M,S,Vt;
>   use LinearAlgebra in
>     n:= RowDimension(Data);
>     Avg := (Vector[row](n,1/n).data);
>     M := data - Vector(n,1) . Avg;
>     Vt := SingularValues(M,output=[':-Vt']);
>     Transpose(Avg), Transpose(Vt[1,1..-1]);
>   end use;
> end proc:
>
> LineFit(Data);
                [0.751428571428571446]  [-0.382423377977291923]
                [                    ]  [                     ]
                [0.864285714285714102], [-0.598085455692940360]
                [                    ]  [                     ]
                [1.39999999999999991 ]  [-0.704305436344918045]

It would make a good Task Template.

acer

Nice.

Apologies, but I couldn't resist a small modification which (I think) works, and to make it a procedure. You are right, of course, that the centroid should lie in the least squares plane.

> Data:= Matrix([[1.33, 2.57, 2.24], [3.68, 5.27, 6.99],
>                [0.92, -0.98, 0.27], [-0.72, -0.74, 0.8],
>                [0.29, -0.31, -0.77], [-0.93, -0.2, -0.4],
>                [0.69, 0.44, 0.67]]):
>
> LineFit := proc(data::Matrix)
>   local n,Avg,M,S,Vt;
>   use LinearAlgebra in
>     n:= RowDimension(Data);
>     Avg := (Vector[row](n,1/n).data);
>     M := data - Vector(n,1) . Avg;
>     Vt := SingularValues(M,output=[':-Vt']);
>     Transpose(Avg), Transpose(Vt[1,1..-1]);
>   end use;
> end proc:
>
> LineFit(Data);
                [0.751428571428571446]  [-0.382423377977291923]
                [                    ]  [                     ]
                [0.864285714285714102], [-0.598085455692940360]
                [                    ]  [                     ]
                [1.39999999999999991 ]  [-0.704305436344918045]

It would make a good Task Template.

acer

Would simply a scaling change of variable suffice? If so then you might try using `subs` on the expressions to replace one variable with a scaled replacement.

acer

Would simply a scaling change of variable suffice? If so then you might try using `subs` on the expressions to replace one variable with a scaled replacement.

acer

The documentation of initialization files and their platform dependent details (eg. name and location) could be much better. These are basic things, and should be documented so that every new user to maple, who as yet knows almost nothing about Maple, should be able to find easily and use them easily.

In Maple 11, issuing  ?initialization or ?mapleinit or ?startup all take one to the help-page for "The Maple Command and Command-line Options". Since most Windows and OSX users only ever start Maple via an icon or launcher button, that page isn't really appropriate for all those help queries. Moreover, that help-page references the ?worksheet,reference,initialization page only very far down, and not in either section dealing with the -i or -s options, and not in the See Also section.

I really don't find it useful when longer help-pages don't include in their See Also section all the cross-references that appear ealier in the page.

Also, the help page name ?worksheet,reference,initialization is a misnomer. It's contents are not specific to the graphical worksheet interfaces.

On Unix the resource file for the GUI may have a name like ~/.maple/11/maplerc which is fine because it has nothing in common with the user initialization file ~/.mapleinit . But on Windows the resource file has a name like maple11.ini while the initialization file is called maple.ini , and their locations can be close (depending on the single- vs multi-user mode). Those similar names are just asking for trouble, and of course now and then we see here a post by someone who attempts to put startup maple commands in the wrong file.

Lastly, where is the simple help query to get instruction and description of the contents of the GUI resource file, that maple11.ini file? (See this blog entry for a nice -- if slightly outdated w.r.t Unix filename and location -- bit of detail on this resource file.)

acer

The documentation of initialization files and their platform dependent details (eg. name and location) could be much better. These are basic things, and should be documented so that every new user to maple, who as yet knows almost nothing about Maple, should be able to find easily and use them easily.

In Maple 11, issuing  ?initialization or ?mapleinit or ?startup all take one to the help-page for "The Maple Command and Command-line Options". Since most Windows and OSX users only ever start Maple via an icon or launcher button, that page isn't really appropriate for all those help queries. Moreover, that help-page references the ?worksheet,reference,initialization page only very far down, and not in either section dealing with the -i or -s options, and not in the See Also section.

I really don't find it useful when longer help-pages don't include in their See Also section all the cross-references that appear ealier in the page.

Also, the help page name ?worksheet,reference,initialization is a misnomer. It's contents are not specific to the graphical worksheet interfaces.

On Unix the resource file for the GUI may have a name like ~/.maple/11/maplerc which is fine because it has nothing in common with the user initialization file ~/.mapleinit . But on Windows the resource file has a name like maple11.ini while the initialization file is called maple.ini , and their locations can be close (depending on the single- vs multi-user mode). Those similar names are just asking for trouble, and of course now and then we see here a post by someone who attempts to put startup maple commands in the wrong file.

Lastly, where is the simple help query to get instruction and description of the contents of the GUI resource file, that maple11.ini file? (See this blog entry for a nice -- if slightly outdated w.r.t Unix filename and location -- bit of detail on this resource file.)

acer

On Unix, the startup file is ~/.mapleinit , and on Windows it is maple.ini .

See the help-page  ?worksheet,reference,initialization

These initialization files also get reread when one issues a restart within a Maple session.

acer

On Unix, the startup file is ~/.mapleinit , and on Windows it is maple.ini .

See the help-page  ?worksheet,reference,initialization

These initialization files also get reread when one issues a restart within a Maple session.

acer

I'd like to add that those "percent" labels do not behave like names, in the sense that %1 is not the same as the name `%1` . It's not clear that any Maple name has actually been assigned, in Maple's usual sense, the expression which such a label represents. The labels appear to be accessible only at the interface level, and not directly from within the kernel. That's how it seems, at least, which goes along with their being next to impossible to procedurally manipulate.

acer

I find it hard to accept that the RREF of the following Matrix , whose condition number is roughly 10^1201, should be taken to be the identity.

> M:=Matrix([[1e600,0,0],[0,1,1],[0,1e-600,0]]);
                           [      601                   ]
                           [0.1 10           0         0]
                           [                            ]
                      M := [    0            1         1]
                           [                            ]
                           [                   -599     ]
                           [    0        0.1 10        0]

> evalf(ReducedRowEchelonForm(convert(M,rational)));
                               [1.    0.    0.]
                               [              ]
                               [0.    1.    0.]
                               [              ]
                               [0.    0.    1.]

On the other hand, it was interesting how the above Matrix made the external NAG function hw_f08mef "go away" when I asked for LinearAlgebra:-Rank(M) at default Digits.

acer

I find it hard to accept that the RREF of the following Matrix , whose condition number is roughly 10^1201, should be taken to be the identity.

> M:=Matrix([[1e600,0,0],[0,1,1],[0,1e-600,0]]);
                           [      601                   ]
                           [0.1 10           0         0]
                           [                            ]
                      M := [    0            1         1]
                           [                            ]
                           [                   -599     ]
                           [    0        0.1 10        0]

> evalf(ReducedRowEchelonForm(convert(M,rational)));
                               [1.    0.    0.]
                               [              ]
                               [0.    1.    0.]
                               [              ]
                               [0.    0.    1.]

On the other hand, it was interesting how the above Matrix made the external NAG function hw_f08mef "go away" when I asked for LinearAlgebra:-Rank(M) at default Digits.

acer

Thanks Will, I can understand that MathML has not taken enough hold.

But isn't it still true, that 2D Math input being displayed here on Mapleprimes posts via gifs makes the whole cut & paste of said input rather too much work?

I see that uploaded .mw files can be displayed (using a client plugin) in such a way that it looks like Maple 2D Math as well as behaves nicely under cut & paste into a separate Maple session. Could not the same technology be used (transparent to the mapleprimes user) to mark up <maple> fragments in posts here, and display them inlined with each using some similar mechanism?

If the math and the maple can't be easily copied into a working Maple session, then something important is missing. Having to resort to uploading a worksheet in order to get that effect isn't much different than having to install extra plugins/fonts/etc. Well, actually, it's more effort since presumably installation of extras is a once-only affair while having to use downloads (or view Properties of embedded objects) to make 2D code easily accessible and transferable is something that currently needs to be done for each occurrence.

acer

Hi John,

While I agree with you that the <maple> tag is not working properly at present, I do wonder why it's an appealing prospect at all.

I mean, suppose you produced a nice post, with all the math input as 2D (converted to gifs here on mapleprimes). Is it easy to cut & paste such input, into a separate Maple session? I would say no, if it means having to resort to the trick (thanks again, Jakubi) of popping up the Properties of the embedded gif image and grabbing the Alternate text.

What I wonder is why it can't be displayed with MathML, that might then further be plonked straight into Maple. It is 2008, after all.

acer

I don't know how the original poster will resolve his separate, unposted questions related to construction of more involved piecewise functions.

But, for the type of problem as originally posted here where the form of the operators' bodies is known in advance, unapply is not a better choice as far as scaled performance goes.

One can benchmark the two, in separate sessions (full exit and relaunch, not just restart).

> for i from 1 to 20000 do
> unapply(t*i,t);
> od:
> quit
bytes used=57567480, alloc=16905192, time=1.56

versus

> f := i -> t -> t*i:
> for i from 1 to 20000 do
> f(i);
> od:
> quit
bytes used=5686424, alloc=4324584, time=0.06

Of course, for small code fragments that are not intended for heavy reuse, the convenience might matter much more than the performance. If piecewise() constructs are being used then performance is (cough) probably not the major goal.

acer

I don't know how the original poster will resolve his separate, unposted questions related to construction of more involved piecewise functions.

But, for the type of problem as originally posted here where the form of the operators' bodies is known in advance, unapply is not a better choice as far as scaled performance goes.

One can benchmark the two, in separate sessions (full exit and relaunch, not just restart).

> for i from 1 to 20000 do
> unapply(t*i,t);
> od:
> quit
bytes used=57567480, alloc=16905192, time=1.56

versus

> f := i -> t -> t*i:
> for i from 1 to 20000 do
> f(i);
> od:
> quit
bytes used=5686424, alloc=4324584, time=0.06

Of course, for small code fragments that are not intended for heavy reuse, the convenience might matter much more than the performance. If piecewise() constructs are being used then performance is (cough) probably not the major goal.

acer