acer

32974 Reputation

29 Badges

20 years, 151 days
Ontario, Canada

Social Networks and Content at Maplesoft.com

MaplePrimes Activity


These are replies submitted by 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
The mixture sin-Pi isn't very useful. Does one apply it, as an operator, or evaluate it at a point, or...? > k := sin-Pi; k := sin - Pi > k(1.1); 0.8912073601 - Pi(1.1) > eval(k(x),x=1.1); 0.8912073601 - Pi(1.1) How would you plot it? Distinguishing between sin-1/2 and sin-sqrt(2) seems inconsistent to me. acer
First 578 579 580 581 582 583 584 Last Page 580 of 603