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
>
>
>
>