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

I have been disappointed with the Dictionary. I would agree with Jacques' comment: the definitions are not always equivalent to the meanings used by Maple itself. This is a shortcoming. I often choose Mathworld for checking definitions online. There are also problems with using the Dictionary to annotate Maple documents, a few of which I'll describe below. One problem is that the full name (or search term) of the definition does not appear within the actual page in the Dictionary within the Help system. But the search term is what the help-system needs in order to locate a definition programmatically as a link, or using the ? query mechanism. For example, open the Dictionary browser in the Standard GUI. From the top menu, select Help->Manuals,Dictionary,and more->Dictionary . Now in the help-browser (left pane) open the H alphabetic items, and select the browser entry for Hamilton's equations of motion. That should open that definition. Now, where is the no-punctuation joined-word search term? It is not in the page. It appears in my Linux window-manager's decoration of the window, but that cannot be cut & pasted. So how can I use my mouse to paste in the following? It's sad, if I cannot. ?hamiltonsequationsofmotion Now here's a second, related problem. In a Document, or text mode in a Worksheet, I can select text and right-click to get a context-menu, in which I choose Convert To->Hyperlink which pops up a small "Hyperlink Properties" window. In that window, I use the drop-down to choose "Dictionary Topic". Ok, so now, why is there no browse action enabled at this point? How does the user figure out, from here, that precisely "Definition, hamiltonsequationsofmotion" must be entered? This is unfriendly. acer

I deduced 4736 registered users by hovering over the maple leaf & number of some recently joined members whose handles appeared in the "Who's new" list. I believe that I was close to spot on, at the time I posted, and that discrepency with Will's figure was due to the later date of his posting. If you hover over Will's leaf, you'll see the number 1, which may be a good hint that it is a userid. Hovering over others' leaves shows a reasonable correlation with the stated time of membership shown on profile pages. I do not know how to easily gather all userids and handles, assuming that these guesses are close to correct. It might be possible using wget and some scripting work (which could be similar to what Will referred to by the term "scraping"). I can only imagine that the csv file posted was a snapshot of a window in time, a subset of the entire set of postings here -- possibly only those since mapleprimes left beta?! acer