Re: Re: When is a List not a List?
- To: mathgroup at smc.vnet.net
- Subject: [mg90988] Re: [mg90956] Re: [mg90947] When is a List not a List?
- From: Andrzej Kozlowski <akoz at mimuw.edu.pl>
- Date: Sat, 2 Aug 2008 03:25:41 -0400 (EDT)
- References: <200807310656.CAA07700@smc.vnet.net> <16711231.1217501820078.JavaMail.root@m08> <op.ue54zeqq2c6ksp@bobbys-imac> <21465667.1217530845998.JavaMail.root@m08> <op.ue6m0tdk2c6ksp@bobbys-imac> <32926975.1217563920588.JavaMail.root@m08> <op.ue7o67wi2c6ksp@bobbys-imac> <97345FCA-2165-4054-A869-BA4F30AA8450@mimuw.edu.pl>
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 >