I'd like say that what Joe has described is a very good way to develop and maintain non-trivial Maple code source. To my mind, it's not a question of Windows vs Unix. It's a question of scripts & commandline versus GUI, for non-trivial code development and maintenance. Windows too has batch files. A plaintext file will always be accessible, while .mla and .mw may be less reliable. The procedures and modules that comprise one's source may be saved into a .mla archive, and used conveniently from any worksheet (not just that one containing the code!) via the libname mechanism. Source being stored in plaintext files, combined with use of the "TTY" shell-based Maple interface (cmaple.exe), allows one to use the #define and #include directives as implemented in Maple. External editors can provide very nice Maple language specific syntax highlighting. There are plenty of editors for Windows, even graphical ones, that provide automatic indentation in a solid way. The Worksheet and Document facilities of the Maple GUI are very nice for developing worksheets and documents. But there are better ways to develop and maintain a Maple code base. acer

Thanks for that strong point. I find your point about abstracted sizes of Matrices to be compelling. So, attributes on names might do. So no evaln might be needed. And it might be less difficult to code. Allowing for any concrete qualities, such as sub-blocks, might be hard, though. As for last-name-eval, I agree. I wasn't suggesting adding it to anything else. I was wondering more whether something like evalm() could be useful for some new ALA, to provide a way to generate concrete rtables from abstract LA ones. ps. By mistake I added this as a general comment to the top of the thread. Sorry. I meant it as a reply to Jacque's Abstract matrices comment. acer

Hi Jacques, Sure, having pure symbols (names, which presumably evaluate to just themselves and nothing else) with attributes is one of the ways that I thought that abstract linear algebra might go. But I also wondered whether, at some point, it would be nice to be able to convert an abstract LA expression into a computational, concrete LA thing which evaluates explicitly. One way to get that effect might be to have the usual Matrix/Vector rtables get attributes on them, and have an abstract LA environment in which those objects are treated as evaln. But in such a case, why the need for attributes, when such rtables could be queried about size, indexing-function? Is it important for memory, that the rtables needn't actually exist concretely, for a good abstract LA project? The new Matrix/Vector objects don't have last-name-eval like matrix/vector do, but would there still be a need to convert abstract LA expressions to comething concrete, in a way akin to what evalm does for arrays? Or is that a misdirection? acer

S := Sum(((-1)^n)/ln(n),n=2..infinity); evalf(S); acer

S := Sum(((-1)^n)/ln(n),n=2..infinity); evalf(S); acer

Thanks, Joe. As always, your code is sharper. I was just playing around. Under 10 lines of code and all the relevent builtins can be tested for zero (or other bad) arguments. Rinse and repeat, for each comprehensive test run of the product. acer

Maple 11.00, > `**`(); Execution stopped: Stack limit reached. I mention it, only because `**` has a different option builtin number than does `^`. Also, when I look at the help-page obtained with ?`**` I don't see `**` mentioned. Am I just not seeing it? It's pretty easy to test this sort of thing, too. A := [anames(builtin)]; A := remove( x->type(x,{ identical(`?[]`),identical(goto),identical(`assemble`), identical(`disassemble`),identical(`pointto`), identical(`DEBUG`),identical(`RETURN`),identical(`**`), identical(`^`) }), A ); for x in A do x; try x(); x(0); x(-1) catch: print(lastexception); end try; end do; acer

I wonder whether there was a "ban" on using array(), rather than the newer Array(). acer

I wonder whether there was a "ban" on using array(), rather than the newer Array(). acer

Please post a specific example, so that we can see to what you are referring. acer

I find this discussion fascinating. It reminded me of an idea that I've been playing with: whether abstract linear algebra (for use with LinearAlgebra, say) might be done reasonably well using attributes. Attributes on just what,.. that I don't know. acer

I tried this in both Maple 11.00 and 10.06, just for fun. In 10.06 it ran longer and seemed to use more memory. Interestingly, in 11.00 I saw no garbage collection messages while in 10.06 I did see gc update messages. I'm not sure how to reconcile that with more apparent memory consumption/use in 10.06. acer

I tried this in both Maple 11.00 and 10.06, just for fun. In 10.06 it ran longer and seemed to use more memory. Interestingly, in 11.00 I saw no garbage collection messages while in 10.06 I did see gc update messages. I'm not sure how to reconcile that with more apparent memory consumption/use in 10.06. acer

I'm not sure what it means, to be "first class objects" in Maple. Hardware scalar floats can exist stand-alone. But they'll only come into being (apart from when using their constructor explicitly) within a proc with option hfloat. > kernelopts(version); Maple 11.00, X86 64 LINUX, Feb 16 2007 Build ID 277223 > x:=HFloat(1.2); x := 1.19999999999999996 > dismantle(%); HFLOAT(2): 1.2 Also, see ?option_hfloat acer

I'm not sure what it means, to be "first class objects" in Maple. Hardware scalar floats can exist stand-alone. But they'll only come into being (apart from when using their constructor explicitly) within a proc with option hfloat. > kernelopts(version); Maple 11.00, X86 64 LINUX, Feb 16 2007 Build ID 277223 > x:=HFloat(1.2); x := 1.19999999999999996 > dismantle(%); HFLOAT(2): 1.2 Also, see ?option_hfloat acer