Chris Kerr

```python In [2]: (np.longdouble(2)/3).as_integer_ratio() Out[2]: (108172851219475575594385340192085, 162259276829213363391578010288128) ``` ```python In [3]: Float(np.longdouble(2)/3)._mpf_ Out[3]: (0, 27043212804868893898596335048021, -105, 105) ```

> I'm happy to change the sympy tests for this (e.g. to use `resolution`) but I do wonder if any of this should be considered a numpy bug rather than...

> The Float that you show has a slightly different value though: So if the sympy `Float` object has a value that is not the same as the numpy `longdouble`...

> Most implementations of double-double arithmetic that I've seen do not allow for a "gap" between the mantissa bits of the "low" and "high" value I was not aware of...

The difference isn't as big, but `.as_integer_ratio()` is still faster: ```python In [4]: %timeit fmin.as_integer_ratio() 9.31 µs ± 91.7 ns per loop (mean ± std. dev. of 7 runs, 100,000...

```python In [1]: import numpy as np In [2]: d = np.longdouble(2)/3 In [3]: d Out[3]: 0.66666666666666666666666666666666 In [4]: prec = np.finfo(d).nmant + 1 In [5]: prec Out[5]: 106 In...

Also potentially relevant: ```python In [28]: d = np.longdouble(2)/3 In [29]: num, den = d.as_integer_ratio() In [30]: x3 = Float(Rational(num, den), prec) In [31]: x3._mpf_ Out[31]: (0, 108172851219475575594385340192085, -107, 107)...

Well spotted. With `precision=prec` the values are the same: ```python In [52]: d = np.longdouble(2)/3 In [53]: num, den = d.as_integer_ratio() In [54]: x = Float(d) In [55]: x._mpf_ Out[55]:...

I found an even worse example `3483252843105403 / 13933011372409071` which is just greater than 1/4. For this number, the precision estimated by the number of bits in the mantissa is...

I also noticed the possibility of setting `__attribute__((endian(host)))` in the kernel, so maybe this is less important than I thought. However, I also noticed that `cltypes` doesn't include types for...