Andrew Barnert wrote:
> if you’re going to be a pedant, the floats in
> whatever Python you’re using right now are probably 854/754-1985 doubles, not
> 754-2019
> binary64s.
Mr. Andrew Barnet,
if pedant means adhere to the standard, yes, I'm a pedant.
> > This is because NaN, IMHO, it's not the right name
> > for the entity. A number can't be Not a Number. It's an Undefined Number.
> OK, so you really are arguing against IEEE float here.
So now I'm no more a pedant. No, I'm an heretic, because I don't like the Not A
Number name but I prefer Undefined Number?
A rose with any another name has the same smell.
> > But IEEE 754-2019 is written mainly for C and
> > Assembly. And you can't return nothing in a comparison between two floats.
> > So they take
> > the most practical solution: return false.
> > They defined a whole complicated system of signaling vs. quiet nan values
> > and
> signaling (on sNaN) vs. non-signaling operations and multiple forms of
> exception handling
> from traps to checkable flags to substitution of default values. You can use
> much of that
> in C (and all of it in assembly) if you want to, even if people usually don’t.
Yes, I perfectly know, I read the specs. You forgot the payload. Thank you for
confirming what I said.
> Also, who says you can’t return nothing in a comparison between two floats?
> You can
> write a named function that has any API you want (say, it returns -1, 0, 1,
> or NaN, or
> even an enum of less, greater, equal, left nan, right nan, both nan, other
> incomparable)
> instead of a Boolean function that has to return true or false.
First, C and assembly has no boolean type. And I can write whatever I want, but
IEEE 754-2019 clearly says that every comparison with NaN must return false,
that is zero in C.
> But the fact that C (and countless other languages, including Python) also
> provides the
> operators and people use them extensively implies that many people don’t
> think the
> operators are useless, even if you do.
I never said the operators are useless. Can you quote please?
> > This obviously does not apply to total ordering. Even
> > if I think mathematically has no sense, IEEE 754 clearly defined a total
> > ordering, also
> > for NaNs. So a total_ordering() key function, passed to sort functions,
> > should order as
> > IEEE 754 declares, without raising exceptions. There's a bug opened
> > somewhere about this
> > key function.
> > This is what I've done. Unluckily, the API now works this way. It's not a
> > big problem
> > anyway. You have only to pass as key to the sort function:
> > def sortNans(x):
> > try:
> > if math.isnan(x):
> > return float("+inf")
> > except TypeError
> > pass
> >
> > return x
> >
> But this isn’t the same thing that IEEE totalOrder defines.
I clearly stated that the key function total_order() is being developed, that
there's a bug opened by Tim Peters and that what I wrote has nothing to do with
total ordering. Can you please read my post with more attention? It's a bit
frustrating to explain the things two times, and it's not respectful for who
writes.
_______________________________________________
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/NJOTBTLR3JIJBATTF56J3ZCY2DSIFL5J/
Code of Conduct: http://python.org/psf/codeofconduct/
