unexpected instability in minimization (make sure to set parameter initial values and errors when initializing Minuit) about iminuit HOT 12 CLOSED

inspired by the description in issue #107 I modified my function to observe the value of the parameters - this is uploaded to the same website as above, and called test_exp2.py. I believe it is being caused by the same issue as #107 - see my output from

def f(t,m,a):
    print "CALL", m,a
    return a * np.exp(-m * t)

which gives the output

then we can give them initial values and errors
 values =  {'a': -6.0000000000000002e-06, 'm': 0.28999999999999998}
 errors =  {'a': 5.9999999999999997e-07, 'm': 0.0030000000000000001}
 then we can call migrad
**************************************************
*                     MIGRAD                     *
**************************************************

 CALL 0.0 0.0
 CALL 0.0 0.0
 CALL 0.0192190876039 0.0
 CALL 0.0192190876039 0.0
 CALL -0.0192190876039 0.0

so clearly, the initial values are not being passed correctly to the function before migrad.

Andre

from iminuit.

Try it with printlevel=2 or so. It should print the value it tries at every step.

Also try updating iminuit to the latest version. There has been a lot of bugs related to setting the limit (but it never applied).

iminuit used exactly the same library version as pyminuit but there could be some bugs relating to setting the error.

from iminuit.

will do - by the way, thanks for putting this together - it seems pretty cool, even if not yet working for me.

from iminuit.

OK - pip uninstall, then pip install and same behavior.
Can I pull the latest git repo and then just python setup.py install?
I will try that now. - I would add with print_level=2, the initial values are 0.0

PS - OK, did

pip uninstall iminuit
git clone https://github.com/iminuit/iminuit.git
cd iminuit
python setup.py install

and I get the same behavior. What seems consistent is the initial values of the parameters are starting at 0., instead of what I have them set to.

from iminuit.

OK - I think I figured it out - didn't fix it myself in the _libiminuit.pyx - but at least see what needs to be done in principle - maybe in line 272, in the def migrad call, the first thing should be the assignment of fitarg?
Here is what I have deduced - best explained from sample - if you do not set the parameter values when initially calling the Minuit, the fitargs are not set properly. This is why the minimizer is having so much trouble, it is starting from all values = 0. and all errors = 1.
So the issue is the self.fitarg in _libiminuit.pyx, somehow, this needs to get updated when a user specifies the value

In [2]: val_init = {'a': -7e-06, 'm': 0.29}
In [3]: f_1 = mn.Minuit(TestChi2(f,t_dat,y_dat),pedantic=False,print_level=1)
In [4]: f_1.values
Out[4]: {'a': 0.0, 'm': 0.0}
In [5]: f_1.fitarg
Out[5]: 
{'a': 0.0,
 'error_a': 1.0,
 'error_m': 1.0,
 'fix_a': False,
 'fix_m': False,
 'limit_a': None,
 'limit_m': None,
 'm': 0.0}
In [6]: for param in val_init:
    f_1.values[param] = val_init[param]
In [7]: f_1.values
Out[7]: {'a': -7e-06, 'm': 0.29}
In [8]: f_1.fitarg
Out[8]:
{'a': 0.0,
 'error_a': 1.0,
 'error_m': 1.0,
 'fix_a': False,
 'fix_m': False,
 'limit_a': None,
 'limit_m': None,
 'm': 0.0}
In [9]: f_2 = mn.Minuit(TestChi2(f,t_dat,y_dat),pedantic=False,print_level=1,**val_init)
In [10]: f_2.values
Out[10]: {'a': -7e-06, 'm': 0.29}
In [11]: f_2.fitarg
Out[11]: 
{'a': -7e-06,
 'error_a': 1.0,
 'error_m': 1.0,
 'fix_a': False,
 'fix_m': False,
 'limit_a': None,
 'limit_m': None,
 'm': 0.29}

from iminuit.

OK, feeling brave, I added these lines to _libiminuit.pyx at line 307

        #set fitarg values to match any user specified values after init
        self.fitarg.update(
            {k:v for k,v in self.values.items()})
        self.fitarg.update(
            {'error_'+k:v for k,v in self.errors.items()})
        #not sure how to grab limits and fix_pars so won't try it here

but since I don't really know what I am doing, I was not able to recompile with cython on my own mactop. But I think something like this should work. Also, the limits and fixed_pars should get updated, but I didn't see how to do that as easily. Maybe if I knew how to set fix_pars in iminuit after the Minuit init call, it would be more clear.

from iminuit.

Oh.... now I see what you mean. The values and errors are meant to be readonly.

See input 4 in
http://nbviewer.ipython.org/github/iminuit/iminuit/blob/master/tutorial/tutorial.ipynb
for how to set the initial value and error. Use keyword parameter expansion if you want to do it more programatically.
For Keyword expansion see:
http://stackoverflow.com/questions/3394835/args-and-kwargs

from iminuit.

so the user should alter the values and errors and limits and fixed_pars ONLY through fitarg. That is an important point. I got into this mess because pyminuit did not define (as far as I know) a separate fitarg dictionary, and so when you wanted to temporarily freeze parameters, or shift their values to check for stability of the minimization (not just in local min) you would alter the values and errors and limits... not through this separate dictionary, but directly. I would suggest either not allowing the user to alter these parameters (not sure how to do that) or update fitarg if the user does modify them.

for now, I am happy to close this issue. i would try to make the fix myself, but would likely cause other bugs - I have not used cython yet, or thought of the code in the big picture, only how to hack my problem away.

from iminuit.

I see your point. Currently there is an easy way to recycle the value.... just use **m.fitarg to construct a new minuit object. But, I'll keep what you said in mind though.

from iminuit.

That is a very nice feature.
Correct me if I am wrong, I believe to utilize this, you would have to re-initialize the Minuit call, rather than simply alter parameters in fitarg. I just tried altering fitarg after init and it does not seem to have any effect on the minimization. So, if I init without any values specified, and then use fitarg to change the values/errors, it still can puke, so somehow, this information is not getting passed to Minuit if it is done after init.

The only reason I suggest this is so that you can temporarily freeze some parameters, then unfreeze them and migrad again, etc. without having to re-init. In an interactive ipython session, that would be a very nice feature.

Cheers,

Andre

On Feb 25, 2014, at 12:45 AM, Piti Ongmongkolkul [email protected] wrote:

I see your point. Currently there is an easy way to recycle the value.... just use **m.fitarg to construct a new minuit object. But, I'll keep what you said in mind though.

—
Reply to this email directly or view it on GitHub.

from iminuit.

Yes, you have to construct another Minuit object which you can recycle altered version of fitarg if needed. The sole reason fitarg exists is for recycling the parameter values and errors with ease.

from iminuit.

But I agree this is confusing. I'll clarify it in the doc+tutorial when I have time.

from iminuit.