`set` API and various sorting problems
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.
I'm sorry Marco, you seem to have changed the subject line to discuss the set API and sorting, but then went on to discuss NANs without mentioning sets or sorting. Regarding NANs: Marco said:
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.
You are correct that numbers cannot be "Not a Number". But NANs aren't numbers. They are floats, which tells you the *type* of data they are (not a string, not an int, not a list, not a bool, but a float). But floats aren't necessarily numbers. Some floats are numbers (1.0, 7.5, -2.25 etc) but some floats are not numbers, they represent a non-numeric value which is called "Not A Number" or NAN by the standard that defines them and their behaviour. We cannot assume that since *some* floats are numbers, *all* floats are numbers. That's simply wrong. In Go, "runes" (Unicode code points) are represented by 32-bit integers. But not all runes are valid Unicode code points: some of them are code points, but some of them are just... something else. "Not a code point" perhaps. Going against the name "NAN" is a losing proposition. You're arguing against the standard, and every programming language which follows the standard. And even if you convinced everyone to use "Undefined Number" instead, you're left with an even more confusing situation: what on earth is an undefined number? Is it related to (say) the Javascript Undefined value? Is an undefined number what you get when you declare a variable as an int but don't define it? number: int -- Steven
Steven, can you please remember me what operations can return NaN? I remember for example 0/0 and +Infinity - +Infinity.
Marco Sulla wrote:
First, C and assembly has no boolean type.
Not to focus on this because it's not particularly relevant to the original topic, but this isn't true: C99 added the boolean type "_Bool", which can be aliased as "bool" with the <stdbool.h> header. On Thu, Dec 26, 2019 at 8:53 PM Marco Sulla via Python-ideas < python-ideas@python.org> wrote:
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-leave@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/NJOTBT... Code of Conduct: http://python.org/psf/codeofconduct/
participants (3)
-
Kyle Stanley -
Marco Sulla -
Steven D'Aprano