The semantics of FromInert is in some sense easy: it is simply 'denotation', in the sense of denotational semantics. In other words, it takes a representation of a term and returns a term. ToInert is defined as being its pseudo-inverse. Pseudo because the only equations that are guaranteed to hold is that for TF := ToInert@FromInert and FT := FromInert@ToInert then 1) FT is operationally equivalent to the identity (but is not necessarily equal to it) 2) FT and TF are both idempotent (ie FT@FT = FT and TF@TF = TF) Basically, one round-trip may modify the routine (but not its meaning), while 2 or more round-trips do nothing at all (is the identity). The harder part of doing this is to carefully describe the "type" of expression that is the output of ToInert (and the input to FromInert). It is very closely related to the DAG representation internal to Maple (documented in an appendix to the advanced programming guide) but modified a bit for programming convenience.

Frustrating isn't it? You are quite right: Maple is in fact substantially more powerful and has a fair bit more functionality than what is actually documented. At least Maple's source and functioning is mostly visible, so that those willing to dig are amply rewarded. Too bad most of Maplesoft's customers can't more easily benefit from some of that hard work done by the developers.

The task is not that difficult - unlike full "pretty-printing", which is massively difficult. Nevertheless, it would be somewhat time-consuming, as there are a fair number of cases to deal with. However, by peeking at the code for the latex command itself, as well as that for the MathML conversion (the content part, not the display part, which is at a much lower level than LaTeX) should make it relatively straightforward. The biggest problem is one of person-hours. While I would love to work on this [it would be fun], I certainly don't have any serious time to devote to this. But if someone is willing to put in the development hours, I can help with the architecture and design.

The latex command is ancient. Worse, it was written by someone who thought they "knew better" about typesetting than LaTeX (yeah, right). So the latex commands produces all sorts of hard-coded spacing and font changes, when clearly that's just bogus. This code was updated some in the recent past, but not nearly enough. Of course, reading between the lines of the marketing stuff, you shouldn't hold your breath for improvements in this area -- like Wolfram Research some years ago (anyone remember Publicon???), and IBM before that (TeX Explorer), Maplesoft seems to think that it knows more than Donald Knuth and Leslie Lamport on the topic of typesetting.

LaTeX (and TeX) were designed to solve exactly those problems. Maple was designed as a way to make mathematical computations simpler and easier (and it is good at it too). The 'other' features that Maple also has are less well-honed than its core features -- and still has many years to go before it can compete with products (LaTeX, etc) that are specially designed. This is not uncommon: Word still can't touch PageMaker for doing things like brochures. Not can 'Paint' beat PhotoShop for editing pictures. The fact that it is "doable" does not mean that it is a good idea to do it.

LaTeX (and TeX) were designed to solve exactly those problems. Maple was designed as a way to make mathematical computations simpler and easier (and it is good at it too). The 'other' features that Maple also has are less well-honed than its core features -- and still has many years to go before it can compete with products (LaTeX, etc) that are specially designed. This is not uncommon: Word still can't touch PageMaker for doing things like brochures. Not can 'Paint' beat PhotoShop for editing pictures. The fact that it is "doable" does not mean that it is a good idea to do it.

As far as I know, there is no way to 'trap' warnings, or turn them into errors (like in most other languages).

I am an extremely heavy user of ToInert/FromInert. However, toTree and fromTree are incomparably simpler [and thus relatively weaker]. One can easily understand these functions and what they do. A full understanding of ToInert/FromInert takes months.

That is because you can give a parametric definition to plot. How to do that? Why, by giving a list with 3 elements [f(t), g(t), t=a..b], that's how. Hum, rather like the output of BSplineCurve! That's not a coincidence at all. In fact, parametric plot came first, and then some clever designer [I don't know who in this case, but I do have a guess] reused that same data-structure for the output of BSplineCurve, so as to obtain automatic composability!

That is because you can give a parametric definition to plot. How to do that? Why, by giving a list with 3 elements [f(t), g(t), t=a..b], that's how. Hum, rather like the output of BSplineCurve! That's not a coincidence at all. In fact, parametric plot came first, and then some clever designer [I don't know who in this case, but I do have a guess] reused that same data-structure for the output of BSplineCurve, so as to obtain automatic composability!

I completely agree with you Doug. Unfortunately, you seem to be in the minority. I have seen too many teachers who are not quite a forthright with their students. Another issue is Maplesoft's (and Wolfram Research's for that matter) own marketing can be seriously flawed here. The advantages of Maple are way over-hyped, leading to ridiculous user expectations which are obviously and quickly dashed as soon as they try to seriously use the product. I use Maple all the time - it is a very serious time saver. But it is just a really good tool, it can not and should not replace thinking.

I completely agree with you Doug. Unfortunately, you seem to be in the minority. I have seen too many teachers who are not quite a forthright with their students. Another issue is Maplesoft's (and Wolfram Research's for that matter) own marketing can be seriously flawed here. The advantages of Maple are way over-hyped, leading to ridiculous user expectations which are obviously and quickly dashed as soon as they try to seriously use the product. I use Maple all the time - it is a very serious time saver. But it is just a really good tool, it can not and should not replace thinking.

Thank you - that was the real problem, and I did not notice it. So it's not a bug, it is a scoping issue (which I knew about, but did not spot). I really ought to have used unapply instead of an inline function. I know all this stuff, and still I got caught. Either I am going gaga, or these evaluation rules are sub-optimal.

Thank you - that was the real problem, and I did not notice it. So it's not a bug, it is a scoping issue (which I knew about, but did not spot). I really ought to have used unapply instead of an inline function. I know all this stuff, and still I got caught. Either I am going gaga, or these evaluation rules are sub-optimal.

I was using classic when I did that. Perhaps that makes a difference?