[Python-ideas] Fwd: Make `float('inf') //1 == float('inf')`

[Andrew Barnert]

On Sep 19, 2014, at 2:52, Steven D'Aprano <steve at pearwood.info> wrote:

> On Thu, Sep 18, 2014 at 03:31:05PM -0400, Alexander Belopolsky wrote:
> 
>> I don't think there is any dispute over what math.floor(inf) should return.
>> POSIX, C99, IEEE and probably many other standards agree that inf should
>> be returned as long as the resulting type can represent it.
> 
> Why don't we add an integer infinity?

I was thinking the same thing.

In addition to your points, while it's not _useful_ as often, there's nothing inherently any more strange or unmathematical about an affine extended integral line than an extended real line. (In fact, if anything, not having a "largest int" akin to the largest float makes it more sensible.) And it would mean people wouldn't have to use the float -inf as a starting value for finding a maximum, they could use an actual integer.

That does raise the question of whether there should be an int NaN...

> Python int is not a low-level primitive type, it's an object, and can 
> support as rich a set of behaviour as we like. We could subclass int, 
> give it a pair of singletons Infinity and -Infinity (say), and have 
> math.floor(float('inf')) return one of them as needed.
> 
> - The subclass need not be a builtin public class, like bool, it 
>  could be a private implementation detail. The only promise made
>  is that isinstance(Infinity, int) returns True.
> 
> - The Infinity and -Infinity instances need not be built-in.
> 
> - For that matter, they may not even be singletons.
> 
> - We could, but don't necessarily need to, support int('inf').
> 
> - But int(float('inf')) and int(Decimal('inf')) should return
>  the int Infinity.
> 
> 
> 
> -- 
> Steven
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/