Re: Re: Mathematica language issues
- To: mathgroup at smc.vnet.net
- Subject: [mg53050] Re: Re: Mathematica language issues
- From: Maxim <ab_def at prontomail.com>
- Date: Tue, 21 Dec 2004 05:19:43 -0500 (EST)
- References: <cq6ega$2tb$1@smc.vnet.net>
- Sender: owner-wri-mathgroup at wolfram.com
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
- Follow-Ups:
- Re: Re: Re: Mathematica language issues
- From: DrBob <drbob@bigfoot.com>
- Re: Re: Re: Mathematica language issues