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

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

By the by, should all three branches in the following have the same color (and style, if styles were specified)? Plot[x /. Solve[x^2 + x - 1/Sqrt[x + a] == 1, x], {a, 2, 4}] In this case Solve gives FIVE solutions: Solve[x^2 + x - 1/Sqrt[x + a] == 1, x] {{x -> Root[-1 + a + (1 - 2 a) #1 + (-2 - a) #1^2 + (-1 + 2 a) #1^3 + (2 + a) #1^4 + #1^5 &, 1]}, {x -> Root[-1 + a + (1 - 2 a) #1 + (-2 - a) #1^2 + (-1 + 2 a) #1^3 + (2 + a) #1^4 + #1^5 &, 2]}, {x -> Root[-1 + a + (1 - 2 a) #1 + (-2 - a) #1^2 + (-1 + 2 a) #1^3 + (2 + a) #1^4 + #1^5 &, 3]}, {x -> Root[-1 + a + (1 - 2 a) #1 + (-2 - a) #1^2 + (-1 + 2 a) #1^3 + (2 + a) #1^4 + #1^5 &, 4]}, {x -> Root[-1 + a + (1 - 2 a) #1 + (-2 - a) #1^2 + (-1 + 2 a) #1^3 + (2 + a) #1^4 + #1^5 &, 5]}} However: Cases[Plot[ x /. Solve[x^2 + x - 1/Sqrt[x + a] == 1, x], {a, 2.5, 2.7}], _Line, Infinity] // Length 3 There are three lines; there's no reason Plot could not assign colors and styles to them. (Although, perhaps, we couldn't know which branches would match which colors, a priori.) Bobby On Fri, 01 Aug 2008 11:00:34 -0500, Andrzej Kozlowski <akoz at mimuw.edu.pl> wrote: > 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}] > > and > > 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 Mathematica. > > > 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 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 >> > > -- DrMajorBob at longhorns.com