[Rivet] Releasing Rivet 2.0

[Andy Buckley]

Hi Frank,

I think for now it is best to just remove support for the __add__ method
in yodamoerge, i.e. the output scatter will just be the first one seen.
We definitely can't do a reliable general merge of these anyway, and as
you say the "sum of y-values of 'matched' points" is probably not the
desired behaviour in many / most use-cases.

In general, I think we should reconsider the meaning of "adding"
scatters: does it mean to try and identify points with common "binning"
and add them (the current behaviour, I think) or to end up with an
overall scatter that contains all of the points from all the input
scatters? I can see uses for both, and that suggests that we should have
explicitly named distinct functions, and no operator+.

So for now I'll just limit the merging of scatters in that script, and
improving the treatment of them can happen in a later Rivet version. I
would really like to introduce the generalisation of our Axis classes
into a form where they can be used to bin *any* type efficiently, not
just YODA::Dbns... which could really help for converting scatters back
to a "binned" type, without having to make wrong assumptions about sums
of weights, etc.

Andy


On 15/10/13 23:21, Frank Siegert wrote:
> Hi Andy,
> 
> I have noticed another small issue in yodamerge.
> 
> Scatter2D's don't seem to have an __iadd__ but they have an __add__,
> which gets used in yodamerge. The problem is, that __add__ does not
> preserve the path(), instead the resulting object has an empty path.
> This is then written out with the empty path to file.
> 
> I think there are two ways to fix it:
> 1. in yodamerge, set the path after adding.
> 2. in Scatter2D::add (, subtract, divide), set the path of the
> returned object to the one of the first input object (and probably
> check that the paths are equal).
> Which would you prefer?
> 
> Also, what's the expected effect of yodamerge'ing Scatter2D's? Will it
> simply add up the histo bins, which will be useless in all cases that
> I can think of?
> 
> Cheers,
> Frank
> 
> 
> On 6 October 2013 21:10, Andy Buckley <andy.buckley at cern.ch> wrote:
>> Hi all,
>>
>> Since earlier in the week, and particularly after a useful conversation
>> with Frank S on Friday and some YODA merge script & Cython hacking that
>> followed, I'm now feeling that the YODA and Rivet2 head versions are
>> good enough for our long-planned release.
>>
>> That's assuming that the D0 W charge asymmetry issue that I mentioned
>> before (from the H++ vaidation suite) is not actually a problem, since
>> no-one responded about that.
>>
>> Has anyone else tried the head configuration recently? Any problems? Any
>> good reasons *not* to release?
>>
>> If there's no opposition, I'll make a release candidate tag and tarball
>> so I can do a final test on lxplus. David, could you try running your
>> validation scripts on the head one last time, just to make sure that
>> nothing is _crashing_? We've been through the output numbers
>> sufficiently -- I just want to get good coverage to make sure that none
>> of the technical stuff I did in the last 10 days broke systems other
>> than mine. Once we've got the all clear, I'll tag Rivet 2.0.0 and YODA
>> 1.0.3 (or 1.1.0?) and we can *finally* get this thing out!
>>
>> Cheers,
>> Andy
>>
>> --
>> Dr Andy Buckley, Royal Society University Research Fellow
>> Particle Physics Expt Group, University of Glasgow / PH Dept, CERN
>> _______________________________________________
>> Rivet mailing list
>> Rivet at projects.hepforge.org
>> http://www.hepforge.org/lists/listinfo/rivet


-- 
Dr Andy Buckley, Royal Society University Research Fellow
Particle Physics Expt Group, University of Glasgow / PH Dept, CERN