[Date Index] [Thread Index] [Author Index]
Re: Re: Re: is 3?
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/ArcCsch == 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/ArcCsch > > . > > > >> 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/ArcCsch == 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/