Gracefully handle negative std_dev values

[cmarqu]

With uncertainties 2.3.6 (the newest I have available easily), when I write

rngsh_unc   = uncertainties.ufloat(rngsh, -0.03)

I get

fixedpointcalc.py:79: UserWarning: Obsolete: either use ufloat(nominal_value, std_dev), ufloat(nominal_value, std_dev, tag), or the ufloat_fromstr() function, for string representations. Code can be automatically updated with python -m uncertainties.1to2 -w ProgramDirectory.
[...]
  File "[...]/python/2.6/lib/uncertainties-2.3.6-py2.6.egg/uncertainties/__init__.py", line 1949, in _str_to_number_with_uncert
    (value, uncert) = representation.split('+/-')
AttributeError: 'float' object has no attribute 'split'

You may ask why anybody would use negative values for std_dev here. Well, it's because my original code was

rngsh_unc   = uncertainties.ufloat(rngsh,   3.0/100.0*rngsh)

i.e., I want to allow a 3% deviation, and rngsh can be a negative value. I can of course use abs(rngsh), but IMO it's not that nice. What do you think?

[lebigot]

Good question. Since ufloat() officially takes a standard deviation, I could in principle extend the semantics and decide that ufloat() takes instead either a standard deviation or the opposite of a standard deviation. However, I am against this: I want users to catch possible errors in their code. This is reasonable, since the standard deviation is really a central concept in error propagation: I prefer to keep it as it is, i.e., positive.

That said, the error message you got is not very explicit. I will see if giving a nicer error message can be done without any significant speed penalty (I'm thinking of people who create massive arrays of values with uncertainties).

[cmarqu]

Thanks. A nicer error message would be good if it can be done without drawbacks; this had me baffled for a bit. And possibly, if "std_dev is a percentage of a nominal value" is a common construct, it might even make sense to support it as an input/output format, but that's for you to decide of course.

[lebigot]

Version 2.4.3 now has a nice error message, your feedback was very useful! Version 1 had a similar error message, which probably got lost in version 2, when I changed the API.

As for "standard deviation is a percentage of the nominal value", I believe that it is not common enough to warrant a special treatment. In your case, I would write rngsh * ufloat(1, 0.03) (i.e. rngsh_(1±3%)) instead of ufloat(rngsh, 0.03_abs(rngsh)).