Services & Resources / Wolfram Forums / MathGroup Archive
-----

MathGroup Archive 2008

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

Search the Archive

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

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

By the by, should all three branches in the following have the same color  
(and style, if styles were specified)?

Plot[x /. Solve[x^2 + x - 1/Sqrt[x + a] == 1, x], {a, 2, 4}]

In this case Solve gives FIVE solutions:

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

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

However:

Cases[Plot[
    x /. Solve[x^2 + x - 1/Sqrt[x + a] == 1, x], {a, 2.5, 2.7}], _Line,
    Infinity] // Length

3

There are three lines; there's no reason Plot could not assign colors and  
styles to them. (Although, perhaps, we couldn't know which branches would  
match which colors, a priori.)

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: When is a List not a List?
  • Previous by thread: Re: Re: When is a List not a List?
  • Next by thread: Re: Re: When is a List not a List?