PyRoot RooMinuit giving different output

Hi all,

I wanted to learn how to use the RooMinuit implementation so I converted one of the examples (rf403_weightedevts.C) to PyRoot. I’ve attached both the original .C macro and my python’ized version here.

The standard RooFit calls produced similar output between the two scripts, but the RooMinuit implementation produces different results. I can safely say that the PyRoot version is wrong. :slight_smile:

chi2 = RooChi2Var("chi2","chi2",p2,binnedData,RooFit.DataError(RooAbsData.SumW2))
m = RooMinuit(chi2)
m.migrad()
m.hesse()

Here’s the .C output…

  RooFitResult: minimized FCN value: 31.3747, estimated distance to minimum: 8.52316e-08
                coviarance matrix quality: Full, accurate covariance matrix

    Floating Parameter    FinalValue +/-  Error
  --------------------  --------------------------
                    a1   -9.9890e-03 +/-  2.63e-02
                    a2    1.0637e-01 +/-  1.02e-02

And here’s the .py output…

  RooFitResult: minimized FCN value: 998.709, estimated distance to minimum: 0.000310136
                coviarance matrix quality: Full, accurate covariance matrix

    Floating Parameter    FinalValue +/-  Error
  --------------------  --------------------------
                    a1   -6.9585e-02 +/-  1.45e+00
                    a2    5.9616e-12 +/-  6.73e-01

The only place where I was a little unsure of the conversion between .C and .py was here:

  // Instruct dataset wdata in interpret w as event weight rather than as observable
  RooDataSet wdata(data->GetName(),data->GetTitle(),data,*data->get(),0,w->GetName()) ;
wdata = RooDataSet(data.GetName(),data.GetTitle(),data,RooArgSet(data.get()),RooFormulaVar(),w.GetName())

I think everything else was straightforward. Thanks in advance for any clues.

Matt
rf403_weightedevts.C (6.55 KB)
rf403_weightedevts.py (6.2 KB)

Matt,

there’s at least the standard problem with temporaries for RooArgSet(x), and wdata should probably be:wdata = RooDataSet(data.GetName(),data.GetTitle(),data,data.get(),"",w.GetName())But none of that solves the issues within the “m.migrad()” call (drop that call and the results appear okay).

Later,
Wim

Hey Wim,

Thanks, as always, for your prompt response!

The plots appear the same by eye…but the actual values to which the fit converged are slightly different without the explicit call to migrad. The errors on the final values are very different between the .C and .py versions.

For the time being, should I take it that migrad is not callable from PyRoot’ed RooMinuit? I’m not sure that I desperately need it right now, so it’s not a high priority for me personally…but I may wind up using it more later in the year.

Matt

Matt,

no, that was just something I noticed. I’m sure there’s another temporary being referenced by RooFit, but valgrind didn’t show anything other than the RooDataSet pbs. I’ll look again tomorrow.

Cheers,
Wim

Matt,

so at issue is that RooChi2Var has two ctors:RooChi2Var(const char *name, const char* title, RooAbsReal& func, RooDataHist& data, ... RooChi2Var(const char *name, const char* title, RooAbsPdf& pdf, RooDataHist& data, ...and the RooPolynomial is derived from RooAbsPdf, which is derived from RooAbsReal. PyROOT will try the ctors in order, and so the first one (RooAbsReal) will match, since RooPolynomial is derived from RooAbsReal. The C++ version however, will select the second one (RooAbsPdf) since it forms a better match.

The problem can be reproduced by casting the p2 in the .C version to a (RooAbsReal&) in the RooChi2Var ctor call.

It’s unclear to me why the two ctors behave so differently, but I call bug in roofit on this one …

Cheers,
Wim

Hi Wim,

Thanks for your debugging of this.

Do you mind if I forward this odd behavior to the “Stat and Math” forum for Wouter to comment upon or at least be aware of for future development?

Matt

Matt,

sure, go ahead. Saves me the work of doing so. :slight_smile:

Cheers,
Wim

Done.

root.cern.ch/phpBB2/viewtopic.php?t=10060

Matt

Hi,

decided to “fix” this in PyROOT by giving RooAbsReal a lower priority in the overload selection. Is in trunk.

Cheers,
Wim