MathGroup Archive 2008

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

Search the Archive

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

  • To: mathgroup at
  • Subject: [mg90988] Re: [mg90956] Re: [mg90947] When is a List not a List?
  • From: Andrzej Kozlowski <akoz at>
  • Date: Sat, 2 Aug 2008 03:25:41 -0400 (EDT)
  • References: <> <16711231.1217501820078.JavaMail.root@m08> <op.ue54zeqq2c6ksp@bobbys-imac> <21465667.1217530845998.JavaMail.root@m08> <op.ue6m0tdk2c6ksp@bobbys-imac> <32926975.1217563920588.JavaMail.root@m08> <op.ue7o67wi2c6ksp@bobbys-imac> <>

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


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  

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

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