There are actually very few Maple routines which are ``polymorphic'' in the sense of (only) working on integers and polynomials, and nothing else. mod is one such, and that is indeed a real source of frustration for many.
I am sure that there are many different ways to deal with this, but the one I would use would be to use mod indirectly. More precisely, I would define
mymod := proc(num,p)
`if`(num::integer, `mod`(num,p), 'procname(args)')
end proc
This delays evaluation just long enough so that most computations (like the ones above) will succeed.
I think the biggest obstacle in achieving that goal is quite fundamental as it is one of paradigm. The current GUI is quite WYSIWYG (if you ignore the hidden regions and the havoc they can create if used in ways they were not meant to - which is not all that well documented, but I digress). Right, so the GUI is meant to be used in a WYSIWIG fashion. But Knuth's fundamental idea with WEB and CWEB is to take a much more declarative view of a program. As far as best practice goes, you are supposed to separate your meaningful content from its display methods. Weaving is what gives you the end results, be that an executable program or a viewable document. Similarly, well-done LaTeX documents cleanly separate display and semantics (through the judicious use of style files).
In a way, one of the really good tools for this was Word 3! In the early 80s, Word had a really nice outline mode and if you stuck to editing in that mode, and used style sheets well, you could get a graphical editor for structured documents. But then they went totally WYSIWYG with Word 95, and the outline mode got skewered.
At least the XML/XSLT people got that separation right. The XML is all content, and XSLT, as horrible a language as it is, is the right way to render an XML document. Modern web pages (with tons of CSS2) do that too. And guess what? Dreamweaver, which is an otherwise fantastic HTML editor, starts to break down when editing such a "modern" set of web pages. Oh, it can still do it, but all the WYSIWYG niceties go away, and you're mostly left with a clumsy text editor!
Notice how there is no indentation to all the posted code? And, on my screen at least (using Firefox but at 1600x1200 resolution on a big monitor), the font used for the input is fine, but the output is harder to read. The particular kind of italics is fuzzy.
There are also all sorts of other problems: look at the poor line-breaking. In particular look at the lines containing the two K(80). Nobody would ever line-break after that open < ! The visible width of the output region is quite narrow, and it is fixed-width, unlike the rest of the post, which is a pain. Take a look at how := is rendered; the dots on the colon are not properly aligned with the equal sign, and they are tiny. It is very difficult to mistake a := with an =. I could also get into the kerning issues, the space issue between parentheses, and so on.
As far as I am concerned, the post was actually easier to read before your conversion, even though it did have one problem (the pre-formatted text was too wide to see properly on my laptop).
a classical literate programming tool is not mandatory: instead of producing TeX code, it should be far better to produce Maple sheets
Here we disagree. It took several geniuses a number of years to come up with something with the output quality of LaTeX (I include TeX and MetaFont in there). The difficulty of proper typesetting is highly under-estimated by most, with the end results being predictably sub-optimal.
This is not to say that, eventually, Maple will not be up to the task! However, Maple of 2007 still cannot compete for output quality with TeX of 1990. It will take a few more years of concentrated effort on typesetting before that happens. In the meantime, I will take my LaTeX output, thank you very much!
I have looked at this. My take on it is that if you move away from pure expressions are representations for your answers, then you can indeed keep on going, even for more complex problems.
If you are curious, see my paper
Partial Evaluation and Residual Theorems in Computer Algebra with (my former student) Mike Kucera. There is a more recent version of the technical Partial Evaluation details (published at PEPM 2007) that I should put up on my web page too. Writing a partial evaluator for (most of) Maple was fun and challenging!!!
From the kernel, you can change arbitrary Maple code. You can even change the worksheet you are in (see the Worksheet and DocumentTools packages).
But it may well be that this is new behaviour, that undo used to be more "generous". It will be interesting to find out.
Unfortunately, since any execution can do arbitrary changes, and this cannot be (reliably) predicted or controlled, the only safe thing to do is to disable undo after any execution, even if it failed.
This is not very user-friendly, agreed. But it is one of those restrictions inherited by relying on an older system architecture.
There are routines in StringTools, as well as sscanf which could be used for doing this.
Rather too bad that one never gets official confirmation of these things. I would much rather know that a bug is a bug, than to be left in the dark.
For those of use who are not emacs-savvy,
vim has a decent maple-mode. I submitted some upgrades to it, which are now part of the standard distribution. I have a few more to submit (some of which are courtesy of some Maplesoft people, who also use vim), but it has been difficult to find the time.
Of course I would love to use
literate programming tools with Maple. I have been meaning to adapt with
funnelweb or
noweb for this task, but again time pressures have not allowed me to do so (yet).
Of course I would also like a nice javadoc-like infrastructure for my APIs (Maplesoft apparently has this tool internally now, or so I've heard). And I would really like something like
JUnit for simple testing purposes, and
QuickCheck when things get more complex. Here I know that Maplesoft has some nice tools (you can see some of them leaking out as
TestTools and
verify). And I know of more, since I
wrote some of those tools while I was at Maplesoft!
isolve is the command for finding integer solutions. But it does not handle constraints (ie like specifying positivity).
There also seem to be some options to some of the commands in the Optimization for ILP, that might work
The only thing that can be undone are pure GUI-side edits. Whenever you "execute" something, that goes off to Maple's kernel, and that is another process with its own state, which is not undo-able. Is this what you are encountering?
Take a look at
LtU, it is a programming languages community blog. So a lot of code, in a lot of different languages, gets posted there. They have already "solved" this problem, and they use Drupal too. Might as well get in touch with its maintainers before reinventing the wheel!
Without something more explicit, no one will really be able to help you. Usually you get the above message when you have created an (unintentional) infinite loop, or when such an infinite loop is caused by a Maple bug.
Calculators serve a very different purpose than a full-on computer. I have already touched upon this topic in
this comment on Maple for PDAs.
Basically, the issue boils down to one of screen real estate. On a calculator, you have very little. And if your user interface does not respect that, your product ends up being awful.
Take a good look at the difference in user interfaces between your iPod and iTunes. They are well-adapted to their respective sizes. So a calculator is still useful for those computations where both the question and the answer fit on a very small screen.
