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

MathGroup Archive 2007

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

Search the Archive

Re: Re: is 3?

  • To: mathgroup at smc.vnet.net
  • Subject: [mg73725] Re: [mg73669] Re: is 3?
  • From: Andrzej Kozlowski <akoz at mimuw.edu.pl>
  • Date: Sun, 25 Feb 2007 04:44:56 -0500 (EST)
  • References: <ermdak$hnh$1@smc.vnet.net> <200702240717.CAA09240@smc.vnet.net>

On 24 Feb 2007, at 08:17, David W.Cantrell wrote:

> "Tony Harker" <a.harker at ucl.ac.uk> wrote:
>> Dear Oleksandr,
>>
>>               That's interesting: but looking at what is produced by
>>   ArcSinh[2]/ArcCsch[2] == 3 // FullSimplify
>>  makes me wonder just how Mathematica achieved this.
>
> Spec., before saying True, it gives the warning
>
> N::meprec : Internal precision limit $MaxExtraPrecision =
> 49.99999999999999` reached while evaluating -3 + ArcSinh[2]/ArcCsch 
> [2].
>
>> In other words, what
>> does the message that Bob Hanlon so carefully suppressed mean?  
>> Similar
>> messages sometimes occur when checking the results of simple  
>> equations by
>> back-substituting, especially when the solutions contain surds, and
>> appear to show that Mathematica is diving off into real numbers to  
>> prove
>> results involving integers and powers of integers.
>
> Yes, I find such things disconcerting. Would someone please explain  
> what's
> going on? It's probably been explained here before; if so, maybe  
> just a
> reference to an earlier thread could be given.

This has been explained before (more than once). It is only due to  
the fact that FullSimplify does not hold its arguments, so  
Mathematica's evaluates receives a numerical equality to evaluate it  
tries  to disprove it, which can be done using extended precision  
arithmetic when equality does not hold. It then returns the message  
telling you that it could nto settle the equality and only then  
FullSimplify starts its work. In fact this approach (first try a  
numerical check, then use symbolic methods)  is exactly what I use  
myself when trying to solve such a problem by habnd; doesn't everyone?

Of course there is no need to suppress any messages:


Unevaluated[ArcSinh[2]/ArcCsch[2] == 3] // FullSimplify


True





>
> BTW, another example, which was never explained, appeared here at  
> the end
> of last Nov. in the thread "Unexpected Warning with ArcTan" by Andrew
> Moylan.
>
> Simplify[ArcTan[1/(1/2 + (1/2)*(-1 + 1/E^40))]]  yields  ArcTan 
> [2*E^40].
> But that correct result is preceeded by the warnings
>
> Power::infy : Infinite expression 1/0. encountered.
> Power::infy : Infinite expression 1/0.^1. encountered.
>
> which make it seem as though approximate arithmetic were involved  
> in some
> intermediate steps.
>

This is actually hard to explain  although again it has nothing to do  
with Smplify. Mathematica's evaluator sees a numerical expression  
and  rather than leaving it alone attempts to evaluate it  
numerically. Note that evaluating

ArcTan[1/(1/2 + (1/2)*(-1 + 1/E^40))]

produces the same message, so Simplify plays no role. Hence


Simplify[Unevaluated[ArcTan[
     1/(1/2 + (1/2)*(-1 + 1/E^40))]]]


ArcTan[2*E^40]

without any messages, because this time only Simplify does the job.

This shows anyway that Simplify and FullSImplify do not in these case  
atempt to use any numerical techniques and all these messages come  
form "the Evaluator".

There still remains the question why the Evaluator does anything at  
all with

ArcTan[1/(1/2 + (1/2)*(-1 + 1/E^40))]

since all the numbers are exact an in such cases it is supposed to  
return an exact answer. This seems to be something do do with the  
function ArcTan itself, because no such check is performed if you enter


1/((1/2)*(1/E^40 - 1) + 1/2)

By the way, the same thing will happen if you replace E by  Pi:

ArcTan[1/(1/2 + (1/2)*(-1 + 1/Pi^40))]

but not, for example, for


ArcTan[1/(1/2 + (1/2)*(-1 + 1/Pi^E))]


ArcTan[1/(1/2 + (1/2)*(-1 + Pi^(-E)))]

I myself feel pretty sure that this is a "bug", in the sense that it  
was never intended to do anything useful and is probably a side  
effect of something. Since it it harmless and probably nobody at WRI  
will feel it worth spending any time on, I guess it can be called a  
"feature".
A "quirk" is probably a more accurate description.

(However, I still think that

ArcCosh[x]+O[x]

is a "bad thing", whether it is called a bug, feature or just a quirk. )

Andrzej Kozlowski












  • References:
    • Re: is 3?
      • From: "David W.Cantrell" <DWCantrell@sigmaxi.net>
  • Prev by Date: Re: simple question
  • Next by Date: Re: simple question
  • Previous by thread: Re: is 3?
  • Next by thread: Re: Re: Re: is 3?