Do not the Matrices need to commute, for that property to hold? I thought of doing trying that, to be able to replace the product of matrix exponentials with a single matrix exponential of a sum. The result differs in general, I think. And although I did not look hard at the alternative result, it too might be unitary!? (If this is from an algorithm in a published paper, one could imagine that the original authors would have thought of this and discarded it for some reason, however.) I had some other performance improvements for this, which got both memory and speed (33%) gains. It might still be slower than Matlab. For the N=20 case there are something like 399 Matrix complex float exponentials to be computed. Even at something like 1/100th of a second per 20x20 matrix exponential, it might be relatively slower. I will try to find time to post my code edits. I assume that the poster is most interested in following his algorithm, rather than work on another altogether. acer

Do not the Matrices need to commute, for that property to hold? I thought of doing trying that, to be able to replace the product of matrix exponentials with a single matrix exponential of a sum. The result differs in general, I think. And although I did not look hard at the alternative result, it too might be unitary!? (If this is from an algorithm in a published paper, one could imagine that the original authors would have thought of this and discarded it for some reason, however.) I had some other performance improvements for this, which got both memory and speed (33%) gains. It might still be slower than Matlab. For the N=20 case there are something like 399 Matrix complex float exponentials to be computed. Even at something like 1/100th of a second per 20x20 matrix exponential, it might be relatively slower. I will try to find time to post my code edits. I assume that the poster is most interested in following his algorithm, rather than work on another altogether. acer

The maple "engine", which does the computations, is mserver (mserver.exe on Windows). It communicates with one of the three interfaces over sockets. The mserver is supposed to shut down when the interface shuts down, but it seems that under some rare circumstances this might not happen (or gets delayed, perhaps if the kernel has "gone to the think tank"). An unusual exit (crash) of the interface may also orphan the mserver. The mservers can use a lot of memory, because that's where the computations are done. The Std GUI can use a lot of memory because, well, because that runs under java. On unix/linux the interfaces are java (Std GUI), cmaple (TTY), and maplew (Classic, cwmaple on Windows). I'm not sure how "mjava" ties in, though it's likely a Std GUI thing. acer

The maple "engine", which does the computations, is mserver (mserver.exe on Windows). It communicates with one of the three interfaces over sockets. The mserver is supposed to shut down when the interface shuts down, but it seems that under some rare circumstances this might not happen (or gets delayed, perhaps if the kernel has "gone to the think tank"). An unusual exit (crash) of the interface may also orphan the mserver. The mservers can use a lot of memory, because that's where the computations are done. The Std GUI can use a lot of memory because, well, because that runs under java. On unix/linux the interfaces are java (Std GUI), cmaple (TTY), and maplew (Classic, cwmaple on Windows). I'm not sure how "mjava" ties in, though it's likely a Std GUI thing. acer

How would one save the user-assigned variables in such a session as below? a:=proc() local x; x; end: x:=5; y:=a(); Is y "user-assigned"? The fact that it was assigned an escaped local appears lost, using anames(user) or anames(alluser) and the technique suggested. Is there some easy modification to get around that? Are there other problematic cases? (Maybe using modules, or anonymous modules created by a parent module's ModuleApply, or...?) Is a .mla sufficient to store the whole "user-defined" state? Should there be a mechanism to store everything (including the nature of the localness of all locals)? acer

How would one save the user-assigned variables in such a session as below? a:=proc() local x; x; end: x:=5; y:=a(); Is y "user-assigned"? The fact that it was assigned an escaped local appears lost, using anames(user) or anames(alluser) and the technique suggested. Is there some easy modification to get around that? Are there other problematic cases? (Maybe using modules, or anonymous modules created by a parent module's ModuleApply, or...?) Is a .mla sufficient to store the whole "user-defined" state? Should there be a mechanism to store everything (including the nature of the localness of all locals)? acer

I believe that objects are all over the place, in memory. The only data that I know to be stored in a contiguous segments is that of "hardware" datatype rtables (which is why vendor or cache-tuned BLAS are used). If memory is all over, and the simpl table stores a hash value dependent upon memory location (and if that value appears in many other objects), then compacting all stored data is problematic. So fragmentation can be a problem. You can see what I think is evidence of this in how much large hardware rtable creation can cause somewhat "unexpected" allocation increases -- there's free memory already allocated, but not a large enough contiguous piece. acer

I believe that objects are all over the place, in memory. The only data that I know to be stored in a contiguous segments is that of "hardware" datatype rtables (which is why vendor or cache-tuned BLAS are used). If memory is all over, and the simpl table stores a hash value dependent upon memory location (and if that value appears in many other objects), then compacting all stored data is problematic. So fragmentation can be a problem. You can see what I think is evidence of this in how much large hardware rtable creation can cause somewhat "unexpected" allocation increases -- there's free memory already allocated, but not a large enough contiguous piece. acer

The colour does vary, from leaf to leaf and tree to tree. As the green chlorophyll disappears, the yellows begin to show up. The red is usually due to converted sugars, I believe, which varies from tree to tree. A quick web search indicates that the red is due to anthocyanins in the sap (pigments also found in cranberries, cherries, etc), and the yellow and orange is due to carotene type pigments (also found in carrots). acer

showstat(curry); It's a programming convenience. acer

showstat(curry); It's a programming convenience. acer

Could you not have delayed evaluation by using uneval quotes? define( '`&d`' , 'orderless', &d( a::list, b::list ) = 'simplify(sqrt(add( (a[i]-b[i])^2, i=1..nops(a))))' ); [1,2,3,4,5] &d [4,3,2,1,0]; Isn't define() showing maple's usual evaluation rules? If you would want that changed, for define(), then how precisely? In any case, the help-page ?define could be made to explain this. acer

Yes, of course, sorry. The rest still holds, I think. But we seemed to agree that andmap only got called once for product 2*a, which is wrong. I wonder whether it relates to the fact that 2*a dismantles to a SUM, and not a PROD. acer

It looks like it is going wrong, for the multiplication. andmap(A,2*a) is calling A just once, with argument 2. Compare with ormap(A,c*a*b), for which A gets called three times, with arguments a, b, and c. Interestingly, andmap(A,c*a*b) also calls A just once. It seems that andmap is considering only a single operand of a product, while ormap considers all the operands. I wonder whether the problem is restricted to andmap and products. acer

So the user has to do this optional thing, explicitly, to get the .mw file to save enough about the parsed meaning for it to be reproducible when re-executed by someone else? And if that optional thing (involving Typesetting[Settings]) is not done then the worksheet works for the original user regardless? And the natural method of 2D Math input can provide the user's desired parsed meaning for something, without having to do that optional thing? That isn't a good design. It'd be OK for some display characteristics (display of floats, etc) to be different. And different security settings should be respected. But parsed meaning of the input, that should be preserved. The author should not have to do anything special, for the intended parsed meaning to be saved along with the file, so as to allow correct reproduction upon execution elsewhere. Moreover, the typesetting settings of any other user should control only what they themselves enter. Having the user's settings affect re-execution of pre-existing worksheets, by reparsing the input as if it were being re-entered altogether, is not good. I'm having a hard time believing that this is the default behaviour, and that things can be that bad if the original author does not take an extra unobvious step. I'm hoping that I've misunderstood. acer