@Danik Change all instances of `pi` to `Pi`.

In Maple, `Pi` is a name which evaluates in floating-point approximation to 3.14...

But `pi` is just another name, with no such meaning or behaviour by default.

@Danik Change all instances of `pi` to `Pi`.

In Maple, `Pi` is a name which evaluates in floating-point approximation to 3.14...

But `pi` is just another name, with no such meaning or behaviour by default.

@toandhsp 

ksols :=  isolve({(1/9)*Pi+2*k*Pi*(1/3) >= 1, (1/9)*Pi+2*k*Pi*(1/3)<= 2^Pi}) ;

               {k = 1}, {k = 2}, {k = 3}, {k = 4}

op( map2( eval, Pi/9+2*k*Pi/3, {ksols} ) );

                   7     13     19     25   
                   - Pi, -- Pi, -- Pi, -- Pi
                   9     9      9      9    

seq( eval( Pi/9+2*k*Pi/3, K), K in ksols );

                   7     13     19     25   
                   - Pi, -- Pi, -- Pi, -- Pi
                   9     9      9      9    

f := k -> Pi/9+2*k*Pi/3:

seq( f(rhs(op(K))), K in ksols );

                   7     13     19     25   
                   - Pi, -- Pi, -- Pi, -- Pi
                   9     9      9      9    

@toandhsp 

ksols :=  isolve({(1/9)*Pi+2*k*Pi*(1/3) >= 1, (1/9)*Pi+2*k*Pi*(1/3)<= 2^Pi}) ;

               {k = 1}, {k = 2}, {k = 3}, {k = 4}

op( map2( eval, Pi/9+2*k*Pi/3, {ksols} ) );

                   7     13     19     25   
                   - Pi, -- Pi, -- Pi, -- Pi
                   9     9      9      9    

seq( eval( Pi/9+2*k*Pi/3, K), K in ksols );

                   7     13     19     25   
                   - Pi, -- Pi, -- Pi, -- Pi
                   9     9      9      9    

f := k -> Pi/9+2*k*Pi/3:

seq( f(rhs(op(K))), K in ksols );

                   7     13     19     25   
                   - Pi, -- Pi, -- Pi, -- Pi
                   9     9      9      9    

@Lautrup I have a copy of what appears to be the Dcoument, repaired. It is 8.5Mb. Uploading it to Mapleprimes, even zipped, fails.

I will contact you. If you respond to the email then I will have your address and can send you the zipped file.

acer

@Lautrup I have a copy of what appears to be the Dcoument, repaired. It is 8.5Mb. Uploading it to Mapleprimes, even zipped, fails.

I will contact you. If you respond to the email then I will have your address and can send you the zipped file.

acer

@KCM 

p:=expand( (x+x^2)*(x+2) );

                           2          3
                        3 x  + 2 x + x 

sort(p,x);

                         3      2      
                        x  + 3 x  + 2 x

sort(p,x,ascending);

                                 2    3
                        2 x + 3 x  + x 

You can read about `sort` on its help-page.

@KCM 

p:=expand( (x+x^2)*(x+2) );

                           2          3
                        3 x  + 2 x + x 

sort(p,x);

                         3      2      
                        x  + 3 x  + 2 x

sort(p,x,ascending);

                                 2    3
                        2 x + 3 x  + x 

You can read about `sort` on its help-page.

@Christopher2222 There aren't much better ways that I can think of, other than using anames() of some kind before and after. There are variations on what you've described. Eg. you could print instead of showstat, after raising the verboseproc setting.

You might need to watch out for remember tables and/or Cache on the procs.

This shows why a .m file isn't nearly as good a way to store procedures as keeping plaintext copies. Also, it shows why using libary .mla archives is easier to use than .m, since there are easier tools for listing archive contents. (...additonally, .m is no good for saving whole modules.) But even .mla presents a (often surmountable) challenge for extracting module locals separately.

It has even happened (very rarely) in the distant past that .m formats have changed in incompatible ways between releases. Always keep precious source as plaintext, I'd advise (and not even as .mw/.mws), if you want to re-use it in the very long term.

I suppose that the .m file is not of your own creation, is that right?

Some people use .m in weird ways. I've seen people use it to store huge numeric Matrices, which would be more compactly stored using ExportMatrix (and as of recently, in binary format) and likely more efficiently re-read with ImportMatrix. Using .m is pretty old school. cf. comments above on modules.

(Are you looking at that HYPERG question? It has .txt source, not .m, so maybe you're doing something else. That source has handful of its procedures need edtiting to not use `args` as parameters, and it should be changed to save all contents to .mla instead. Changing it from table-based package to module would be icing on the cake, replacing its `init` function with ModuleLoad, perhaps. A OS tool like grep could be used to extract all the names that need to be savelib'd. The old-style help source could be split off separately as source too, I suspect.)

acer

@jimmyinhmb Here's an example, for multiplying the transpose of 50x50 Matrix A with 50x50 Matrix B one hundred thousand times.

On a fast i7 running Win 7 Pro (64bit Maple 15.01) it takes about 4 sec using the ideas laid out above, and it takes about 26 sec to do it repeatedly as C := A^%T . B

dgemm_module.mw

The benefit in speed gets less as the Matrix size goes up. But there is also the question of total memory allocation.

@jimmyinhmb Here's an example, for multiplying the transpose of 50x50 Matrix A with 50x50 Matrix B one hundred thousand times.

On a fast i7 running Win 7 Pro (64bit Maple 15.01) it takes about 4 sec using the ideas laid out above, and it takes about 26 sec to do it repeatedly as C := A^%T . B

dgemm_module.mw

The benefit in speed gets less as the Matrix size goes up. But there is also the question of total memory allocation.

The Standard GUI's debugger is awkward to use. It is awkward but (far, far worse) also has several serious bugs.

The worst bug is a tendency to lock the session, and force shutdown of that kernel and closure of the document with no option to save. (I have been recently having to use it for some debugging of mixed-GUI-related stuff, and for my task simply accidentally putting the focus back to the main sheet -- while the debugger is still in action -- will cause such a freeze up every single time. But that is just one of many ways it can go very wrong and/or crash.)

But in a relative sense I care more about being able to use a better debugger while in Standard than I do about the bugs in the current debugger being fixed. One that is not graphical, with next-to-no mouse action required. One that crashes the kernel on me once per year at most (like in the CLI) instead of once per hour.

I don't understand why the text mode of the commandline interface's debugger cannot be optionally offered in the Standard GUI. It works in Classic, and just involves plain 1D text commands as input, and so why cannot it work in Standard and push out prettyprint=1 level output?

acer

The Standard GUI's debugger is awkward to use. It is awkward but (far, far worse) also has several serious bugs.

The worst bug is a tendency to lock the session, and force shutdown of that kernel and closure of the document with no option to save. (I have been recently having to use it for some debugging of mixed-GUI-related stuff, and for my task simply accidentally putting the focus back to the main sheet -- while the debugger is still in action -- will cause such a freeze up every single time. But that is just one of many ways it can go very wrong and/or crash.)

But in a relative sense I care more about being able to use a better debugger while in Standard than I do about the bugs in the current debugger being fixed. One that is not graphical, with next-to-no mouse action required. One that crashes the kernel on me once per year at most (like in the CLI) instead of once per hour.

I don't understand why the text mode of the commandline interface's debugger cannot be optionally offered in the Standard GUI. It works in Classic, and just involves plain 1D text commands as input, and so why cannot it work in Standard and push out prettyprint=1 level output?

acer

@IanLisle I'm glad that you have a solution.

Yes, I knew of the savelib action's giving a name to the module, which is what made me suspect that one of the approaches might be as adequate as the other.

I will submit a Software Change Request, so that (if this is all true, that both work) the help-pages might indicate creation of a named module as a simpler approach.

@IanLisle I'm glad that you have a solution.

Yes, I knew of the savelib action's giving a name to the module, which is what made me suspect that one of the approaches might be as adequate as the other.

I will submit a Software Change Request, so that (if this is all true, that both work) the help-pages might indicate creation of a named module as a simpler approach.