UFloat doesn't need to be like float. Drop certain features.
#295
Replies: 9 comments 11 replies
-
|
@jagerber48 I mostly agree with this. Well, except that
OK. Can UFloat can equal a UFloat? I might suggest that also be False, so that class UFloat:
def __eq__(self, other):
return False
OK. Just to be clear, with those undefined,
Is "should never" correct there? I believe that a ufloat_is_invalid = x.std_dev is None or x.std_dev =< 0 or x.std_dev < 2.2e-16*abs(x.nominal_value)should be considered invalid and non-sensical. It may be OK to have UFloats with std_dev = zero or More specifically, I thin we do not need to test any calculations or make promises about results with I would be OK if the function def ufloat(nominal_value, std_dev): # note: no default values
if std_dev is None or std_dev =< 0 or std_dev < 2.2e-16*abs(nominal_value) : # note: abs(nominal_value) must work.
return float(nominal_value) # or raise ValueError(f"bad ufloat() values: {nominal_value}, {std_dev}")
return UFloat(nominal_value, std_dev)
I agree. No disagreement with your list of methods.
I am OK with dropping the methods that are there to convert float to integer ( |
Beta Was this translation helpful? Give feedback.
-
|
@newville thanks for the response! I think it sounds like we are in overall agreement. Equality Regarding comparison between But I DO think equality between So I would prefer to keep equality comparison between
I think we both agree that this is an odd case but differ in how it should be handled. Rather than get bogged down in the discussion my plan here is to handle it a certain way in the code, then show the code when I finish and we can discuss. On my first pass I will still have tests testing All of that said, if you prefer to continue the discussion here or at #283 let me know and I'm happy to do so and start addressing your points/suggestions.
I'm glad you agree with the list of methods. That will already make some work on #262 easier. Regarding |
Beta Was this translation helpful? Give feedback.
-
I think that using Also, correlations between UFloats are not well advertised and are difficult to discover without relying on identity. Is there even a simple function to display the correlation of two ufloats? What if the correlation between to UFloats is 1.0-2e-27 ? Are those equal? Identical? Since OTOH, saying For I think my view is similar: Having tests implies that there is a "right answer" and that we promise to give it. But |
Beta Was this translation helpful? Give feedback.
-
|
@newville Ok. I'm seeing your points well enough to take them. For removing equality comparison between For not testing @newville and others: Going forward I would appreciate your input on a few things. I desire these changes because they will make #262 easier, but I think I should make them in separate PRs. But these are starting to be, I think, more breaking changes than we've done previously. Will these changes go into
Also, while I appreciate Newville's input a lot, since these could be seen as moderate breaking changes I would appreciate hearing opinions from at least one other person/maintainer before merging each of these three changes. So the plan of action would be
Thoughts? |
Beta Was this translation helpful? Give feedback.
-
|
Ok, a note that's worth mentioning. After reading the comments in the modules and test I see that one of the intents of the but then if you want You would need to do something like or This touches on the conversation at https://discuss.python.org/t/math-exp-and-math-log-delegate-to-exp-and-log-methods/73495/1 that it would be nice if there were some sort of API that allowed delegation of math methods to avoid these namespace collisions for libraries that define versions of these math functions for special objects. I think it's worth bringing up the above. However, the way I use |
Beta Was this translation helpful? Give feedback.
-
|
@jagerber48 My main interest in maintaining Uncertainties was to keep it working for my use case. It came to my attention due to its dependency on the With all that said, the changes you propose regarding adding and removing functions all seem reasonable to me. It might be nice to make a release with warnings about the removals before removing them. Regarding standard deviation of 0, it also seems fine not to support it. Perhaps a warning could be issued when 0 is passed to Regarding equality of I think the net result of all these changes are it is less likely that a function written for floats will "just work" with |
Beta Was this translation helpful? Give feedback.
-
|
I just made a message to @andrewgsavage above discussing the release strategy in the event that we DO choose to remove any of the features under discussion. In this post I want to give an update on where everyone stands on the features in question. Remove some
Remove
No longer allow
No longer special case I think everyone expressed support for So I am (through biased eyes) seeing some agreement we can drop the But it seems more discussion is needed about the comparison operators. Let me address this again. First off, I want to give a reminder that these comparison operators on Regarding the sorting operation: There is already the ambiguity I just mentioned that, for random variables these comparison operators are statistical. But there is another ambiguity: Should |
Beta Was this translation helpful? Give feedback.
-
|
@jagerber48 has stated my opinions correctly. I agree that the discussion here is mostly about what "4.0" should look like, and that deprecations for removed features will be needed (once we agree on what to change.) Needing to sort or compare |
Beta Was this translation helpful? Give feedback.
-
|
While I haven't read every message or everything in detail, I can share a few points:
Historical note: my reasoning, for handling < and >, was that (1) users with existing float code could use UFloats as a drop-in replacement, and comparison operators would behave similarly similarly to what they did before; (2) comparing 1±0.1 and 42±0.1 is relatively meaningful, based on an idea similar to linear error propagation theory requiring uncertainties to be "small", so my reasoning was that users were similarly responsible for keeping comparison meaningful. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
It seems that when
uncertaintieswas written there was some intent to makeUFloatlike a LSP safe subclass offloat. That is, anything you can do with afloatshould be possible to be done withUFloat. This includes passingUFloatthrough the function in themathmodule, but, since that isn't directly possible, theumathmodule was written, trying to duplicate every function in themath. module.I think this goal was too much and has created a maintenance burden for features which I doubt are used broadly. I reach for
UFloatwhen I am representing a result of a physical measurement or the result of fitting to physical data. I am probably doing basic algebra to myUFloatobjects or at least putting them through some continuous physical model. This means I'm typically dealing withUFloats with non-zero standard deviations and I am putting them through mathematical functions that a physicist would encounter, but I'm NOT putting them through mathematical functions that a computer scientist would encounter.I propose we drop support, on the
UFloatclass, for certainfloatfeatures.UFloatandfloatshould never beTrue, even if theUFloathas zero standard deviation.<, <=, >=, >should not be defined onUFloat.UFloatwith zero standard deviation should never behave like afloatin terms of uncertainty propagation. See Problem with special casingstd_dev = 0#283.mathmodule should not be supported inumath. See below for an enumeration of which functions should be supported and which shouldn't.UFloatinstance methods should likewise be dropped.These changes are largely motivated by asking the question: if we think of
UFloatas modeling a normally distributed random variable, then does this operation make sense? For example, considerUFloat(0, 10) > UFloat(0.1, 10). Thinking of these two objects as normally distributed random variables, then on a single sampling there is a basically a 50% change forTrueand50%chance forFalse. It doesn't make sense to assignFalseto this expression just because of the comparison on nominal values. Hence, it just should be legal to take>onUFloat.More details about
umathversusmath. Here is a script comparing (for Python 3.12) which functions are present inmathandumath. After running the script I added Yes/No comments indicating which functions I think should be included inumathand which I think should not.Essentially if you could imagine using the function on real number representing physical measurements then the function is a yes. E.g. real inputs and real outputs. If the inputs or outputs involve rounding or integers then it is probably a no because it may be ambiguous what the function "should" do based on the range of std_dev. Does it makes sense to round
0.75 +/- 12to1 +/- 12by just rounding the value? Should the std_dev be coerced to 0 in the case of rounding? What actual use cases are we covering? Here is a summary of the changesRemove:
ceilcopysignexpm1fabsI could be convinced to keep thisfactorialfloorfmodI could be convinced to keep thisfrexpisinfisnanldexpmodftruncAdd
cbrtwhenuncertaintiesdrops support < 3.11distexp2whenuncertaintiesdrops support < 3.11log2prodsumprodSome of the corresponding instance methods on
UFloatshould also be dropped:__floordiv____mod__I could be convinced to keep this__div__(This is a Python 2 relic, replaced by__truediv__)__abs__I could be convinced to keep this__trunc__More discussion. Let's think about
X = UFloat(0.75, 12.2)as a normally distributed random variable with mean0.75and12.2. If we takeround(X)then there is a good chance the result is 1, but there is also a chance the result is 2, -1, -3 etc. The distribution is also no longer normally distributed because the sample space has change from the real numbers to the integers. If we think ofXas a normally distributed random variable than the result ofround(X)is not longer a normally distributed random variable so we should not allow it to be aUFloat.What are others' thoughts on dropping support for these things?
Beta Was this translation helpful? Give feedback.
All reactions