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>
• 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

```

• Prev by Date: Re: Re: Re: Mathematica language issues
• Next by Date: Re: Information about subscripted function
• Previous by thread: Re: Re: Mathematica language issues
• Next by thread: Re: Re: Re: Mathematica language issues