Closed cmarqu closed 10 years ago
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).
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.
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))
.
With uncertainties 2.3.6 (the newest I have available easily), when I write
I get
You may ask why anybody would use negative values for std_dev here. Well, it's because my original code was
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?