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: Re: Mathematica language issues

  • To: mathgroup at smc.vnet.net
  • Subject: [mg53065] Re: Re: Re: Mathematica language issues
  • From: Andrzej Kozlowski <akoz at mimuw.edu.pl>
  • Date: Wed, 22 Dec 2004 04:53:01 -0500 (EST)
  • Sender: owner-wri-mathgroup at wolfram.com

I think most people this entire discussion does not have any practical 
importance. Obviously something like this:


2*Unevaluated[1+1]


2 Unevaluated[1+1]

is extremly unlikely to have any practical use. After all, we use 
Unevaluated when we want something to remain unevaluated, whereas here 
only two things can happen: either one will be left with 
Unevaluated[something] or the "something" will evaluate. Both of these 
outcomes are obsiously undesirable. Why should one ever use anything 
like this in a program?

In fact if for some unimaginable reason somone needed this sort of 
thing and wanted Unevaluated to be removed all he needs to do is to 
ensure that some transformation that does not change the value of the 
expression will take place during evaluation. For example, one way to 
make sure thsi will happen woudl be:


a*2*Unevaluated[(1 + 1)/a]

4

Obvioulsy this or a similar method can be used in all cases. There are 
no imaginable cases where one woudl wihs to be left with Unevaluated, 
if one wanted that one should use Hold or HoldForm.

This also deals with the issue of "unpredictability". But for me that 
is non issue. I understand that there are some people who love life to 
be perfectly predictable and go to a great length to ensure that 
(particularly in the case of election results in certain countries) but 
there  others who find a little unpredictability, experimentation and 
the sense of discovery that goes with it quite pleasant and exciting. 
Mathematica is obviously more suitable for the second type of user. I 
am afraid this is not going to change unless someone decides to 
re-write it from scratch, which will make it a very different product.

Andrzej Kozlowski


On 21 Dec 2004, at 19:19, Maxim 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
>


  • Prev by Date: Re: GUIKit - ScrollPane Tables within Wizard
  • Next by Date: Re: Re: Re: Mathematica language issues
  • Previous by thread: Re: Re: Re: Mathematica language issues
  • Next by thread: Re: Mathematica language issues