There is a staggering amount of #if @is_half@ :), open to any suggestions to avoid them. We can convert the PyObject of half itself to float and try perhaps?

Kinda resolved in 07b4614, not very happy with the solution, hence keeping this thread open to suggestions,

Hi @mdickinson, can you please help me understand how we arrive at 970 for 64 bits? It exactly gives 1.7976931348623158079e+308 when max is 1.7976931348623157e+308. Please ignore {MAXEXP - NMANT}, it was just a placeholder. [EDIT], to be more specific, how can we get it via MAXEXP, NMANT, etc

This is in reference to https://github.com/python/cpython/blob/e18d81569fa0564f3bc7bcfd2fce26ec91ba0a6e/Lib/test/test_float.py#L1332

Also, thanks for the extensive testsuite, was able to find a myriad of bugs :).

0x3fffffffffffffp+970 represents the smallest positive value that overflows rather than rounding to a finite number.

As to derivation: the maximum finite representable value is 2**DBL_MAX_EXP - 2**(DBL_MAX_EXP - DBL_MANT_DIG) (in terms of the constants defined in the C standard). However, this isn't the boundary at which we start to overflow: that boundary is halfway between the above value and 2**DBL_MAX_EXP, so it's 2**DBL_MAX_EXP - 2**(DBL_MAX_EXP - DBL_MANT_DIG - 1), which assuming IEEE 754 binary64, is 2**1024 - 2**970, or (2**54 - 1) * 2**970.

For IEEE 754 single-precision (float32), the corresponding boundary would be 2**128 - 2**103, or 0x1ffffffp+103. For float16, it would be 2**16 - 2**4 (0xfffp+4):

A bit off-topic, but there's something a bit funny going on with int-to-float32 conversions in NumPy. I suspect a double-rounding through float64 first.

>>> np.float32(2**128 - 2**103)  # ok: gives infinity, as expected
inf
>>> np.float32(2**128 - 2**103 - 1)  # bad: expect a finite result, get infinity instead
inf

It looks as though the actual boundary is at 2**128 - 2**103 - 2**74 instead of 2**128 - 2**103:

>>> np.float32(2**128 - 2**103 - 2**74)
inf
>>> np.float32(2**128 - 2**103 - 2**74 - 1)
3.4028235e+38

Thanks a lot for the explanation @mdickinson! Will incorporate the same.

I just realized after pushing, if we go beyond float instead of beyond half, we'll return at line 2094's if and the message will be .. too large for float instead of half. Hmm, half is getting real tricky with a lot of edge cases. Will see how we can handle this.

Did this get handled?

I think wouldn't worry about this one. Yes, it would be nicer to report half, but overall it doesn't matter too much.

Rather than float barrier, it may be a bit faster/easier to explicitly check for an inf result (and that it was not inf before) for scalar cases.

That change probably fixes the piodide error indirectly: It doesn't properly support FPEs.

As a compromise, I removed the @name@ so we don't get an incorrect message.

Small nitpick, but please return -1 on error, it is just the more common convention.

Edited in 8d7bc55

Can you use the string for pi or np.sqrt(sctype(2)), but will differ on platforms anyway...

Oh, I did not fully get it, Do you mean change it to individual type's string so it's uniform across platforms?

Do we have to round here?

I think we don't need to round here. I don't have a mathematical proof as to why we don't need to round off, however, purely guessing from the tests passing.

I think wouldn't worry about this one. Yes, it would be nicer to report half, but overall it doesn't matter too much.

Rather than float barrier, it may be a bit faster/easier to explicitly check for an inf result (and that it was not inf before) for scalar cases.

That change probably fixes the piodide error indirectly: It doesn't properly support FPEs.