# Machine accuracy limits further improvement

Hi,

I have a fit going crazy and one of the oddities is the warning MACHINE ACCURACY LIMITS FURTHER IMPROVEMENT. I was wondering is there anything I can learn from this except perhaps I should be running on a “better” machine (whatever that means)?

Cheers,

• Moritz

Normally you get this when your trying to minimize a function with a too small tolerance. For example when trying to find a minimum of a function at value around 1020 with small tolerance of around 10-6 (which are the default). You get in this case the limit of double precision (around 10**-16).
I would check first the function calculation, and eventually re-scale the function values and as last attempt increase the tolerance

Best Regards

Lorenzo

That’s interesting. But in my case the function is around FCN=-1.52811e+06. With a tolerance of 10**-6 we need only 12 digits. If double has 16, this shouldn’t be a problem? Since my function is the -2lnL built by RooFit, I believe the calculation is correct. I’d rather not artificially scale it. Do you know how I can change the tolerance?

• Moritz

Hi Moritz,

Such machine accuracy issues can be driven by a number of sources, the effect of
which may sometimes be amplified in the final likelihood, e.g. when a numeric normalization
integral is used for a p.d.f.

You should be able to control the tolerance by running your fit with RooMinuit
directly and calling RooMinuit::setEps(Double_t eps) ;

Wouter

RooMinuit::setEps controls the machine precision value. It should not be set to smaller values than the default machine double precision which is 10^-16.

The tolerance value passed as argument to Migrad control instead the convergence. I don’t know how to control this in RooFit.

Since the expected distance to the minimum is calculated using the square of the gradient, its numerical error is of the order of 10^-8. This is the reason you get this error with likelihood value of 10**6.

Lorenzo

Hi Lorenzo,

OK. Thanks for that clarification.

The tolerance argument passed to MIGRAD by RooMinuit is at present hard-coded and cannot be changed. Since there seem to be valid cases where one may want to change this, I will make it an optional argument to RooMinuit::migrad() for the
next release.

Wouter

Ok- do you have any suggestions on what I could be doing about it? Maybe I could just ignore it. Knowing the minimum to so many digits seems to be overdone anyway given the error definition of O(1).

Do you think this could be the cause for the convergence problems I’m seeing?

• Moritz

Hi,

I think you should also check the Hessian at the minimum if it has been calculated correctly.
However, I think you might have some problem with your likelihood normalization, maybe some large constant terms have been added
which cause so large negative values.

Lorenzo

Hi Wouter,

I just encountered another situation where I’d like to control the tolerance value that is being passed to MIGRAD. Any hope for this feature soon?

Cheers

• Moritz

PS: Sorry to bring this up after so long…