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: [mg90973] Re: [mg90956] Re: [mg90947] When is a List not a List?
  • From: AES <siegman at>
  • Date: Fri, 1 Aug 2008 03:00:35 -0400 (EDT)
  • References: <>

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

  • Prev by Date: Re: Performance of Array Addition
  • Next by Date: Re: Re: When is a List not a List?
  • Previous by thread: Re: When is a List not a List?
  • Next by thread: Re: Re: When is a List not a List?