I will try to give some hints that might help you. I'm not going to give a lot of very formal notes; if you wish you can read some advanced texts. One can try to find some definitions. In Maple11, one can issue the help-query, ?closedform , and get a somewhat helpful definition. Also of interest might be this link, and this link. The second of those two links mentions a pertinent notion. Suppose that one arrives at a function of one variable, which has no closed form solution (say, under a finite number of arithmetic operations). Suppose further that it can be approximated numerically, plotted, and even shown to truly be a single-valued function. So, why not give it a name, and learn to treat it like an old friend. How much different from this is our use of ln(), or sin(), or perhaps even sqrt()? Axel mentioned erf(). Lots of "special functions" could be placed in such a category. People feel comfortable with some of them, even without rigourous formal definitions for them -- I suspect mostly because of familiarity. Other links that might interest you are definitions for elementary functions, and special functions. I like sin(), as an interesting example. Sure, you may be able to find a power series to represent it as an infinite sum of terms. But as a polynomial with finitely many terms? No. Yet people are comfortable with. It has its own button on calculators. And, interestingly, we can do all sorts of useful conversions and computations and simplifications using all the known trigonometric identities. Isn't that fascinating, that we can do exact computations and manipulations of expressions containing sin(), even though we have no arithmetic formula (with finitely many operations) for it exactly? Now look at the Maple help-page ?evala . That refers to a whole suite or routines which can be used to investigate and compute with algebraic numbers and functions represented with the RootOf notation. The power of these evala routines alone show the usefulness of the RootOf as placeholder. acer

It is used in the Matlab package. showstat(Matlab:-TranslateName); acer

Thank you. I suspect that that is as close as I might get to the meaning in this lifetime. acer

It appears that _ans doesn't get updated after an assignment. acer

Thanks, but I find it a little difficult to believe that martingale is an acronym, in any language. The derivation of the term as used in probability (or measure theory, or stochastic processes) from the gambling term is quite established and clear I think. My query was: how did it become a gambling term, long before that? It's been a gambling term for quite a while. I recall reading Giacomo Casanova use it in excerpt from a translation of his memoirs (late 1700s). But I suspect it was in use some time before then. acer

Thanks for that link. It's still not entirely clear, though, since that page suggests that the equine accoutrements term also stems from that town. That hints, to me, of some relation between the two uses. acer

Thanks for the interesting link. I recently finished reading the sections on gambling in a translation of Gerolamo Cardano's autobiography. The shift from historic to modern should be fun. This tempts me to ask a question: does anyone here have an idea how the term martingale came to be used in gambling to refer to a class of strategies? It is also used as a term in probability theory, but that's more recent. What I'm after is the connection between the etymology of the word and its advent into gambling. There are older uses of the word, as a piece of rigging, be it for sails, horses, or dogs. But I don't see how to get from rigging to gambling. And, since someone might want to make the joke, no, I don't suspect that it's related to bootstraps. acer

I was actually intending the inclusion of indexed RootOfs when I wrote of explicit forms for the roots. I consider a labelled RootOf to be an implicit form. I consider indexed RootOfs as explicit both because indexed roots refer to particular roots (in the case that they can be enumerated) and because they are often what solve() returns after _EnvExplicit has been set to true (for higher degree polynomials or other expressions whose enumerable roots are not found formulaically). I wouldn't know how to obtain exact (non-float) representation of just the roots less than 4, say, in my previous example without resorting to explicit indexed RootOfs. It's not clear to me how well computations using a RootOf with a bounding box would do. You mentioned the notion of labelling RootOfs with numerical tags. But I would have said that that's not what we've been discussing, as "labelled" RootOfs. So far in this discussion, I thought that we'd been using the term "labelled" as in RootOf(...,label=_L2). The numerically tagged RootOf using a numeric root-selector is a reference to a particular root which just hasn't been approximated very closely yet and which may always be further refined in future, and so seems to me to be quite explicit in reference. The RootOf specified by a bounding box range is a reference to a possible subset within a range. The RootOf with a possible subset within a bounding box is slightly odd, not truly implicit if the subset is empty or single-valued, but implicit in the way that label=name is implicit because it may designate a distinct subset of roots. The nested RootOf that my earlier example produced, of a mix of labelled and indexed RootOfs, is bad. The _EnvExplicit variable was set to true, but labelled RootOfs were returned. It's a bug, I think. acer

I was actually intending the inclusion of indexed RootOfs when I wrote of explicit forms for the roots. I consider a labelled RootOf to be an implicit form. I consider indexed RootOfs as explicit both because indexed roots refer to particular roots (in the case that they can be enumerated) and because they are often what solve() returns after _EnvExplicit has been set to true (for higher degree polynomials or other expressions whose enumerable roots are not found formulaically). I wouldn't know how to obtain exact (non-float) representation of just the roots less than 4, say, in my previous example without resorting to explicit indexed RootOfs. It's not clear to me how well computations using a RootOf with a bounding box would do. You mentioned the notion of labelling RootOfs with numerical tags. But I would have said that that's not what we've been discussing, as "labelled" RootOfs. So far in this discussion, I thought that we'd been using the term "labelled" as in RootOf(...,label=_L2). The numerically tagged RootOf using a numeric root-selector is a reference to a particular root which just hasn't been approximated very closely yet and which may always be further refined in future, and so seems to me to be quite explicit in reference. The RootOf specified by a bounding box range is a reference to a possible subset within a range. The RootOf with a possible subset within a bounding box is slightly odd, not truly implicit if the subset is empty or single-valued, but implicit in the way that label=name is implicit because it may designate a distinct subset of roots. The nested RootOf that my earlier example produced, of a mix of labelled and indexed RootOfs, is bad. The _EnvExplicit variable was set to true, but labelled RootOfs were returned. It's a bug, I think. acer

Having set _EnvExplicit to true, I'd prefer to be able to evalf a result -- if not immediately then at some point further in a hybrid symbolic/numeric computation -- without having to call allvalues as well. Hence, S1, as returned below, is not so useful to me. eqn := 9*x^18-18876*x^16+16529689*x^14-7837385864*x^12 +2181959049699*x^10-361775198334748*x^8 +34591757568218862*x^6-1749887233151574528*x^4 +39011320654172764689*x^2-244636361793658185164: _EnvExplicit := true; S1 := [solve(eqn,x)]; S2 := map(allvalues,S1); There may be examples with weak behaviour, for both mechanisms. But one may be more generally weak than the other. I guess that I see what you mean, SortOf, about implicit representations being more computationally effective. But suppose that one wanted only the roots less than 4, in the above example. Does that not bring a need for them in explicit form? I wonder whether the Maple library itself makes good use of labelled RootOfs. acer

Having set _EnvExplicit to true, I'd prefer to be able to evalf a result -- if not immediately then at some point further in a hybrid symbolic/numeric computation -- without having to call allvalues as well. Hence, S1, as returned below, is not so useful to me. eqn := 9*x^18-18876*x^16+16529689*x^14-7837385864*x^12 +2181959049699*x^10-361775198334748*x^8 +34591757568218862*x^6-1749887233151574528*x^4 +39011320654172764689*x^2-244636361793658185164: _EnvExplicit := true; S1 := [solve(eqn,x)]; S2 := map(allvalues,S1); There may be examples with weak behaviour, for both mechanisms. But one may be more generally weak than the other. I guess that I see what you mean, SortOf, about implicit representations being more computationally effective. But suppose that one wanted only the roots less than 4, in the above example. Does that not bring a need for them in explicit form? I wonder whether the Maple library itself makes good use of labelled RootOfs. acer

Thanks for the input. I think that these are some cases where either the documentation (?solve,details) is lacking or misleading, or there is a weakness in the behaviour. An example of weakness in the behaviour would be this case, in which the single RootOf in the result represents roots of a univariate polynomial of degree less than four, and for which _EnvExplicit is not 'false', but for which a labelled RootOf is returned instead of the small number of finite solutions. I'm just repeating that above, so that someone will take notice and record bugs. I would also be very interested in hearing expert opinion on the relative merits of _EnvExplicit=true vs allvalues(). The fact that one requires manual action after the fact, for each solving, seems a clear difference. But are there others? Do other routines ever make use of the higher-level setting of _EnvExplicit (in the way that int() now sometimes uses _EnvAllSolutions to trigger piecewise results) for internal computation decisions? Is allvalues robust? And so on. acer

Thanks for the input. I think that these are some cases where either the documentation (?solve,details) is lacking or misleading, or there is a weakness in the behaviour. An example of weakness in the behaviour would be this case, in which the single RootOf in the result represents roots of a univariate polynomial of degree less than four, and for which _EnvExplicit is not 'false', but for which a labelled RootOf is returned instead of the small number of finite solutions. I'm just repeating that above, so that someone will take notice and record bugs. I would also be very interested in hearing expert opinion on the relative merits of _EnvExplicit=true vs allvalues(). The fact that one requires manual action after the fact, for each solving, seems a clear difference. But are there others? Do other routines ever make use of the higher-level setting of _EnvExplicit (in the way that int() now sometimes uses _EnvAllSolutions to trigger piecewise results) for internal computation decisions? Is allvalues robust? And so on. acer

In Maple 11, see this help-page, for the modular approach, ?LinearAlgebra,Modular,IntegerLinearSolve I do not believe that the above implementation handles sparse rational systems in any special way, and if that's the case then your huge system will be far too much for it. For your huge sparse integer system, you may be able to use another piece of software named LinBox. You might even be able to use their Maple-LinBox Package to solve it from within Maple. It seems that this would require a Linux system. acer

You can use sort() for this. Eg, tab:=table([1,2,3,4,5,6,7,8,9,10]); indices(tab); op(sort([indices(tab)],(a,b)->op(a)>op(b))); It's not clear how an "automatic" sorting would be able to please everyone. T:=table([a=red,-19=heavy,grass=14]); indices(T); One user's notion of how to sort the indices of T might not match some other user's notion. acer