On 3/4/20 11:43 AM, Steven D'Aprano wrote:
On Wed, Mar 04, 2020 at 04:21:46PM +0000, Mark Dickinson wrote:
I'd argue that on a practicality-beats-purity basis, it wouldn't be unreasonable to register both `Decimal` and `float` as implementing `TotalOrdering` (or whatever the ABC ends up being called).
And that seems perfectly practical until somebody tries to compare or sort floats and discovers that they actually don't implement a total ordering if any NANs have crept into their data.
This can be a genuine pain point:
and various other discussions.
Yes, because of the NaN issue, you sort of need an 'Almost Total Order' and 'Really Truly a Total Order', the first allowing the small exception of a very limited (maybe only one) special value that breaks the true definition of Total Order so that we could call Floats to be an Almost Total Order. This wouldn't help the median issue as having median reject being given Float values because they don't form a true Total Order would be much worse than the issue of it getting confused with NaNs.
The presence of NaN in the float system does add a significant complexity to dealing with floating point numbers. Sometimes I wonder if since Python supports dynamic typing of results, might not do better by removing the NaN value from Floats and Decimals, and make the operations that generate the NaN generate an object of a special NaN type.