MathGroup Archive 2010

[Date Index] [Thread Index] [Author Index]

Search the Archive

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



  • Prev by Date: polynomial long division using Series[] and changing polynomial default
  • Next by Date: Inconsistent behaviour of Integrate
  • Previous by thread: Re: an issue of consistency
  • Next by thread: Re: an issue of consistency