`QuadPrecision.is_integer()` and `QuadPrecision.as_integer_ratio()`

[jorenham]

These methods primarily exist for 🦆 type compatibility with builtins.float:

>>> (3.14).is_integer()
False
>>> (3.14).as_integer_ratio()
(7070651414971679, 2251799813685248)

However, they're a bit weird in numpy, because each of the (concrete) numpy.float* classes implement them, but they don't exist on np.floating itself

>>> import numpy as np
>>> np.longdouble(3.14).is_integer()
False
>>> np.floating.is_integer
Traceback (most recent call last):
  File "<python-input-4>", line 1, in <module>
    np.floating.is_integer
AttributeError: type object 'numpy.floating' has no attribute 'is_integer'

But because of some good reasons that I won't bore you with, the stubs lie a bit, and define these two methods on the numpy.floating type. That means that, because QuadPrecision now subclasses np.floating, type-checkers believe that QuadPrecision.is_integer and QuadPrecision.as_integer_ratio actually exist. This is type-unsafe, and could easily lead to bugs, because IDE's will also include these methods in their auto-completion now.

[SwayamInSync]

Hmm we should be able to expose our version of those functions from QuadPrecision. Would that be able to resolve this?

[jorenham]

Hmm we should be able to expose our version of those functions from QuadPrecision. Would that be able to resolve this?

Yup; that'd do the trick 👌🏻