Re: Re: Re: Log[4]==2*Log[2]
- To: mathgroup at smc.vnet.net
- Subject: [mg50623] Re: [mg50599] Re: [mg50557] Re: [mg50520] Log[4]==2*Log[2]
- From: Andrzej Kozlowski <andrzej at akikoz.net>
- Date: Wed, 15 Sep 2004 01:49:15 -0400 (EDT)
- References: <200409120842.EAA01340@smc.vnet.net> <opsd8augkviz9bcq@monster.cox-internet.com> <9144B6AA-0511-11D9-9D11-000A95B4967A@akikoz.net> <opsd8qdyosiz9bcq@monster.cox-internet.com> <3ADADD30-0534-11D9-AE14-000A95B4967A@akikoz.net> <opsd857nociz9bcq@monster.cox-internet.com>
- Sender: owner-wri-mathgroup at wolfram.com
But this is all due to your using *premature* evaluation (as I
explained in m y original reply):
In[1]:=
N[Unevaluated[Log[4]==2Log[2]]]
Out[1]=
True
In[2]:=
Simplify[Unevaluated[Log[4]==2Log[2]]]
Out[2]=
True
So this time it is really the case of "user error" and, as far as I am
concerned at least, this behaviour is clear, logical and I see no good
reason to change it.
Andrzej
On 13 Sep 2004, at 15:41, DrBob wrote:
> *This message was transferred with a trial version of CommuniGate(tm)
> Pro*
>>> When I wrote an "error" I meant a (likely) programmer's error, not
>>> Mathematica's error.
>
> So did I.
>
>>> in real life situations, when, in a program and equality appears
>>> that Mathematica is unable to verify
>>> it is very likely to be something unintended; most probably the
>>> programmer forgot to use N.
>
> If I use N, don't I still get an error message, even though
> Mathematica DOES verify the equality?
>
> Log[4]\[Equal]2Log[2]//N
>
> \!\(\*
> RowBox[{\(N::"meprec"\), \(\(:\)\(\ \)\), "\<\"Internal precision
> limit $MaxExtraPrecision = \\!\\(50.`\\) reached while
> evaluating \
> \\!\\(\\(\\(\\(\\(-2\\)\\)\\\\ \\(\\(Log[2]\\)\\)\\)\\) + \
> \\(\\(Log[4]\\)\\)\\). \\!\\(\\*ButtonBox[\\\"More?\\\", \
> ButtonStyle->\\\"RefGuideLinkText\\\", ButtonFrame->None, \
> ButtonData:>\\\"General::meprec\\\"]\\)\"\>"}]\)
>
> True
>
>>> On the other hand whenever you use Simplify you are (or at least
>>> should be) aware that Mathematica may fail to
>>> return what you are expecting (or hoping for).
>
> If I use Simplify, don't I still get an error message, even though I
> _do_ get what I'm expecting, otherwise?
>
> Simplify[Log[4]==2Log[2]]
>
> \!\(\*
> RowBox[{\(N::"meprec"\), \(\(:\)\(\ \)\), "\<\"Internal precision
> limit $MaxExtraPrecision = \\!\\(50.`\\) reached while
> evaluating \
> \\!\\(\\(\\(\\(\\(-2\\)\\)\\\\ \\(\\(Log[2]\\)\\)\\)\\) + \
> \\(\\(Log[4]\\)\\)\\). \\!\\(\\*ButtonBox[\\\"More?\\\", \
> ButtonStyle->\\\"RefGuideLinkText\\\", ButtonFrame->None, \
> ButtonData:>\\\"General::meprec\\\"]\\)\"\>"}]\)
>
> True
>
> Tell me again why that isn't dumb?
>
> Bobby
>
> On Mon, 13 Sep 2004 12:23:06 +0900, Andrzej Kozlowski
> <andrzej at akikoz.net> wrote:
>
>> *This message was transferred with a trial version of CommuniGate(tm)
>> Pro*
>> I disagree, though of course this is a matter of design, which is to
>> some extent is a matter of taste and judgement, not mathematics.
>> When I wrote an "error" I meant a (likely) programmer's error, not
>> Mathematica's error. In my judgement, in real life situations, when,
>> in a program and equality appears that Mathematica is unable to verify
>> it is very likely to be something unintended; most probably the
>> programmer forgot to use N. On the other hand whenever you use
>> Simplify
>> you are (or at least should be) aware that Mathematica may fail to
>> return what you are expecting (or hoping for). That is in the nature
>> of
>> Simplify and realizing this fact is an essential aspect of
>> understanding Mathematica. So, in my opinion, there is a good reason
>> for treating these two cases differently.
>>
>> Andrzej
>>
>>
>>
>> On 13 Sep 2004, at 09:59, DrBob wrote:
>>
>>> *This message was transferred with a trial version of CommuniGate(tm)
>>> Pro*
>>>>> it seems to me that it is a good idea
>>>>> for errors to produce error messages
>>>
>>> It's not an error. If we ask Simplify to recognize an equality, we
>>> (usually) don't get an error message if it fails; we just get back
>>> the
>>> original expression. This is NO different.
>>>
>>> In fact, for the expression Log[4]==2Log[2], Simplify returns True as
>>> it should--but too late to avoid the "error" message from Equal.
>>> That's just dumb.
>>>
>>> Log[4]==2Log[2]//Simplify
>>>
>>> \!\(\*
>>> RowBox[{\(N::"meprec"\), \(\(:\)\(\ \)\), "\<\"Internal precision
>>> limit $MaxExtraPrecision = \\!\\(50.`\\) reached while
>>> evaluating \
>>> \\!\\(\\(\\(\\(\\(-2\\)\\)\\\\ \\(\\(Log[2]\\)\\)\\)\\) + \
>>> \\(\\(Log[4]\\)\\)\\). \\!\\(\\*ButtonBox[\\\"More?\\\", \
>>> ButtonStyle->\\\"RefGuideLinkText\\\", ButtonFrame->None, \
>>> ButtonData:>\\\"General::meprec\\\"]\\)\"\>"}]\)
>>>
>>> True
>>>
>>> Bobby
>>>
>>> On Mon, 13 Sep 2004 08:14:59 +0900, Andrzej Kozlowski
>>> <andrzej at akikoz.net> wrote:
>>>
>>>> *This message was transferred with a trial version of
>>>> CommuniGate(tm)
>>>> Pro*
>>>>
>>>> On 13 Sep 2004, at 04:24, DrBob wrote:
>>>>
>>>>>
>>>>> If Equal can't decide equality for exact expressions, then it
>>>>> should
>>>>> return unevaluated. It shouldn't interrupt everything with a
>>>>> useless
>>>>> error message.
>>>>>
>>>>> Bobby
>>>>
>>>> I am not sure about that. You are right as far as the "aesthetics"
>>>> of
>>>> the interface of CAS is concerned. But when this sort of thing
>>>> happens
>>>> in a program it is likely to be the result of an error (probably not
>>>> intended by the programmer) and it seems to me that it is a good
>>>> idea
>>>> for errors to produce error messages since it makes it debugging
>>>> easier (such messages can be caught with Check).
>>>>
>>>> Andrzej
>>>>
>>>>>
>>>>>
>>>>> On Sun, 12 Sep 2004 04:42:10 -0400 (EDT), Andrzej Kozlowski
>>>>> <andrzej at akikoz.net> wrote:
>>>>>
>>>>>> Actually, I don't think Mathematica does any real "determining"
>>>>>> since
>>>>>> it does not replace the exact values given in the input by
>>>>>> numerical approximations. The message issued is, I think, purely
>>>>>> formal. Mathematica could not determine anything because it tries
>>>>>> to
>>>>>> compare the numbers "numerically" without using approximate
>>>>>> numerical
>>>>>> values, which can't be done. (You have to apply N for it to use
>>>>>> numerical values). That't what I meant by "not surprisingly". I
>>>>>> don't
>>>>>> think I really understand your point?
>>>>>>
>>>>>> ANdrzej
>>>>>>
>>>>>>
>>>>>> On 11 Sep 2004, at 01:52, DrBob wrote:
>>>>>>
>>>>>>
>>>>>>>>> Mathematica does not apply any simplification rules but just
>>>>>>>>> tries
>>>>>>>>> to
>>>>>>>>> evaluate the expression numerically and, not
>>>>>>>>> surprisingly, it can't determine if the LHS is zero or not
>>>>>>>>> up to the required precision.
>>>>>>>
>>>>>>> On the contrary, I think the error message itself clearly
>>>>>>> indicates
>>>>>>> the difference IS zero to "the required precision". If 50 digits
>>>>>>> extra
>>>>>>> precision isn't enough to determine that the difference ISN'T
>>>>>>> zero,
>>>>>>> why doesn't Equal return True?
>>>>>>>
>>>>>>> Bobby
>>>>>>>
>>>>>>> On Fri, 10 Sep 2004 04:05:56 -0400 (EDT), Andrzej Kozlowski
>>>>>>> <andrzej at akikoz.net> wrote:
>>>>>>>
>>>>>>>> On 9 Sep 2004, at 18:17, Andreas Stahel wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>> To whom it may concern
>>>>>>>>>
>>>>>>>>> the following answer of Mathematica 5.0 puzzeled me
>>>>>>>>>
>>>>>>>>> Log[4]==2*Log[2]
>>>>>>>>> leads to
>>>>>>>>>
>>>>>>>>> N::meprec: Internal precision limit $MaxExtraPrecision = 50.`
>>>>>>>>> reached
>>>>>>>>> while \
>>>>>>>>> evaluating -2\Log[2]+Log[4]
>>>>>>>>>
>>>>>>>>> with the inputs given as answer. But the input
>>>>>>>>>
>>>>>>>>> Log[4.0]==2*Log[2]
>>>>>>>>>
>>>>>>>>> leads to a sound "True"
>>>>>>>>>
>>>>>>>>> Simplify[Log[4]-2*Log[2]]
>>>>>>>>> leads to the correct 0, but
>>>>>>>>> Simplify[Log[4]-2*Log[2]==0]
>>>>>>>>> yields no result
>>>>>>>>>
>>>>>>>>> There must be some systematic behind thid surprising behaviour.
>>>>>>>>> Could somebody give me a hint please
>>>>>>>>>
>>>>>>>>> With best regards
>>>>>>>>>
>>>>>>>>> Andreas
>>>>>>>>> --
>>>>>>>>> Andreas Stahel E-Mail:
>>>>>>>>> Andreas.Stahel at [ANTI-SPAM]hti.bfh.ch
>>>>>>>>> Mathematics, HTI Phone: ++41 +32 32 16 258
>>>>>>>>> Quellgasse 21 Fax: ++41 +32 321 500
>>>>>>>>> CH-2501 Biel WWW: www.hta-bi.bfh.ch/~sha
>>>>>>>>> Switzerland
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> When you enter
>>>>>>>>
>>>>>>>> Log[4] - 2*Log[2] == 0
>>>>>>>>
>>>>>>>> Mathematica does not apply any simplification rules but just
>>>>>>>> tries
>>>>>>>> to
>>>>>>>> evaluate the expression numerically and, not surprisingly, it
>>>>>>>> can't
>>>>>>>> determine if the LHS is zero or not up to the required
>>>>>>>> precision.
>>>>>>>>
>>>>>>>> If you use
>>>>>>>>
>>>>>>>> Simplify[Log[4] - 2*Log[2] == 0]
>>>>>>>>
>>>>>>>> Mathematica first tries to evaluate the argument of Simplify and
>>>>>>>> the
>>>>>>>> same thig happens as above, but then it actually applies
>>>>>>>> Simplify
>>>>>>>> to
>>>>>>>> the output and gets the right answer True.
>>>>>>>>
>>>>>>>> The best thing to do is:
>>>>>>>>
>>>>>>>>
>>>>>>>> Simplify[Unevaluated[Log[4]-2*Log[2]==0]]
>>>>>>>>
>>>>>>>>
>>>>>>>> True
>>>>>>>>
>>>>>>>> which avoids evaluation of the argument and instead uses
>>>>>>>> Simplify
>>>>>>>> on
>>>>>>>> the unevaluated input.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Andrzej Kozlowski
>>>>>>>> Chiba, Japan
>>>>>>>> http://www.akikoz.net/~andrzej/
>>>>>>>> http://www.mimuw.edu.pl/~akoz/
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> DrBob at bigfoot.com
>>>>>>> www.eclecticdreams.net
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> DrBob at bigfoot.com
>>>>> www.eclecticdreams.net
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> DrBob at bigfoot.com
>>> www.eclecticdreams.net
>>>
>>
>>
>>
>
>
>
> --
> DrBob at bigfoot.com
> www.eclecticdreams.net
>
- References:
- Re: Re: Log[4]==2*Log[2]
- From: Andrzej Kozlowski <andrzej@akikoz.net>
- Re: Re: Log[4]==2*Log[2]