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>
- Re: is 3?