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.