Mathematica 9 is now available
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: Log[4]==2*Log[2]

  • To: mathgroup at smc.vnet.net
  • Subject: [mg50626] 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:18 -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> <FC5C5A8F-0550-11D9-A0AA-000A95B4967A@akikoz.net> <opsd88dletiz9bcq@monster.cox-internet.com>
  • Sender: owner-wri-mathgroup at wolfram.com

> (Tell me again why Simplify shouldn't ring bells when it can't 
> simplify something?)

One reason is that it is not actually clear what is meant by "can't 
simplify something". There are at least two different reasons why 
Simplify may return to you your input. It often happens that Simplify 
does this not because it could not "simplify it" but because it found 
the original form to be the "simplest" according to the default 
ComplexityFunction.   There are also cases when Simplify does not know 
any rules to apply to input.
So the only "universal message" that could cover both cases would be 
"the simplified output turned out to be the same as the input", which 
is hardly informative. In addition,you may have in your code something 
like
f[y_]:=If[Simplify[y]==a, ....]
which ought to work for y=a without producing a warning message.


Besides, you never need to use things like

Simplify[Log[4]==2*Log[2]]

since you can always replace them by:


Simplify[Log[4]-2*Log[2]]==0

True

which does not even require using Unevaluated (I only used it to 
illustrate what is going on, I would not use this form in actual 
programming).

Andrzej




On 13 Sep 2004, at 16:28, DrBob wrote:

> *This message was transferred with a trial version of CommuniGate(tm) 
> Pro*
> You went to some trouble to use Unevaluated; I didn't go out of my way 
> to commit "*premature* evaluation". (That sounds so evil, doesn't it?)
>
> Simplify[Log[4]==2Log[2]] asks Mathematica to simplify an expression. 
> If Equal left the expression unevaluated (because it can't decide the 
> question) then Simplify could come along and settle it.
>
> And it DOES do exactly that, just as I would expect it to.
>
> But the error message rings a great big meaningless bell, giving me a 
> completely unnecessary headache.
>
> (Tell me again why Simplify shouldn't ring bells when it can't 
> simplify something?)
>
> Anyway, if Equal really HAS to throw an error, why shouldn't it be a 
> meaningful one, like "These expressions are equal to 
> $MaxExtraPrecision, but we're unwilling to declare them equal, because 
> we'd never declare them equal anyway, we only declare things unequal."
>
> I think I'll add Off[N::meprec] to my Init file.
>
> Bobby
>
> On Mon, 13 Sep 2004 15:48:57 +0900, Andrzej Kozlowski 
> <andrzej at akikoz.net> wrote:
>
>> *This message was transferred with a trial version of CommuniGate(tm) 
>> Pro*
>> 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
>>>
>>
>>
>>
>
>
>
> -- 
> DrBob at bigfoot.com
> www.eclecticdreams.net
>


  • Prev by Date: Re: Re: Re: Log[4]==2*Log[2]
  • Next by Date: Text in Tables
  • Previous by thread: Re: Re: Re: Log[4]==2*Log[2]
  • Next by thread: Re: Log[4]==2*Log[2]