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:
https://mail.python.org/archives/list/python-ideas@python.org/message/K35GTWPKNS2DSUMH63VTSWXQWVN6JASW/
https://bugs.python.org/issue33084
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.
--
Richard Damon
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/ML3BYS4BEJP3VYYBLIZSXLDW7ZT6CEK4/
Code of Conduct: http://python.org/psf/codeofconduct/
