[issue27975] math.isnan(int) and math.isinf(int) should not raise OverflowError

[Mark Dickinson]

Mark Dickinson added the comment:

Closing this as "won't fix". I agree with Tim that the right way to handle this 
is to make math.isnan behave like math.floor and math.ceil currently do, via 
new special methods, but (1) I think introducing new special methods should 
probably be a PEP-level change, and (2) I'm afraid I'm not motivated enough to 
implement it, so it's going to have to wait on someone who has that motivation.

--
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed
type:  -> behavior

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27975] math.isnan(int) and math.isinf(int) should not raise OverflowError

[Mark Dickinson]

Mark Dickinson added the comment:

> as would `math.isnan(Decimal('1e500'))`

Whoops, no. I'd forgotten that large finite `Decimal` objects end up as `float` 
infinities under conversion. Not sure I like that much, but it is what it is ...

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27975] math.isnan(int) and math.isinf(int) should not raise OverflowError

[Mark Dickinson]

Mark Dickinson added the comment:

[Steven]
> Versus the even simpler model:
> "Return whether the number x is a NAN."

But what you're proposing doesn't match that description! Under your proposal, 
`math.isnan(10**1000)` would be `False`, but `math.isnan(Fraction(10**1000))` 
would again raise an `OverflowError`, as would `math.isnan(Decimal('1e500'))`.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27975] math.isnan(int) and math.isinf(int) should not raise OverflowError

[Steven D'Aprano]

Steven D'Aprano added the comment:

On Tue, Sep 06, 2016 at 05:59:08PM +, Mark Dickinson wrote:
> Why do you single out `int` for special treatment, 

Mostly as a demonstration for what could be done, not necessarily as 
what should be done. Secondly as a potential optimization. Why go to the 
expense of converting something to a float when there's a much 
cheaper(?) test?

> but not `Fraction` or `Decimal`?

They're not built-ins. They would have to be imported first, before you 
can test for their types. That could be costly, and it would rarely be 
necessary.

> How should the implementation handle Fraction objects, and why?

If some hypothetical subclass of Fraction provides a NAN or INF value, 
trust that float(x) of those values will return a float NAN or INF. If 
the conversion overflows, the value isn't a NAN or INF.

> How should the implementation handle a Fraction-like object 
> implemented by a user?

As above.

> Why only objects of exact type `int`, but not instances of subclasses?

Subclass of int might hypothetically implement their own NAN or INF 
values. In which case, trust that MyInt('nan').__float__() will return a 
NAN float as it is supposed to.

> Your suggestion replaces a straightforward 
> mental model (math.isnan converts its input to float, then operates on 
> it, just like almost all other math module functions) with something 
> more complicated.

Not more complicated. An even more simple *model*. The existing model 
for (let's say isnan):

"Convert the number x to a float, which may Overflow, then return 
whether the float is a NAN."

Versus the even simpler model:

"Return whether the number x is a NAN."

(Which of course hides a more complex *implementation*.)

Versus the practice of pushing the complexity onto the users:

"Oh gods, what sort of number is my x? If I pass it to math.isnan, will 
it blow up? Better wrap it in a try...except ValueError just in case. 
[Later] Ah, dammit, I meant OverflowError! Oh no, is there an 
UnderflowError for Fractions?"

I guess the argument boils down to whether we want to prioritise 
simplicity or usefulness in the math module.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27975] math.isnan(int) and math.isinf(int) should not raise OverflowError

[Tim Peters]

Tim Peters added the comment:

The only sane way to do things "like this" is to allow types to define their 
own special methods (like `__isnan__()`), in which case the math module defers 
to such methods when they exist.  For example, this is how 
`math.ceil(Fraction)` works, by deferring to `Fraction.__ceil__()`.  The math 
module itself knows nothing else about what `ceil(Fraction)` could possibly 
mean.  All it knows is "if the type has __ceil__ use that, else convert to 
float first".

I'm also -1 on adding masses of if/else if/else if/.../else constructs to the 
math module to build in knowledge of the builtin numeric types.  Do it "right" 
or not at all.

I'd just be -0 on adding masses of new __isnan__, __isinf__, ..., special 
methods.  They're just not useful enough often enough.

--
nosy: +tim.peters

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27975] math.isnan(int) and math.isinf(int) should not raise OverflowError

[Mark Dickinson]

Mark Dickinson added the comment:

> As a convenience for whom?

I was referring to the general math module model. Being able to type `sqrt(2)` 
rather than having to type `sqrt(float(2))` or `sqrt(2.0)` is a convenience.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27975] math.isnan(int) and math.isinf(int) should not raise OverflowError

[Mark Dickinson]

Mark Dickinson added the comment:

> It shouldn't be hard to do the equivalent of:

Right, that's not hard at all. But is it what we *want* to do? Why do you 
single out `int` for special treatment, but not `Fraction` or `Decimal`? How 
should the implementation handle Fraction objects, and why? How should the 
implementation handle a Fraction-like object implemented by a user? Why only 
objects of exact type `int`, but not instances of subclasses? Your suggestion 
replaces a straightforward mental model (math.isnan converts its input to 
float, then operates on it, just like almost all other math module functions) 
with something more complicated.

-1 from me.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27975] math.isnan(int) and math.isinf(int) should not raise OverflowError

[Steven D'Aprano]

Steven D'Aprano added the comment:

As a convenience for whom? Certainly not the poor user, who thinks that 
math.isnan(x) should return False if the number x is not a NAN. Since 
neither 10**1 nor 10**10 are NANs, why should one return correctly 
and the other raise a completely spurious OverflowError?

I cannot speak for the implementation, except as a wild guess. It 
shouldn't be hard to do the equivalent of:

if type(x) == int: return False  # Intentionally excluding subclasses.
try:
y = float(x)
except OverflowError:
return False
else:
... # existing implementation

but since I know nothing about the C implementation maybe I'm completely 
wrong. But as far as the user's cognitive load, I don't think that:

"math.isnan(x) might return the expected result, or it might raise 
OverflowError"

is *simpler* for the user than:

"math.isnan(x) will return the expected result".

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27975] math.isnan(int) and math.isinf(int) should not raise OverflowError

[Mark Dickinson]

Mark Dickinson added the comment:

Related: #18842

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27975] math.isnan(int) and math.isinf(int) should not raise OverflowError

[Mark Dickinson]

Mark Dickinson added the comment:

I see this as a documentation issue: the vast majority of math module functions 
are designed to operate on floats, and if given a non-float input, simply 
convert that input to a float as a convenience. If we start special-casing math 
module functions for int, Fraction, and Decimal inputs, the module is going to 
become much more complicated both in terms of implementation and in terms of 
cognitive load for the user.

--
nosy: +mark.dickinson

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27975] math.isnan(int) and math.isinf(int) should not raise OverflowError

[Steven D'Aprano]

New submission from Steven D'Aprano:

Currently, math.isnan(n) and math.isinf(n) for n an int may raise OverflowError 
if n is too big to convert to a float, e.g.:

py> math.isnan(10**1)
Traceback (most recent call last):
  File "", line 1, in 
OverflowError: int too large to convert to float


But this conversion is unnecessary. int does not support either INF or NAN, so 
there is no need to convert the value to float first. If the argument is an 
int, the result must be False.

The same applies to Fraction.

--
messages: 274568
nosy: steven.daprano
priority: normal
severity: normal
status: open
title: math.isnan(int) and math.isinf(int) should not raise OverflowError

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com