Re: Re: When is a List not a List?
- To: mathgroup at smc.vnet.net
- Subject: [mg90973] Re: [mg90956] Re: [mg90947] When is a List not a List?
- From: AES <siegman at stanford.edu>
- Date: Fri, 1 Aug 2008 03:00:35 -0400 (EDT)
- References: <200807310656.CAA07700@smc.vnet.net>
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.