Re: Re: Re: Mathematica language issues

*To*: mathgroup at smc.vnet.net*Subject*: [mg53062] Re: Re: Re: Mathematica language issues*From*: DrBob <drbob at bigfoot.com>*Date*: Wed, 22 Dec 2004 04:52:56 -0500 (EST)*References*: <cq6ega$2tb$1@smc.vnet.net> <200412211019.FAA17344@smc.vnet.net>*Reply-to*: drbob at bigfoot.com*Sender*: owner-wri-mathgroup at wolfram.com

Here's an article on the use of Unevaluated in which a WRI employee explains all. Well. Maybe he explains it all; I'm not sure yet. He explains a LOT, anyway. So... until I've gotten through his explanation, I no longer have an opinion!! http://library.wolfram.com/conferences/devconf99/villegas/UnevaluatedExpressions/ or http://library.wolfram.com/infocenter/Conferences/377/ Highly recommended, everyone. Bobby On Tue, 21 Dec 2004 05:19:43 -0500 (EST), Maxim <ab_def at prontomail.com> wrote: > > > On Mon, 20 Dec 2004 11:53:46 +0000 (UTC), Andrzej Kozlowski > <akoz at mimuw.edu.pl> wrote: > >> >> On 19 Dec 2004, at 20:15, Maxim wrote: >> >>> On Sat, 18 Dec 2004 09:36:01 +0000 (UTC), Andrzej Kozlowski >>> <akoz at mimuw.edu.pl> wrote: >>> >>>> >>>> On 17 Dec 2004, at 19:20, Maxim wrote: >>>> >>>>> In[5]:= >>>>> Unevaluated[1 + 1]*2 >>>>> 2*Unevaluated[1 + 1] >>>>> >>>>> Out[5]= >>>>> 4 >>>>> >>>>> Out[6]= >>>>> 2*Unevaluated[1 + 1] >>>>> >>>> >>>> This is not a glitch but works exactly as one woudl expect. You can >>>> see the difference and the reason by looking at Trace in both cases >>>> (although there is no need for that, if you understand Unevaluated you >>>> can see it right away). >>>> >>>> First: >>>> 2*Unevaluated[1+1]//Trace >>>> >>>> >>>> {2 (1+1),2 Unevaluated[1+1]} >>>> >>>> >>>> First Unevaluated is stipped away and Mathematica attempts ot evaluate >>>> 2*(1+1). Since it knows no rule to apply and the expression has not >>>> changed Unevaluated is restored and evaluation is completed with the >>>> output you see. >>>> >>>> >>>> >>>> Unevaluated[1+1]*2//Trace >>>> >>>> {(1+1) 2,2 (1+1),{1+1,2},2 2,4} >>>> >>>> As before, first Unevaluated is stripped away and Mathematica tires to >>>> evaluate 2*(1+1). It now knows a rule to apply, which is given by the >>>> Orderless attribute and the canonical ordering, so it converts the >>>> expression into the form 2 (1+1). But now Unevaluated is not restored >>>> because the expression has changed so evaluation continues with 1+1 >>>> evaluationg to 2 and finally you obtain 4. >>>> >>>> Now, I have honstly considered this case only because I could see at >>>> once what what was going on. I do not knwo if any of the others are >>>> glitches but jusdging by my experience with the past "language >>>> glitches" you have reported (unlike the more serious problems desribed >>>> in your last posting) I rather doubt it. However I have no time to >>>> spend on this just to prove a point (again). >>>> >>>> >>>> >>>> Andrzej Kozlowski >>>> Chiba, Japan >>>> http://www.akikoz.net/~andrzej/ >>>> http://www.mimuw.edu.pl/~akoz/ >>>> >>> >>> I do not agree. Suppose we evaluate z*Unevaluated[1 + 1]; according to >>> your explanation, after the reordering of the factors Unevaluated >>> should >>> disappear from the final result. However, the expression evaluates to >>> Unevaluated[1 + 1]*z. Further, suppose we take Unevaluated[1 >>> + 1]*Sin[Pi/4]: Sin[Pi/4] evaluates to 1/Sqrt[2], so in this case an >>> evaluation step definitely takes place; however, the output is >>> Unevaluated[1 + 1]/Sqrt[2]. Your theory simply doesn't work. But even >>> if >>> it did, there is another problem: suppose I use Sin[Pi/8] instead of >>> Sin[Pi/4] -- then first you would need to know whether Mathematica has >>> a >>> built-in rule for Sin[Pi/8] to arrive at any conclusion as to how it >>> might >>> work with Unevaluated (that is, what will count as an evaluation >>> step?). >>> So to apply your explanation we would have to search through all the >>> built-in rules of Mathematica. >>> >>> Maxim Rytin >>> m.r at inbox.ru >>> >>> >>> >> The principle behind Unevaluated, which I described above and which >> gos like this : strip off Unevaluated, keep applying all known rules to >> the expression (without evaluating the part that is supposed to be >> Unevaluated) then check if the expression "has changed", if not restore >> Unevaluated, if yes do not restore it. I have not invented it, it can >> be found in several perfectly reliable sources including Michael >> Trott's Giudebooks (section 4.7 of the programming volume). >> You can go on saying as long as you like that you don't agree wiht this >> or that and that you have discovered "glitches" (as you imagine you >> have done in the past with patterns and significance arithmetic) but >> that is your and not my problem. It also does not seem to be a problem >> for WRI since they rightly continue to ignore it. You seem to think >> that anything that you do not understand is a glitch or is wrong. I >> have seen people with this attitude and I have long ago learned that it >> can't be cured and that its best to just ignore it. >> >> Returning for the last time to this issue: what you have discovered is >> not a "glitch" but one of the many peculiarities of Unevaluated and >> also of the (very special) functions Times and Plus. They do not >> matter at all to the user because none of the examples you present have >> any realistic application. >> >> The point seems to be in deciding when "an expression has changed" or >> "has not changed". In this respect as in many others the functions >> Times and Plus are peculiar because they treat numerical expressions >> and symbolic ones in a different way. >> >> In general, if f is any function with the Orderless attribute f[a,b] >> and f[b,a] will be considered as the same expression. Thus; >> >> >> >> >> >> SetAttributes[g,{Orderless,Flat,OneIdentity}] >> >> >> Trace[g[ Unevaluated[f[1 , 1]],2]] >> >> >> {g(f(1,1),2),g(2,f(1,1)),g(2,Unevaluated[f(1,1)])} >> >> Here although the Orderless attribute of g was used in the above to >> reverse the order of parameters of g the expression is considered not >> to have changed and Unevaluated is restored. >> >> This behaviour however changes when g is one of the functions Times or >> Plus: >> >> >> Block[{g=Times},Trace[g[ Unevaluated[f[1 , 1]],2]]] >> >> >> {{g,Times},f(1,1) 2,2 f(1,1)} >> >> >> Block[{g=Plus},Trace[g[ Unevaluated[f[1 , 1]],2]]] >> >> {{g,Plus},f(1,1)+2,f(1,1)+2} >> >> It will not, however, happen when 2 is replace by a symbol: >> >> >> Block[{g=Times},Trace[g[ Unevaluated[f[1 , 1]],z]]] >> >> >> {{g,Times},f(1,1) z,z f(1,1),z Unevaluated[f(1,1)]} >> >> >> Block[{g=Plus},Trace[g[ Unevaluated[f[1 , 1]],z]]] >> >> >> {{g,Plus},z+f(1,1),z+f(1,1),z+Unevaluated[f(1,1)]} >> >> >> In other words, the issue amounts to the way Mathematica views the >> operation of commuting a number and (effectively) a symbol. In such >> cases expressions that differ only in the order of factors are >> considered different. Even simpler cases are: >> >> >> Unevaluated[a]*2 >> >> >> 2 a >> >> >> 2*Unevaluated[a] >> >> >> 2 Unevaluated[a] >> >> and the same with Times, as compared with using two symbols: >> >> >> Unevaluated[a]*z >> >> >> Unevaluated[a] z >> >> >> Unevaluated[z]*a >> >> >> a Unevaluated[z] >> >> >> you can even do this: >> >> >> Times[0,Unevaluated[Infinity]] >> >> 0 >> >> Times[Unevaluated[Infinity],0] >> >> Indeterminate expression 0* Infinity encountered. >> >> >> >> O.K. so finally so what? Mathematica clearly treats the operation of >> adding or multiplying a number and a symbol differently than it does >> adding or multiplying two symbols or two numbers. This is not >> documented but not really surprising. There are thousands of such >> undocumented aspects of Mathematica but this does not matter because >> they are totally irrelevant to the user. Nobody is ever going to use >> any of the above for any purpose. There is no glitch , there is no >> reason to change anything (and nothing will be changed. Your posting >> seems to me like a waste of effort, but that is your problem. Reading >> it and thinking about it is a waste of time and that is my problem. I >> think I shall form now on leave it to those who like this sort of >> thing. >> >> >> >> Andrzej Kozlowski >> Chiba, Japan >> http://www.akikoz.net/~andrzej/ >> http://www.mimuw.edu.pl/~akoz/ >> > > Basically you're saying that it works one way for numbers and another way > for symbols, one way for Plus and another way for other Orderless > functions; but how does that explain anything? It would be more precise to > say that the result depends on whether Mathematica applies any built-in > rules on intermediate evaluation steps, but this isn't a sufficient > explanation either; consider > > In[1]:= > Unevaluated[2]/Sqrt[2] > Unevaluated[Sqrt[2] + Sqrt[2]]/Sqrt[2] > > Out[1]= > Sqrt[2] > > Out[2]= > Unevaluated[Sqrt[2] + Sqrt[2]]/Sqrt[2] > > In the first case 2/Sqrt[2] is reduced to Sqrt[2], which means that some > basic arithmetic rules are applied; in the second case (Sqrt[2] > + Sqrt[2])/Sqrt[2] is not reduced to 2, so some basic arithmetic rules are > not applied; how can you tell which it's going to be in any given case? > > Next, compare > > In[3]:= > Unevaluated[Sqrt[2]*(Sqrt[3] + 1)]*Csc[Pi/12] > Unevaluated[Sqrt[6] + Sqrt[2]]*Csc[Pi/12] > > Out[3]= > 2*(1 + Sqrt[3])^2 > > Out[4]= > Sqrt[2]*Unevaluated[Sqrt[6] + Sqrt[2]]*(1 + Sqrt[3]) > > The difference is that in the first case the argument of Unevaluated > exactly matches the result of the evaluation of Csc[Pi/12], and > Mathematica transforms a*a to a^2; in the second case the argument of > Unevaluated is the same numerically but has a different structure, and > Mathematica cannot simplify the product further, thus Unevaluated remains. > I have to repeat what I said in my previous post: to predict the outcome > you need to know exactly what the part which isn't wrapped in Unevaluated > evaluates to; in other words, you need to see the output first and only > after that you can explain to me why it was exactly the output you had > been expecting. > > Maxim Rytin > m.r at inbox.ru > > > > -- DrBob at bigfoot.com www.eclecticdreams.net

**References**:**Re: Re: Mathematica language issues***From:*Maxim <ab_def@prontomail.com>