       Re: Re: When is a List not a List?

• To: mathgroup at smc.vnet.net
• Subject: [mg90991] Re: [mg90956] Re: [mg90947] When is a List not a List?
• From: DrMajorBob <drmajorbob at att.net>
• Date: Sat, 2 Aug 2008 03:26:17 -0400 (EDT)
• References: <200807310656.CAA07700@smc.vnet.net>
• Reply-to: drmajorbob at longhorns.com

The second evaluation could/should result in a plot of 7 functions in 7
colors, not 3, since:

x /. Solve[x^3 + x - 1/Sqrt[x + a] == 1, x]

{Root[-1 +
a + (1 - 2 a) #1 + (-2 + a) #1^2 + (1 - 2 a) #1^3 + (-2 +
2 a) #1^4 + 2 #1^5 + a #1^6 + #1^7 &, 1],
Root[-1 +
a + (1 - 2 a) #1 + (-2 + a) #1^2 + (1 - 2 a) #1^3 + (-2 +
2 a) #1^4 + 2 #1^5 + a #1^6 + #1^7 &, 2],
Root[-1 +
a + (1 - 2 a) #1 + (-2 + a) #1^2 + (1 - 2 a) #1^3 + (-2 +
2 a) #1^4 + 2 #1^5 + a #1^6 + #1^7 &, 3],
Root[-1 +
a + (1 - 2 a) #1 + (-2 + a) #1^2 + (1 - 2 a) #1^3 + (-2 +
2 a) #1^4 + 2 #1^5 + a #1^6 + #1^7 &, 4],
Root[-1 +
a + (1 - 2 a) #1 + (-2 + a) #1^2 + (1 - 2 a) #1^3 + (-2 +
2 a) #1^4 + 2 #1^5 + a #1^6 + #1^7 &, 5],
Root[-1 +
a + (1 - 2 a) #1 + (-2 + a) #1^2 + (1 - 2 a) #1^3 + (-2 +
2 a) #1^4 + 2 #1^5 + a #1^6 + #1^7 &, 6],
Root[-1 +
a + (1 - 2 a) #1 + (-2 + a) #1^2 + (1 - 2 a) #1^3 + (-2 +
2 a) #1^4 + 2 #1^5 + a #1^6 + #1^7 &, 7]}

Three of these are real-valued at a==2, just as the second plot indicates:

% /. a -> 2.

{-1.99157, 0.311967, 0.888061, -0.419459 - 1.30719 I, -0.419459 +
1.30719 I, -0.18477 - 0.963069 I, -0.18477 + 0.963069 I}

(That's why, I suppose, only 3 colors are visible in the chart.)

Two of the real solutions are spurious here, while 2 of the complex
solutions ARE correct to machine precision:

x^3 + x - 1/Sqrt[x + a] - 1 /. {x -> #, a -> 2} & /@ % // Chop

{-21.7816, -1.31534, 0, 0, 0, -1.35391 - 0.336917 I, -1.35391 +
0.336917 I}

Perhaps Reduce could help, since it allows us to restrict the domain of
the variables?

Reduce[x^3 + x - 1/Sqrt[x + a] == 1, {x, a}, Reals]

x > Root[-1 + #1 + #1^3 &, 1] &&
a == (1 - x + 2 x^2 - x^3 + 2 x^4 - 2 x^5 - x^7)/(
1 - 2 x + x^2 - 2 x^3 + 2 x^4 + x^6)

Now consider the lower limit on x:

Root[-1 + #1 + #1^3 &, 1] // ToRadicals
% // N

-(2/(3 (9 + Sqrt)))^(1/3) + (1/2 (9 + Sqrt))^(1/3)/3^(2/3)

0.682328

Since your first Plot includes x values smaller than this, the output of
Reduce is contradicted, no? (Oh, woe is me, who CAN we trust?!?)

If HoldAll were not in the picture, we could get the first plot SOMEHOW,
I'm sure... probably with

f[a_?NumericQ] := x /. Solve[x^3 + x - 1/Sqrt[x + a] == 1, x]
Plot[f[a], {a, -1, 3}]

since the same plot results now from

Plot[f[a] // Evaluate, {a, -1, 3}]

So, in my estimation, HoldAll in your example is compensating for the fact
that Solve doesn't return real solutions and doesn't identify parameter
ranges that ALLOW real solutions, neither of which seems (to me) to be a
natural responsibility for a Plot attribute. (It may be the reason this
artifact exists, however, and if so... so be it, quirkiness be damned!)

> Understanding a bit of mathematics often helps to understand Mathematica.

In light of all that, in what way have the rest of us failed to understand
"a bit of mathematics"?

Bobby

On Fri, 01 Aug 2008 11:00:34 -0500, Andrzej Kozlowski <akoz at mimuw.edu.pl>
wrote:

> Just in case I have not made my point clearly enough, I suggest
> pondering over the difference between:
>
>
> Plot[x /. Solve[x^3 + x - 1/Sqrt[x + a] == 1, x], {a, -1, 3}]
>
> and
>
> Plot[Evaluate[x /. Solve[x^3 + x - 1/Sqrt[x + a] == 1, x]], {a, -1, 3}]
>
>
> The second graph uses three colors, just as you and AES would have
> wished, but unfortunately there is a slight problem with it :it is quite
> wrong.
>
> Understanding a bit of mathematics often helps to understand Mathematica.
>
>
> Andrzej Kozlowski
>
>
>
> On 1 Aug 2008, at 17:30, Andrzej Kozlowski wrote:
>
>> Because there are lots of plots of the kind which I just sent (Plot[x
>> /. Solve[x^3 - 3 x^2 + a == 0, x], {a, -3, 5}]) but where you have
>> FindRoot or NMaximize etc., instead of Solve and the first argument
>> can't be evaluated until the value of the parameter a has been
>> supplied. There have been lots of post of this kind on this forum so
>> its kind if weird you managed to miss them all.
>>
>> Andrzej Kozlowski
>>
>>
>>
>>
>> On 1 Aug 2008, at 16:29, DrMajorBob wrote:
>>
>>> Agreed.
>>>
>>> And I'm wondering what advantage HoldAll has, in the case of Plot,
>>> since a plot can't result without evaluating the arguments?
>>>
>>> Why NOT evaluate the first argument, at least, before making style
>>> decisions/assignments?
>>>
>>> The defense that "everybody already knows this" is irrelevant to the
>>> question of how we'd LIKE Plot to behave.
>>>
>>> Naturally, we won't necessarily GET what we want... but we're entitled
>>> to say what that is.
>>>
>>> I'm trying to think how David Park's Presentations package handles
>>> such things.
>>>
>>> Bobby
>>>
>>> On Thu, 31 Jul 2008 22:33:50 -0500, AES <siegman at stanford.edu> wrote:
>>>
>>>> At 7:44 PM -0500 7/31/08, DrMajorBob wrote:
>>>>> Plot COULD assign colors after evaluation, OTOH... the fact that it
>>>>> doesn't is a design choice/artifact, not a necessity preordained by
>>>>> fate.
>>>>>
>>>>> That being so, users are entitled to find it odd at first glance.
>>>>> (Or even second... maybe third.)
>>>>
>>>> If the above is true -- and I'd suppose it is -- then I'd say it's
>>>> also very much an unfortunate, not to say flat-out *bad* design
>>>> choice or artifact.
>>>>
>>>> An innocent novice-level user creates a Plot[ ] with three curves
>>>> using the {f1, f2, f3} List form of the first argument, and discovers
>>>> that M by default assigns a different color to each curve -- a good
>>>> and helpful default design choice on M's part, I'd say.
>>>>
>>>> Maybe this novice user wants to go a bit further: Thicken certain
>>>> curves, change the Dashing, and so on.  He or she discovers the
>>>> PlotStyle option (or equivalent); learns how to do this; is happy.
>>>>
>>>> And then this user also realizes: Hey, I could plot 8 or 10 curves
>>>> this way, without having to type in f1 thru f8 by just using a Table[
>>>> ] command for the first argument and iterating over some appropriate
>>>> parameter.  A Table[ ] creates a List, right?
>>>>
>>>> So he/she does this; the 8 or 10 curves appear exactly as desired;
>>>> except the styling behavior is suddenly all screwed up.  Once again,
>>>> a classic M-style Gotcha!!! -- and a particularly nasty Gotcha:  Am I
>>>> getting this unwanted result because of the way I structured the
>>>> PlotStyle commands I used? -- or because of something mysterious with
>>>> using Table[ ]?  The coloring and so on in the default  {f1, f2, f3}
>>>> case has the nice default cycling behavior for the styling -- Why am
>>>> I not getting it now?
>>>>
>>>> Andrzej says this unfortunate result _has_ to be the case because
>>>> Plot[ ]  doesn't "pre-Evaluate" the first argument.
>>>>
>>>> Well, somehow, if the first argument is {f1, f2, f3, f4, f5, f6, f7,
>>>> f8}, Plot[ ] somehow "pre-evaluates" (lower-case pre-evaluate) this
>>>> argument at least enough to know that it's not only a List, but how
>>>> many elements that List has.  Is it somehow impossible for Plot[ ] to
>>>> know that Table will also produce a List, and to similarly
>>>> pre-evaluate how many elements that List will have?  I suspect it's
>>>> not impossible.
>>>>
>>>> And if that is indeed impossible with the PlotStyle option in Plot[ ]
>>>> then can Andrzej  explain how it _is _ possible for Plot[ ] to
>>>> somehow handle the PlotRange->All option correctly (i.e.,
>>>> identically) with either form of the first argument -- even though
>>>> that option needs to determine not only the number of curves in the
>>>> first argument, but the maximum and minimum values over all those
>>>> curves, in order to set the axes and axis Tick locations and values
>>>> for the plot.  Is just getting the number of curves and picking the
>>>> colors for them really harder than that?
>>>>
>>>> I very much like DrMajorBob's wording here:  I'll bet the coloring
>>>> problem with List vs Table is precisely "an [accidental] design
>>>> choice/artifact, not a necessity preordained by fate" -- and an
>>>> unfortunately unfortunate "design choice/artifact".
>>>>
>>>> The only things more unfortunate are (a) that M has a fair (and
>>>> increasing?) number of these Gotchas; (b) M's documentation is
>>>> substantially less helpful than it could or should be either in
>>>> diagnosing or in warning about them; and (c) it's far from clear that
>>>> anyone at WRI really recognizes these points.
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>> --DrMajorBob at longhorns.com
>>
>
>

--
DrMajorBob at longhorns.com

• Prev by Date: Re: Re: When is a List not a List?
• Next by Date: Re: Re: Re: When is a List not a List?
• Previous by thread: Re: Re: When is a List not a List?
• Next by thread: Re: When is a List not a List?