# Increasing MaxExtraPrecision arbitrarily changes numerical result

I am trying to confirm that a function $$f$$ satisfies a particular differential equation of the type $$D f=0$$, for some differential operator $$D$$. I set $$Df$$ as Diffeq in Mathematica and I tried to check if it gives zero for any numerical value of the variables that $$f$$ depends on. I wrote

N[Difeqx /. x -> 3/4 /. y -> 1/5 , 500]


I got the following:
"N::meprec: Internal precision limit $MaxExtraPrecision = 50. reached while evaluating [the function] Out=-1.214057*10^-613 - 6.579195*10^-614 I ". I then used Block[{$MaxExtraPrecision = 550}, N[Difeqx /. x -> 3/4 /. y -> 1/5, 500]]


and I got back
"N::meprec: Internal precision limit $MaxExtraPrecision = 550. reached while evaluating [the function] Out= 4.131621*10^-1089 + 2.022562*10^-1089 I " The numerical result changes (and becomes smaller for this particular case) as I increase the MaxExtraPrecision. The question: From the different numerical results I get, I can conclude with some uncertainty that indeed $$Df=0$$ (or Difeq=0) is satisfied. But, can I make it more precise? How can I be more sure that it indeed gives zero? P.S. I don't think that Chop, which returns zero, makes it any more sure that the result is precisely zero. • It would be way easier for us to help you if you shared the function f and the differential equation with us. Moreover, your actual question doesn't have anything to do with the title of your question: Even if there were no error message, you would perform "only" some numerical testing which would not be a strict mathematical proof; the only difference would be that you would just feel more secure because no error or warning message pops up. Jan 6 '19 at 23:30 • @HenrikSchumacher thanks for the reply. Will change the title to hopefully something more helpful. The reason that I did not share the differential equation and the function is because they are very messy (the function is a hypergeometric function that takes two lines to write and the diff. equation is even longer). I guess that the essence of the question is about whether or not the error message means that the numerical result is somehow incorrect and if I can somehow increase the "certainty" that the result is indeed zero. Jan 6 '19 at 23:34 • (1) Don't you expect the value to change when you change a system parameter? and (2) the numbers are pretty close to one another, so the change is not that great (esp. if the answer is zero). And, I suppose, (3) it's not possible to prove every expression that is zero is equal to zero numerically; see also PossibleZeroQ -- To give a Tolstoyan echo of @Henrik's comment, every unhappy numerical code is unhappy in its own way. (That is to say, without the code, it's hard to give an answer.) Jan 6 '19 at 23:49 • @MichaelE2 thanks for the reply. (1) Sure, but here I am not changing a parameter/variable but the precision (maybe I didn't get your point here?). (2) The numbers are not close. They differ by 400 orders of magnitude :) (3) you got a point there. I guess what I am looking for is an efficient way to get as close to the true/actual result as possible. Will check the code you suggested, thanks! As for the code, the only thing I did not give is$D$and$f$(a combination of products of hypergeometric functions) which are really messy and I don't expect that they'll give any useful info. Jan 6 '19 at 23:56 • (1) $MaxExtraPrecision is a system parameter that you are changing; it changes the computational environment, and for a numerically troublesome computation, I would expect it to make a difference -- indeed, I'd expect just what you are seeing if the answer should be zero. Of course, it's always possible that the true value is 10^-40000 or some other nonzero value. (2) The numbers are both close to zero; relative error is not the way to measure closeness to zero. Jan 7 '19 at 0:10

The fact that you are getting this error message is already a pretty good indication that the number is in fact zero. The fact that it does not go away when you increase MaxExtraPrecision further points in this direction.

When you apply N[expr, 100] you are asking Mathematica to numerically evaluate the expression with an output precision of 100 digits. However, if expr actually evaluates to 0 this is impossible because a zero always has zero significant digits. Hence no matter how much Mathematica increases its internal precision, it never reaches the desired output precision of a 100 digits.

Lets view a concrete example. Let

a = 1 - 1/Sqrt[x] - (Sqrt - 1)/Sqrt


It does not take a genius to realize that (a /. x-> 2) == 0. (However Mathematica does not immediately do so, when you input

(a /. x-> 2)


it returns

1 - 1/Sqrt - (-1 + Sqrt)/Sqrt


N[(a /. x-> 2),10]


Produces a N::meprec error message as in your example. An it will continue to do so no matter how much you increase the \$MaxExtraPrecision, exactly because it cannot produce any finite precision representation of 0.

In this case you can get Mathematica to confirm that this is zero by simply asking

Simplify[(a /. x-> 2)]


Since you mentioned that your expresion involves Hypergeometric functions, you would at the very least need FullSimplify, although it is very possible that even then Mathematica won't be able to recognize that it is zero.

This leaves you with numerical probes, which will never tell you that the result is zero exactly. For example, instead of inputting the parameters as exact number and asking Mathematica to produce a finite precision result, you could input the parameters as finite precision numbers. E.g.

a/. x -> 2.100


if a is exactly zero this should produce a finite Accuracy zero E.g.

0.100
`

(This is essentially the process that Mathematica was following internally, but now you can explicitly check that a finite precision input leads to zero within the expected accuracy.)