[Rivet] Time for Rivet 2.5.3?

[Chris Pollard]

To be honest I don't really have details. It was mentioned for one of the
Atlas top analyses which performs a fit "after unfolding". The contact for
that analysis is a graduating student who won't have time to implement in
Rivet, so it's unclear when we will actually have someone attempting to
write this thing. I think it'd be better if we did not provide a fitting
library (even via dependency).

On Wed, Dec 7, 2016 at 1:55 PM, David Grellscheid <
david.grellscheid at durham.ac.uk> wrote:

>
> >>> Amazing, thank you! Changes like that on the "default" branch (aka
> >>> trunk), please -- and you can re-apply your GSL removal there, if not
> >>> already done. Thanks!
> >> Ok will do, Chris however mentioned that some people wanted to use gsl
> >> stuff in an analysis,
> >> I think some minimisation stuff, not sure what do do now.
> >
> > Hmm, that's a first. Any details, Chris?
> >
> > Fits into the general question of "what external libs do we allow?".
> >
> > The GSL interface is actually pretty nasty from a C++ perspective, so I
> > think it'd be best if we could avoid exposing all that raw-C-array, raw
> > pointers, etc. stuff to analysis users... but what's the alternative?
> > Pity Minuit isn't available anymore without hauling in the rest of ROOT,
> > and all its runtime foibles & attempts to grab the wheel :-/
>
> I'm still very excited about removing GSL completely, so we'll have to
> look at that individual case. Is it such a complicated minimization that
> we need something like Minuit for it or can we make use of a simpler
> function we can include in the analysis?
>
> See you,
>
>   David
>
>
> _______________________________________________
> Rivet mailing list
> Rivet at projects.hepforge.org
> https://www.hepforge.org/lists/listinfo/rivet
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.hepforge.org/lists-archive/rivet/attachments/20161207/1d813b71/attachment.html>