I hope it was clear that we agree. In fact, I have a summer student doing 4 different "experiments" in mathematics this summer, all 4 being done 100% within Maple.

Maple's main (current) use appears to still be as a tool to teach math, even though it is so much more than that. To me, Maple always has been a tool with which to do mathematical computations of all kinds. "computation" is an important restriction, otherwise Maple would have to deal with that much harder aspect of mathematics: proof. Right now, proof is completely avoided, and that is probably wise [I have looked at the state-of-the-art in computerized proof systems; they are amazing, but also astonishingly difficult to use]. However, what it is (to me), and what it is mostly used for, can be somewhat different. I would not want to have Maple be restricted to computing integrals, or solving DEs, or ... in only the ways that are taught in undergraduate courses! That would effectively neuter Maple. I am not against all sorts of extra frills (like making things pretty), as long as they don't interfere with getting the main task done - be it a simple mathematical computation, or a series of computations which help me understand a particular problem (and its solution). If the tool also lets me present my results nicely, great. If it goes out of its way to help me understand, then I am definitely sold. For an example of software that helps you understand, take a long at Ron Avitzur's Graphing Calculator.

Are there some numbers (maybe from a 3rd party, out there on the web) comparing ATLAS vs MKL on various Intel processors and architectures? I am curious. One question you did not address: AMD/Windows -- does that use ATLAS? Is there no equivalent to the MKL for Linux? I thought the MKL was written in pure assembly and was self-contained, so that it would be O/S independent! Where was I being too naive?

The Standard GUI was supposed to first reproduce all the functionality of Classic, then start introducing new ones. It is clear that some functionality was lost. Certainly the pretty-printer is, often, still not as good. I wonder what other features were lost?

The Standard GUI was supposed to first reproduce all the functionality of Classic, then start introducing new ones. It is clear that some functionality was lost. Certainly the pretty-printer is, often, still not as good. I wonder what other features were lost?

He had a style all his own, and had interesting things to say. I too would prefer if he came back. One of these days, I have meant to go in the 'old' places where knowledgeable Maplers used to hang out (like sci.math.symbolic and comp.soft-sys.maple or whatever the name is) and 'invite' some of the people we have not seen here to come and check out mapleprimes. I just have not had the time!

He had a style all his own, and had interesting things to say. I too would prefer if he came back. One of these days, I have meant to go in the 'old' places where knowledgeable Maplers used to hang out (like sci.math.symbolic and comp.soft-sys.maple or whatever the name is) and 'invite' some of the people we have not seen here to come and check out mapleprimes. I just have not had the time!

The hackware package should be so-identified more strongly. Back when it was created, it was OK because all computer users were hackers, and all software was unpredictable. Things have changed, and so hackware should evolve. I would consider being backwards *in*compatible on the hackware functions a feature! That with sscanf and the %m format you can create un-normalized DAGs is cool. A neat hole where many crashes lie. However, there are still (likely) some genuine bugs here: DAG normalization is session-dependent, so one can't read in a .m "raw" and expect it to be normalized already (normalized == what simpl does). So there must be selected calls to simpl() in the code for sscanf already, there just are a few more missing.

Congrats on getting your silver leaf.

Congrats on getting your silver leaf.

One's software should never crash. However, "garbage in, garbage out" does apply. So, short of crashing (or hanging or anything similar), both your examples could return rather arbitrary nonsense, and that would be legit. But not crash. I have seen one caveat to this hard rule two other languages: all commands which are 'unsafe' are clearly labelled so. In one language, they have the word 'unsafe' as a prefix to all unsafe functions. In the other, all such potentially unsafe commands are grouped in one module (called Obj in this case), which is not officially documented. I rather like the 'unsafe' route myself. pointto should be named unsafePointto. What you show with sscanf just feels like a straight bug rather than caveat emptor.

(2*{3})[4]^5$6&*7;

`!`:<<%>>.<<%>|<%>>; I think the results are rather pretty.

Why don't you make a blog posting of it, which will be a better place to store that information that in this thread. I would rather like to see how many keystrokes it takes to crash the kernel, as you describe. You should set the rules of the game -- what counts. For example, do the ; and <return> count? Maybe they do, since the bug might be in the command-line editing features!

Why don't you make a blog posting of it, which will be a better place to store that information that in this thread. I would rather like to see how many keystrokes it takes to crash the kernel, as you describe. You should set the rules of the game -- what counts. For example, do the ; and <return> count? Maybe they do, since the bug might be in the command-line editing features!