LaTeX is old and reliable and understood by a lot of people.
MathML is sexy and shiny and web-friendly.
LaTeX is old and reliable and understood by a lot of people.
MathML is sexy and shiny and web-friendly.
First, a lot of things in Maple don't scale, at least in Theory: look at Groebner bases as one obvious instance. Some others are even simpler, as you point out, since they are instances of problems which are in general undecidable [never mind low complexity stuff like NP- or even EXP-complete!]. Yet Maple works rather well, and a lot of people spend a lot of time implementing Groebner basis algorithms and using them successfully. So I do not buy that argument at all.
Second, you are right that a straight coding of parametric algorithms seems like a nightmare. But I have tackled exactly this problem in two papers:
one shows how to systematically derive parametric algorithms from scalar ones,
the other explains the underlying techniques in general (partial evaluation).
The reason it works, and avoids some of the blowup of other techniques, is that it uses implicit representations instead of explicit ones. See
the work presented at the Maple Conference showing that for symbolic LU, this brings the complexity of manipulating these giant expressions back down to n^3.
I think that's because all of the introductions to Maple try to "show off" Maple [this is not to be taken negatively!], and thus introduce sum. Rarely is add() used in such tutorials. And since sum mostly works as add does, why would users bother to figure out those subtleties? [Learning Maple already induces a lot of information overload...]
To minimize this effect, either
1) add should be introduced at the same time as sum
2) the semantic mismatch should be resolved.
#1 might make the introductions a lot heavier (information_overload++). #2 is likely a lot of work, and cannot be 100% backwards compatible. Neither seems like a really good way forward, so hopefully someone can come up with a #3 !
I think that's because all of the introductions to Maple try to "show off" Maple [this is not to be taken negatively!], and thus introduce sum. Rarely is add() used in such tutorials. And since sum mostly works as add does, why would users bother to figure out those subtleties? [Learning Maple already induces a lot of information overload...]
To minimize this effect, either
1) add should be introduced at the same time as sum
2) the semantic mismatch should be resolved.
#1 might make the introductions a lot heavier (information_overload++). #2 is likely a lot of work, and cannot be 100% backwards compatible. Neither seems like a really good way forward, so hopefully someone can come up with a #3 !
Yes,
I would be happy with such a result. However, I am even more interested in solving the problem, (the ability of Maple to compute the results, as you say) so that if there is a ``better'' solution dreamed up for this, that's fine with me. piecewise is currently the main way to express "choice" in Maple, but mathematically that is not the only way that can be done. Now, I happen to
rather like piecewise, but that is really a different matter.
The requirement is to "solve the problem". I have some solutions that I like, but I don't want to prejudice the design by offering them now.
The hotkeys item is nice, but some of the other items posted here belong either on their own (bugs are bugs and should be fixed), or sometimes on the wish list as they are feature requests.
However, Joe, your "better worksheet access" contains an actual "use case", so it belongs here. You proposed some ways of implementing this too - and that still belongs here as long as you don't mind if what ends up being implemented does not match your suggestions but does solve the use case.
I do want pretty-printing of code. I have been "converted" to this view by the Haskell people. Many of their published papers, even in prestigious journals like the Journal of Functional Programming, are "print outs" of their literate code. I want to be able to do the same with my maple code (I have a partial evaluator for Maple that is almost out of the prototype stage, some program transformation code, some inference code, etc, all of which should sit inside a literate document).
The nice thing about pretty-printing code (which the worksheet does to a certain extent already) is that the stuff that is really mathematics looks like math too. I do want my ranges, 'in' operators, big expressions, and so on to look like math. But I am not the only one there - Haskell does that, that's what Intentional Programming is all about, same as Fortress, etc.
Hyperlinked PDF would indeed be the target -- but I really do want to use full LaTeX as my markup language.
Chunks would be nice, but it is one feature that I would be willing to live without. lhs2tex does not have to worry about chunks because Haskell programs are declarative, so ordering doesn't matter so much, making chunks and code rearrangement not a particularly important feature.
I want a good, maple-aware literate programming tool. Something like the tight integration of
lhs2tex is to Haskell. I can't think of writing non-literate Haskell code now, and feel rather bad when I have to do so in Maple.
Note that I do not consider any version of the worksheet/document interface to be a good solution to this. [This is why this is in the wish list rather than the requirements list].
Suppose I have some expression e which depends on a variable x and some parameters a,b,c. I want to compute some quantity of e, but I also know that the answer depends on the parameters, but not quite how - that is Maple's job.
An explicit easy example: degree(a*x^2+b*x+c, x). The correct answer is not '2'! What exactly should be the shape of the 'correct' answer, that is open.
Of course, this gets more interesting for integrals, differential equations, series, etc. Some of this is already implemented, but somewhat patchily - but I have run into this problem many times.
Oh, no, Roman has been way ahead of me for a long time - but I have been catching up in the last few months. Seems I might pass him soon.
Oh, no, Roman has been way ahead of me for a long time - but I have been catching up in the last few months. Seems I might pass him soon.
I should be able to cut and paste from Maple (GUI versions) into other standard applications (Word, OpenOffice, an input box in Firefox like the one I am typing in now, an email program, older versions of Maple) and have the result be 1) meaningful, and 2) as visually pleasant as the application allows.
Actual uses cases are clear: I do some short computations in Maple, and I wish to report on these in another setting. I want to cut and paste, and have the results 'look right' without much editing.
One example case which does not work satisfactorily: from Standard to Classic.
I know Joe has been using Maple a long time, but I have been using Maple a LONG time! I first typed 'maple' in the fall of 1985, and Maple 4.0 came up. When I bought the manual in the store (which I still have), that was for Maple 3.3.
I was so taken with Maple that, after taking the symbolic computation course at the University of Waterloo (taught by George Labahn), I worked hard at getting a job with a company then called Waterloo Maple Software Inc. I started with them in 1991 (I was the one and only GUI programmer then! I wrote 80% of the first version of the Windows GUI, and some of the ideas I used there are still in the current GUI), before I moved to being the whole Math Group a year and a half later. My first coop student is now the head of the Kernel Group, and my second coop student is now the VP R&D. At that time, 100% of the 'math development' was still done in the research groups at various universities. My first year or so, all I did was bug fixing. I highly recommend it as a great way of learning just about any system inside-and-out.
I won't go into the rest of my Maple history (the above only gets me to 1993!), maybe some other time.
The thing to remember is that I was steeped in Maple for years. I once estimated that I have personally read/reviewed about 600Kloc of Maple's roughly 1 million lines of (maple) code. I still use Maple all the time to get my own research done [and I complain when it slows me down because I know it can be better].
I had to learn a lot about Maple the hard way. If my posting here helps a few people learn Maple faster, I am happy. If some of my posts here cause a few people at Maplesoft to cringe now and then, well, that certainly won't make me lose any sleep...
I know Joe has been using Maple a long time, but I have been using Maple a LONG time! I first typed 'maple' in the fall of 1985, and Maple 4.0 came up. When I bought the manual in the store (which I still have), that was for Maple 3.3.
I was so taken with Maple that, after taking the symbolic computation course at the University of Waterloo (taught by George Labahn), I worked hard at getting a job with a company then called Waterloo Maple Software Inc. I started with them in 1991 (I was the one and only GUI programmer then! I wrote 80% of the first version of the Windows GUI, and some of the ideas I used there are still in the current GUI), before I moved to being the whole Math Group a year and a half later. My first coop student is now the head of the Kernel Group, and my second coop student is now the VP R&D. At that time, 100% of the 'math development' was still done in the research groups at various universities. My first year or so, all I did was bug fixing. I highly recommend it as a great way of learning just about any system inside-and-out.
I won't go into the rest of my Maple history (the above only gets me to 1993!), maybe some other time.
The thing to remember is that I was steeped in Maple for years. I once estimated that I have personally read/reviewed about 600Kloc of Maple's roughly 1 million lines of (maple) code. I still use Maple all the time to get my own research done [and I complain when it slows me down because I know it can be better].
I had to learn a lot about Maple the hard way. If my posting here helps a few people learn Maple faster, I am happy. If some of my posts here cause a few people at Maplesoft to cringe now and then, well, that certainly won't make me lose any sleep...
