Re: an issue of consistency
- To: mathgroup at smc.vnet.net
- Subject: [mg112399] Re: an issue of consistency
- From: Andrzej Kozlowski <akoz at mimuw.edu.pl>
- Date: Tue, 14 Sep 2010 05:13:30 -0400 (EDT)
This is a little strange but it is certainly a more sensible answer than the one I got when I reported my observation. It suggests that Graphics does not automatically convert all numeric arguments into approximate numbers but only does so in certain cases. Borrowing from your example, we see that:
Graphics[Point[{0, Log[Pi]}]]
works
while
Graphics[Point[{0, ProductLog[1]}]]
does not.
The "special cases" include most common numeric quantities, even transcendental numbers such as E^Pi and all algebraic numbers but not, for example, Root[#^5 - #^3 - E &, 1]. Well, OK, I guess this is an explanation of sorts though it leaves more puzzles unsolved than it answers. Presumably there must be some reason why Graphics doesn't just apply N to all of its arguments? It escapes me at this time but at least it seems clear that the reason why some symbolic expressions are automatically converted to numerical ones by Graphics and others has nothing to do with their mathematical nature (e.g. E^Pi is transcendental).
Andrzej Kozlowski
On 13 Sep 2010, at 09:13, Gianluca Gorni wrote:
>
> 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 probabl=
y
>> some kind of subtle bug that b doesn't get converted. Other kinds of exa=
ct
>> 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
>>
>>
>>
>>
>
>