Re: an issue of consistency

*To*: mathgroup at smc.vnet.net*Subject*: [mg112390] Re: an issue of consistency*From*: Gianluca Gorni <gianluca.gorni at uniud.it>*Date*: Mon, 13 Sep 2010 03:13:27 -0400 (EDT)

A couple of years ago I reported to Wolfram the following example, where a special function inside PlotRange generates an error: Graphics[Point[{0, 0}], PlotRange -> {0, ProductLog[1]}] The response was this: > This is as designed. Unless it is one of the special functions used by > Mathematica in numerical evaluation (like Gamma functions, log, etc), it > will not be evaluated by default. Mathematica knows what you mean, but will > generate an error nonetheless. To use such functions, just wrap N around > them, as follows: > Plot[x, {x, 0, 1}, PlotRange -> {0, N[ProductLog[1]]}] Gianluca Gorni On 11/set/2010, at 11.46, David Park wrote: > I would say it is not only inconsistent, but an outright bug because > graphics routinely converts exact expressions to approximate numbers and > Root objects are supposed to be exact. > > Sometimes this occurs simply by mixing the exact expression with an > approximate number as in the following (which works): > > b = Root[#1^5 - # + Log[2] &, 1]; > Plot[b + x, {x, 0, 2}] > > But when an exact number appears in a list unmixed with an approximate > number, such as in Point, Line, Rectangle or Circle, then it doesn't get > converted by the mixing mechanism and WRI must apply N (or something > equivalent) in their graphics algorithms. It is inexplicable and probably > some kind of subtle bug that b doesn't get converted. Other kinds of exact > numbers are converted. > > In numerical graphics algorithms it's a bug. > > > David Park > djmpark at comcast.net > http://home.comcast.net/~djmpark/ > > > From: Andrzej Kozlowski [mailto:akoz at mimuw.edu.pl] > > > This post is about a mild dispute I have been having with Wolfram's > technical support. It concerns behaviour that I see as inconsistent and > Technical Support seems to insist otherwise. I would not claim that it > actually represents a "bug" but I discovered it in a "real life" > situation, it was unexpected and took a while to see what the cause of > it was. > In any case, I am not writing to "complain", but to find out if anyone > can justify the behaviour that I am going to describe as "consistent". > Technical Support thinks it is, but I can't understand their reasoning. > > Consider the two "root object" numbers: > > a = Root[#1^5 - # + 1 &, 1]; > b = Root[#1^5 - # + Log[2] &, 1]; > > The first is an algebraic number, the second is not, but they are both > real numbers which can be computed to arbitrary precision, e.g. > > N[{a, b}, 10] > > {-1.167303978,-1.127288474} > > O.K. now compare this: > > Graphics[Point[{{Root[#1^5 - # + 1 &, 1], 0}}]] > > and this: > > Graphics[Point[{{Root[#1^5 - # + Log[2] &, 1], 0}}]] > > In the first case Graphics forces N to be automatically applied while in > the second case one needs to do so manually: > > Graphics[Point[{{Root[#1^5 - # + Log[2] &, 1], 0}}]]//N > > This seems to me to be inconsistent, or at least I do not know of nay > obvious reason why the first number being algebraic and the second > number not being so should make any difference to how they are treated > by Graphics. Technical Support claims otherwise but is unable to provide > a reason that I can understand. Can anyone else? > > Andrzej Kozlowski > > > >