Overflow when Fraction instances are created using Numpy integers

[aerobio]

Consider the following operations between fractions:

>>> from fractions import Fraction
>>> import numpy as np
>>> np.seterr(all='ignore')

>>> a = Fraction(15.09288707969291)
>>> b = Fraction(24274009, 1604460)
>>> c = Fraction(np.int64(24274009), 1604460)

>>> b == c
True
>>> a - b
Fraction(-8173385384594606777, 225807670566589562880)
>>> a - c
Fraction(3404474268251672442183, 225807670566589562880)

The last two results should be equal.

Numpy integers qualify as Rational in Fraction.__new__() and the Fraction instance uses them internally without modification:

class Fraction(numbers.Rational):
    def __new__(cls, numerator=0, denominator=None, *, _normalize=True):
        [...]
        elif (isinstance(numerator, numbers.Rational) and
            isinstance(denominator, numbers.Rational)):
            numerator, denominator = (
                numerator.numerator * denominator.denominator,
                denominator.numerator * numerator.denominator
                )
        [...]

But they may overflow, as in the example, producing wrong results when np.seterr() is set to warn or ignore.
The workaround for the user is as simple as converting inputs to Python integers, but it's not obvious that the user needs to do so.

A small change in the constructor like this would avoid the problem:

class Fraction(numbers.Rational):
    def __new__(cls, numerator=0, denominator=None, *, _normalize=True):
        [...]
        elif (isinstance(numerator, numbers.Rational) and
            isinstance(denominator, numbers.Rational)):
            numerator, denominator = (
                int(numerator.numerator) * int(denominator.denominator),
                int(denominator.numerator) * int(numerator.denominator)
                )
        [...].

CPython versions tested on:

3.10, 3.12, 3.13

Operating systems tested on:

Linux

[terryjreedy]

I believe a - c ends up calling c.rsub(a) (int64.__rsub(c, a)), which will call Fraction._sub(a, c), which calls math.gcd and Fraction._from_coprime_ints. The bug is that that numpy somewhere returns the wrong value for int * int64 in Fraction._sub instead of either the correct value or raising. The underlying bug is numpy registering int64 as Rational when it is not.

I believe your proposed fix is wrong as I think the intent is to allow Fractions with custom integral types as numerators and denominators. This works fine as long as the custom type does arithmetic as expected.

I think that this issue should be closed as I see no bug in CPython . If you want, raise an issue with numpy about mis-registering non-rationals as Rational, or about better educating users.

[skirpichev]

The bug is that that numpy somewhere returns the wrong value for int * int64 in Fraction._sub instead of either the correct value or raising.

Sure. OP just turned off floating-point exceptions. Without np.seterr(all='ignore') you will end with an informative message:

>>> a-c
/usr/local/lib/python3.13/fractions.py:784: RuntimeWarning: overflow encountered in scalar multiply
  t = na * (db // g) - nb * s
Traceback (most recent call last):
  File "<python-input-7>", line 1, in <module>
    a-c
    ~^~
  File "/usr/local/lib/python3.13/fractions.py", line 665, in forward
    return monomorphic_operator(a, b)
  File "/usr/local/lib/python3.13/fractions.py", line 784, in _sub
    t = na * (db // g) - nb * s
        ~~~~~~~~~~~~~~~^~~~~~~~
OverflowError: Python int too large to convert to C long

This works fine as long as the custom type does arithmetic as expected.

Certainly, fractions code doesn't expect modular integers as input.

raise an issue with numpy about mis-registering non-rationals as Rational

This is something that certainly does make sense for me. The numbers module offer no strict specifications for most operations over defined ABC types, yet some details clearly state that "usual" integers (bigint's!) and rationals are assumed. E.g. "The numerator and denominator values should be instances of Integral and should be in lowest terms with denominator positive." - does make sense for usual integers (with euclidean algorithm, gcd(), etc), but not for modular integers (that e.g. might have zero divisors).

Arithmetic with finite-size integers fits to this picture only if you raise exceptions on overflows. (And results match "usual" arithmetic operations, unless exception is triggered.)