Just a little note to tag on to this discussion: I noticed that writeto() also auto-linebreaks output. This is not always optimal.

Just a little note to tag on to this discussion: I noticed that writeto() also auto-linebreaks output. This is not always optimal.

I use lprint() all the time, but I can't help but think that there's another, more powerful print command that I just can't seem to find or remember. I think I remember the help page showing how you could make very nice aligned tables using that command... Gah, this is going to bug me.

I use lprint() all the time, but I can't help but think that there's another, more powerful print command that I just can't seem to find or remember. I think I remember the help page showing how you could make very nice aligned tables using that command... Gah, this is going to bug me.

You could always collect your values in a sequence and then use printf(). For example: seq := 1,2,3,4,5; printf( "%q", seq ); I seem to remember there being another command that is better, but for the life of me I can neither remember nor find it.

You could always collect your values in a sequence and then use printf(). For example: seq := 1,2,3,4,5; printf( "%q", seq ); I seem to remember there being another command that is better, but for the life of me I can neither remember nor find it.

That would seem to speak to a deeper problem in Maple. It seems that further testing is necessary. Thank you for showing us this, Tim!

That would seem to speak to a deeper problem in Maple. It seems that further testing is necessary. Thank you for showing us this, Tim!

You have hit term elision, it would seem. You can set the elision threshhold in the Maple preferences. Basically, there were so many terms that Maple simplified the output by deleting (only from the output) the middle terms and only shows the beginning and ending terms. An annoying thing, elision is. I didn't know that the writeto() command would respect such settings. We always use another way to solve this whole problem (i.e. to print Maple results to a file): fopen, fprintf, fclose. Example (using your s4 proc): fd := fopen("myoutput.txt", WRITE): fprintf( fd, %a, [`$`(s4(n), n=1..10002)] ): fclose(fd): --Schivnorr

You have hit term elision, it would seem. You can set the elision threshhold in the Maple preferences. Basically, there were so many terms that Maple simplified the output by deleting (only from the output) the middle terms and only shows the beginning and ending terms. An annoying thing, elision is. I didn't know that the writeto() command would respect such settings. We always use another way to solve this whole problem (i.e. to print Maple results to a file): fopen, fprintf, fclose. Example (using your s4 proc): fd := fopen("myoutput.txt", WRITE): fprintf( fd, %a, [`$`(s4(n), n=1..10002)] ): fclose(fd): --Schivnorr

Are you using Maple 11 Standard interface? If so, it could be a problem with the Java on your system, causing it to slowly gobble up all of your memory. It couldn't hurt to make sure you have the most up-to-date version of Java on your machine, anyway.

You know, when you say it like that, it seems so simple. I want to say that I tried that, but I guess I had not; if I had, I would have saved myself a good deal of time. The single quotes delay the evaluation in exactly the same manner as eval(x,1) does in the example. Yes, define() seems to be using Maple's standard evaluation rules. The problem is, this evaluation does not happen when performing the analogous task of defining a procedure. Speaking of which, I should really go into Maple and test to see what happens if I try to define local variables, have multiple lines of action, include while loops, etc. in the define() command. All that would really need to be placed in the help page is a quick note and example detailing this evaluation.

Maple is horrendous when it comes to input in Maple (1D) versus 2D notation. When multiple exact same keystroke sequences or lines (see this post) end up parsing as entirely different entities, it's amazing to think that Maple can actually understand itself (see this post for a discussion of a major area in which Maple does NOT understand itself). Interestingly enough, if one escapes the slashes in the division when entering x/y/z into Maple in 2D input (i.e. the literal keystrokes would be x\/y\/z; ), then Maple returns the same result one would have received from entering the division in as Maple (1D) notation.

Suppose that f,g,h are functions. What does f(g+h) mean?—f×(g+h) or f applied to g+h? Well, then we get back to nitpicking context. Are f,g, and h functions from the same ring? Are g and h functions from the same group? Is g+h in the domain of f? How are you representing multiplication in other cases? How are you representing function application in other cases? Etc. ... This game can be played ad nauseam. Instead, I'd like to agree that most of Iverson's ideas were (and still are) really good, and note that APL seems to still have a decent user base (myself included). Mathematics may have its conventional notation, but conventions change over time and space; not everybody uses the same conventions for marking up mathematics. To move away from implicit multiplication (as we seem to be riding it like a dead horse in the Kentucky Derby), take line breaking for example: If one must line break between the two operands of a sum or difference ( e.g. a + \n b ), does one put the plus/minus sign before the new line, after the new line, or both? Depending on who you ask, you'll get all three answers. It's one thing for Maple to support a certain convention for output, it's quite another for Maple to try to support as many conventions as possible via WYSIWYG input. If personal typesetting rules were somewhow inherent in the worksheet and would enforce themselves when opened on foreign machines, then things wouldn't be as problematic; however, that would, itself open a large can of worms. I think I'm just rambling at this point--I should try to make a concise point and end this post. The .mw format of the worksheet does store the specific typesetting rules/format for any line input and run in the Maple worksheet. This format / these rules are disregarded when lines of the worksheet are executed in a foreign environment. This design would lead to unnecessary clutter caused by the user entering extra lines specifying typesetting rules for particular lines so that when the worksheet is run in its entirety (and sequentially) in a foreign environment, the work remains correct. Disregarding my opposition to Maple's current 2-D Math Input mode, this simply does not seem to be an effective system overall.

Just ... wow. Well, thank you for giving me another reason not to use MapleTA.