I don't have Maple 10 installed; so I cannot play with this. Does increasing numpoints ameliorate things? (In any case, though, this seems to be an implementation issue, rather than a specification issue.)

I don't have Maple 10 installed; so I cannot play with this. Does increasing numpoints ameliorate things? (In any case, though, this seems to be an implementation issue, rather than a specification issue.)

The first desideratum of a plot is to accurately represent its input. So consider a case where the function is continuous, but rapidly changing. As a simple example, consider plots[densityplot](piecewise(x < y-0.01, 2, x < y+0.01, 1, 0), x = 0..1, y = 0..1) In such instances, densityplot no longer gives an accurate representation of the function. Hence a user who does not a priori know what the function looks like could well be misled.

The first desideratum of a plot is to accurately represent its input. So consider a case where the function is continuous, but rapidly changing. As a simple example, consider plots[densityplot](piecewise(x < y-0.01, 2, x < y+0.01, 1, 0), x = 0..1, y = 0..1) In such instances, densityplot no longer gives an accurate representation of the function. Hence a user who does not a priori know what the function looks like could well be misled.

Would someone from Maplesoft be willing to comment on this? The current behavior might be quite nice to have sometimes, but it is often not what is wanted. Moreover, it is unexpected. Perhaps there could be an option to control whether there is smoothing?

Would someone from Maplesoft be willing to comment on this? The current behavior might be quite nice to have sometimes, but it is often not what is wanted. Moreover, it is unexpected. Perhaps there could be an option to control whether there is smoothing?

A programmer's dream: "Every bug is a feature in disguise!" That would surely make life easier for developers. The behavior here, though, is not what is going to be expected by almost all users; nor would there seem to be any user benefit for it. Claiming that the behavior is not a bug is a real stretch. Also, what about this: Pi^numtheory:-pi(a) It seems reasonable to want to display that in 2-D; after all, Maple can. Here, however, is how that displays with <maple> tages wrapped around it: 2^Pi^numtheory:-pi(a)

Ahh, sorry about the lack of clarity in my earlier comment. And much thanks for confirming that there is a problem with ErrorPlot.

I do not have a form (as my post indicated); so Statistics[Regression] is not really what I want. Indeed, what is especially nice about lowess is that it does not presuppose a form. Would it be feasible to return the lowess curve as a piecewise function?

I do not have a form (as my post indicated); so Statistics[Regression] is not really what I want. Indeed, what is especially nice about lowess is that it does not presuppose a form. Would it be feasible to return the lowess curve as a piecewise function?

I am running Maple 11.01 under Windows XP. Here is an example of what happens, using strings. > restart; > with(Statistics): > ErrorPlot(<1,2,3>, color = "blue"); Error, (in Statistics:-ErrorPlot) argument 'color = "blue"' invalid: rhs should be of type {specfunc(anything, {COLOR, COLOUR}), list({specfunc(anything, {COLOR, COLOUR}), name}), range({specfunc(anything, {COLOR, COLOUR}), name}), name} This does work with single quotes, and in fact that is the only way to get it to work—contrary to your message.

The following work as described. plot(sin, 0..1, color= "blue") plot(sin, 0..1, color= "Blue") The following plot, but with a red line. plot(sin, 0..1, color= 'blue') plot(sin, 0..1, color= 'Blue') I assume that the color input is just ignored, because the color needs to be a string. I think it might be better to not ignore the input, but to issue a warning (or even evoke an error). The following evoke errors. ErrorPlot(<1,2,3>, color= "blue") ErrorPlot(<1,2,3>, color= "Blue") ErrorPlot(<1,2,3>, color= 'Blue') The following works. ErrorPlot(<1,2,3>, color= 'blue') This behavior is confusing.

Your method seems to work well, but I am a confused about one aspect. According to ?solve,details, variables in the solution whose names are prefixed by “_NN” take non-negative integer values. Consistent with that, about(_NN1) says AndProp(integer,RealRange(0,infinity)). So I would not have expected to use eval with _NN1=-1.

It may be that sets are more useful mathematically when considered as unordered. ... But that is not the primary cause of why sets may appear to some people to be unordered in Maple.

Sets in mathematics are unordered. As a Maple user, I want, hope, and expect Maple to be as close to mathematics as feasible.

In fact, sets are ordered in Maple. They are ordered by the addresses in memory of the members.

What are "addresses in memory"? Presumably, they are something to do with how Maple implements sets. As a Maple user, then, I would prefer to not have to learn about such arcane implementation details. (Moreover, someone who did know what addresses in memory were would perhaps ask what would happen if Maple were implemented on a computer that had associative memory, instead of random access memory.) Another argument to support the claim that sets are ordered in Maple is that when S is a set, then S[i] is defined (for i≤nops(S)). Having this definition might be considered to be an error. For myself, I think of it as syntactic sugaring—a convenience to save writing L:=[op(S)], and then looping over L[i], when I want to loop over the elements of a set. Of course, some of the above is a fantasy: the fantasy that Maple is a corporeal realization of pure mathematics. Yet I suspect that most Maple users would like that fantasy realized as much as practicable. And, nicely, Maple often does an excellent job of allowing that. Your claim based on implementation details might be the perspective of an implementer. I do not agree that it is desired or necessary for the perspectives of most users.

> restart: -3: a: s := 11 - 17*v^2*w^3*x^4 - 3*a^2*w^3*x^4 + 1: lcoeff(s); > # The above may produce either -3 or -17, if repeated over and over.

This is fine. Even better might be to make it undefined.

Now let's move on to this: "That order [of additions when `add` acts on a maple set of floats] is inherently undefined; so the add is inherently irreproducible, in principle." What's the justification for claiming that? Why could not the members be ordered in a manner reproducible across sessions? I take the "in principle" to mean that it could never be made to work in maple.

You are right that the add is not inherently irreproducible. E.g. add(expr,i=SF) could be defined as equivalent to add(expr,i=sort(SF,(x,y)->(abs(x)<abs(y)) or (abs(x)=abs(y) and x<y))) or similar. That would give reproducibility, as well as greater accuracy. Could something similar be done everywhere? (I am not advocating any change, just wondering.) By "in principle", I mean that the differences are insignificant in most applications. In general, floats co-exist uneasily with the dream that Maple is a manifestation of mathematics. Very few users want to deal with numerical problems. But in real life, if I am using floats, I sometimes have to (in any computer system; nicely, less so in Maple).

It may be that sets are more useful mathematically when considered as unordered. ... But that is not the primary cause of why sets may appear to some people to be unordered in Maple.

Sets in mathematics are unordered. As a Maple user, I want, hope, and expect Maple to be as close to mathematics as feasible.

In fact, sets are ordered in Maple. They are ordered by the addresses in memory of the members.

What are "addresses in memory"? Presumably, they are something to do with how Maple implements sets. As a Maple user, then, I would prefer to not have to learn about such arcane implementation details. (Moreover, someone who did know what addresses in memory were would perhaps ask what would happen if Maple were implemented on a computer that had associative memory, instead of random access memory.) Another argument to support the claim that sets are ordered in Maple is that when S is a set, then S[i] is defined (for i≤nops(S)). Having this definition might be considered to be an error. For myself, I think of it as syntactic sugaring—a convenience to save writing L:=[op(S)], and then looping over L[i], when I want to loop over the elements of a set. Of course, some of the above is a fantasy: the fantasy that Maple is a corporeal realization of pure mathematics. Yet I suspect that most Maple users would like that fantasy realized as much as practicable. And, nicely, Maple often does an excellent job of allowing that. Your claim based on implementation details might be the perspective of an implementer. I do not agree that it is desired or necessary for the perspectives of most users.

> restart: -3: a: s := 11 - 17*v^2*w^3*x^4 - 3*a^2*w^3*x^4 + 1: lcoeff(s); > # The above may produce either -3 or -17, if repeated over and over.

This is fine. Even better might be to make it undefined.

Now let's move on to this: "That order [of additions when `add` acts on a maple set of floats] is inherently undefined; so the add is inherently irreproducible, in principle." What's the justification for claiming that? Why could not the members be ordered in a manner reproducible across sessions? I take the "in principle" to mean that it could never be made to work in maple.

You are right that the add is not inherently irreproducible. E.g. add(expr,i=SF) could be defined as equivalent to add(expr,i=sort(SF,(x,y)->(abs(x)<abs(y)) or (abs(x)=abs(y) and x<y))) or similar. That would give reproducibility, as well as greater accuracy. Could something similar be done everywhere? (I am not advocating any change, just wondering.) By "in principle", I mean that the differences are insignificant in most applications. In general, floats co-exist uneasily with the dream that Maple is a manifestation of mathematics. Very few users want to deal with numerical problems. But in real life, if I am using floats, I sometimes have to (in any computer system; nicely, less so in Maple).