Services & Resources / Wolfram Forums
-----
 /
MathGroup Archive
2004
*January
*February
*March
*April
*May
*June
*July
*August
*September
*October
*November
*December
*Archive Index
*Ask about this page
*Print this page
*Give us feedback
*Sign up for the Wolfram Insider

MathGroup Archive 2004

[Date Index] [Thread Index] [Author Index]

Search the Archive

Re: Re: Mathematica language issues

  • To: mathgroup at smc.vnet.net
  • Subject: [mg53029] Re: [mg53011] Re: Mathematica language issues
  • From: Andrzej Kozlowski <akoz at mimuw.edu.pl>
  • Date: Mon, 20 Dec 2004 06:35:01 -0500 (EST)
  • Sender: owner-wri-mathgroup at wolfram.com

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/


  • Prev by Date: Re: Re: Re: Mathematica slows down
  • Next by Date: Re: Mathematica is not very clever
  • Previous by thread: Re: Mathematica language issues
  • Next by thread: Re: Re: Mathematica language issues