Heh, so NaN is, pretty literally, “not a number”, but infinity is ?

Math-wise at least that doesn’t make sense, infinity has a meaning as a notation in the context of limits, but it’s neither a number nor even a value.

Python-wise, we already treat nan and the infs as a special thing, in the floor, ceil, round and int functions. All those disagree that infinities are “like all others”, and reject them.

This is going to go too much off topic if I have to explain you why that phrase “inf is not a number” that you hear some Calculus teachers and students repeat is wrong. Let me just leave it as there is no such thing as “number” in mathematics to be saying that inf is not one of them. So the phrase doesn’t make sense, it doesn’t convey any meaning. And there are multiple concepts with names “… numbers”, of which inf is one of them.

I would like to correct something I said in what you quoted. I intended to say “value” instead of number. As in float('inf') is a value of float, like any other.

It is a different thing having a function not defined on a value of float, due to not having a useful definition, from that being some suggestion that something is not a valid value. For example, / doesn’t like to have float(0.0) as the second operand.

I think that many of these suggestions regarding float (another that I saw is this one) come inspired from looking at floating point numbers with bounded precision as real numbers with a deficiency. Floating point numbers with bounded precision are a structure of its own and the boundedness of the precision is a feature. As such, I see having functions like +, -, *, /, and Euclidean division //, % as internal operations as useful. And as a consistent feature. You do operations on its values and obtain some other of its values. Compare to int, which does model \mathbb{Z}, assuming sufficient memory, in which the same is true.

That’s just WAY too philosophical here. I mean, if we want to get into a debate as to whether or not there are numbers, we can also discuss whether or not you and I even exist. Kinda irrelevant

What matters is that floats and ints represent numbers, and occasionally other concepts (NaN and Infinity are values that aren’t numbers, but are floats), so if it’s better to talk about “values” rather than “numbers”, then sure, but I think most of us would prefer to just accept that 3 is a number and have done with it.

You’ll have to explain (a) what you mean, and (b) what the relevance is. I’m a bit lost here. So when a mathematician talks about countung numbers or prime numbers, they’re not really numbers, they’re just called that?

Too much of a digression from the topic of this thread. Values of float is the topic and values of float is what I intended to write in the message. I just posted it too fast. In some other place I could explain further.

Thanks. I think there’s a rationale to set infinities apart from math numbers by coming back to the set-theory definition of N, then Q, then R, but as the original message I was answering to was sort-of amended this is kind of moot.

I only meant that “number” is not a concept in mathematics, but a common language one. Mathematics doesn’t need it, since no theorem is going to have it as hypothesis.

Instead “real numbers”, “rational numbers”, “complex numbers”, “extended real numbers”, “surreal numbers”, … are the ones that are concepts. They have surnames, and in some of them there are elements called \infty is an element (or many of them) of its own right with its own algebraic properties. That’s all.

Yes, there is no need for this thread. I mean to write “value of float” in the other thread.

How is that a limitation? How is it useful for a+1==a to be true? Remember, infinity is NOT an actual number; it is a concept. You cannot say “therefore a = inf” as a solution to an equation.

This sentence is meaningless. Infinity is a floating point number. And finite floating point numbers are also concepts. float('inf') is one element of the structure of floating point numbers, just as 1.0 and float('nan') are.

Note that x + 1 = x has also as solution sys.float_info.max and many other finite (and moreover elements for which is_integer() returns True) float.

Let’s not segue again in the numbers / not number debate, in this instance we were restricting ourselves to “fints”, aka floats on which f.is_integer() is True, which are numbers in any sense of the term. Infinities are not “fints”, so that point is moot.
Franklin was not thinking about infinities when showing the equation example in the first place, but on those large finite float values on which f+1.0 gets rounded down to the starting value.

It’s a floating-point value, but it is not a number. And, okay, yes, 2**53 is another number which is equal to itself plus one. But that is still not a solution to an equation. How is it useful as a feature?

That’s a gross misrepresentation. Floating point values CAN be compared for equality, but it doesn’t always behave in a way that is intuitive when you start from an assumption of decimal floats, and the issues generally show up when working with fifths - that is to say, fractions. Not integers. Testing a+1 == a is most absolutely NOT undocumented behaviour.

I don’t understand what is going on in this thread, other than a lot of float FUD.

The “is still not a solution to an equation” makes no sense. The value certainly satisfies the equation. As well as “is not a number”, since there is no such concept.

The reason we were talking about propositions/equations satisfied/satisfiable by one structure and not another is that they give you an indication of how different the structures are. In this case, the fact that floating points for which is_integer() returns True is not a sub-structure of int. The PEP draft observes that the set of values of the first is a subset of values of the second, but values represented is not what is important, functionality/behavior is.

At the end of the day, all of it is indication of how much one can expect that changing the type of the output of // will be a breaking change. Again, note that x+1=x is but one example.

I understand your point, my stance is that more specifically than this, documented and/or reliable behavior(/features/functionalities) are what’s important.
Among those, the only ones that are different between int and float are .hex() and direct typechecks. This is because as I explained earlier, values satisfying your “equation” (which is even less an actual concept in python than “number”) are not reliable across systems, implementations and installs. Therefore, that makes it as unreliable as can be, so it’s fine to break it by substituting it with an int - which is reliable in that it never satisfies mathematically absurd equations.

So far you gave two, which I explained why I considered them invalid. The ones I recognize are .hex() and direct typechecks.
As this could go, I suspect that many of the differences you can cite would turn up to be features of the int type lacking for the float type. But feel free to try again.

You already tried to use the “there’s no such thing as numbers” argument and then refused to elaborate. It’s not an argument. Numbers ARE viable concepts and they are extremely useful.

I think this is a useless thread. Can a moderator please lock it?

The digression you two make (and which you, Chris, restarted) on what is or is not a number are indeed useless, you can both delete them.
Otherwise, we do advance valid points about the differences between int and float apis, and the consequences of having something return one instead of the other.

Please don’t feed the practice of closing feature requests because some messages are out of place or relevance. If you’re looking for those, you can start with the requests to rollback PEP3141’s change to math.floor and round, but don’t condemn my proposal just because of this noise.

I can just move the number theory digressions to the number theory thread that I already split off a bunch of posts into earlier (but it seems that discussion continued here, instead). Can we please try to keep that discussion in its own thread going forward, so others can discuss the more concrete merits of the proposed idea here?