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