Re: [ROOT] On the ability of RooFit to use an arbitrary fitter plugin
Hi,
I agree with Rene's proposal (i.e revise TVirtualFitter first).
Class RooMinuit was written a long time ago, when minuit was for all
practical purposes the only available fitter engine. Since the
TVirtualFitter interface did not provide access to essential information
at that time I took from the guts of gMinuit directly, just to make it
work. That more or less explains the current situation.
I'd be especially happy if I could move to an official interface to
retrieve the various bits of information on the correlation matrix.
(Perhaps this is already possible, I have not checked recently.) Rewriting
the minimizer-RooFit interface has been on my to-do list for a while but
if there is going to be some movement in this area, I make this a higher
priority.
In the end I envision a RooFit interface class for each of the minimizer
implementations in ROOT so RooFit users have access to each of the
minimizers specific functionality (e.g. minos, hesse in minuit) and put
them all under a RooFit 'mimimizer interface' base class that takes care
of the common functionality as is seen through ROOT class
TVirtualFitter.
Wouter
On Fri, 27 Jan 2006, Christian Holm Christensen wrote:
> Hi Kevin, Rene, Wouter, et al,
>
> [Sorry for the late follow-up - I've been busy as ...]
>
> On Wed, 2006-01-25 at 16:39 -0500, Kevin B. McCarty wrote:
> > [CC-ing to Chris Roat and debian-science since I originally suggested
> > there that RooFit could be patched to use any of the fitter plugins.]
> >
> > Unfortunately it looks like RooMinuit.cxx and RooFitResults.cxx can't
> > currently be converted to use the TVirtualFitter interface. There are
> > two main issues:
> >
> > 1) The function RooMinuit::contour() directly uses TMinuit::Contour(), a
> > method which isn't accessible through TVirtualFitter (or even in TFitter).
>
> Hmph.
>
> > 2) The function RooFitResult::fillCorrMatrix() mucks about in the
> > internals of the TMinuit class in order to obtain an error correlation
> > matrix. There is no API for obtaining this matrix even in TMinuit, let
> > alone in TVirtualFitter.
>
> Whoha - those guys must have nerves of steel :-)
>
> > I could submit a patch to fix RooFitResult::lastMinuitFit() and
> > RooMinuit::synchronize() to use TVirtualFitter instead of gMinuit, but I
> > guess there is not much point until (1) and (2) above are dealt with.
> > Someday maybe these functionalities can be added to TVirtualFitter (and
> > the classes that inherit from it) and RooFit can switch to use it
> > completely.
> ...
> > To conclude, currently libRooFit is constrained to depend specifically
> > upon libMinuit. I do apologize for wasting people's time because I
> > thought otherwise at first. For the ROOT Debian packages, I think
> > therefore libRooFit cannot be packaged as a library unless libMinuit is
> > also packaged as a library. Or, they could both be packaged just as
> > plugins.
>
> To the ROOT people that get this mail: I think many developers are not
> really aware of the various abstract interface that exist in ROOT, like
> TVirtualFitter, TSQLServer, and so on. That results in people writing
> code like
>
> TSQLServer* s = TMySQLServer::Connect(...)
>
> (fictive example :-) which breaks these nice interfaces, and makes life
> hard for the user.
>
> Perhaps you could make an effort to stipulate that the virtual
> interfaces are there, and should be used. Thanks.
>
> Of course, the Right Way(tm) to do it, would be to _not_ export the
> declarations of pure `plug-in' classes like `TMinuit', `TMySQLServer',
> and so on. That is, do not install the header files anywhere, nor
> create development libraries, and put the binary loadable plug-in
> modules somewhere the linker doesn't look for it, say
> `<base>/lib/root/plugins'.
>
> For the Debian people: I'll probably merge Minuit into the libroot
> package, or make libroot-minuit and libroot-minuit-dev. Making rootfit
> a plug-in package wouldn't work.
>
> Yours,
>
>
Reply to: