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

Re: Re: Re: is 3?

• To: mathgroup at smc.vnet.net
• Subject: [mg73700] Re: [mg73725] Re: [mg73669] Re: is 3?
• From: "Chris Chiasson" <chris at chiasson.name>
• Date: Mon, 26 Feb 2007 06:04:32 -0500 (EST)
• References: <ermdak$hnh$1@smc.vnet.net> <200702240717.CAA09240@smc.vnet.net>

Thanks Andrzej. I didn't know it was because the normal process of
evaluating the arguments attempts to check for inequality. I'll keep
that in mind.

On 2/25/07, Andrzej Kozlowski <akoz at mimuw.edu.pl> wrote:
>
> 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
>
>
>
>
>
>
>
>
>
>
>
>


-- 
http://chris.chiasson.name/

• References:
  • Re: is 3?
    • From: "David W.Cantrell" <DWCantrell@sigmaxi.net>