HEPData / hepdata_lib

Library for getting your data into HEPData
https://hepdata-lib.readthedocs.io
MIT License
16 stars 39 forks source link

Strange issue with Uncertainty in SWAN #154

Closed echapon closed 3 years ago

echapon commented 3 years ago

When I try running this notebook in Swan, the output looks like this and errors make no sense. When I remove the uncertainty part, then the output is fine. It is also fine when I convert the code to a script and run it with python2 on lxplus.

Swan detailed information (I kept all defaults):

AndreasAlbert commented 3 years ago

Hi, it seems to me that this issue is not a SWAN problem, but rather related to the way the inputs are passed to the Uncertainty object. Your notebook is quite lenghty, so I did not run it, but I see that you use operations like these:

unc.values = data[:,3:5]

I think in this case, the elementary data type in your list is a numpy scalar rather than just a python float, and I suspect that this is not treated correctly by the yaml dumping code. Could you test this by explicitly converting your numbers to basic python types before inserting them? I mean something like this:

unc.values = [tuple(map(float,line)) for line in data[:,3:5]]

or alternatively, if you have a symmetric unc:

unc.values = list(map(float(data[:,X]))

If that resolves the issue, we know where the problem lies and can improve the code so that it natively deals with this case better.

echapon commented 3 years ago

After some investigation, I see that you are right -- the issue was that I had a list of numpy scalars, rather than just python floats. If I force the conversion to float, things work fine in python3. With python2, things just work in both cases, even without having to worry about this conversion.

For information, here is a minimal notebook with the issue. I have put the two versions, the one which works with both python2 and python3 (explicit conversion to float), and the one which fails in python3 (no explicit conversion).

clelange commented 3 years ago

Should be fixed by #169. Please reopen if this is not the case.