@simonbyrne @pkofod - Could you guys review?

@oscardssmith Should we merge if it is passing the comprehensive float16 testsuite?

If it passes, this is just free performance.

So bad news: This doesn't pass the test. Worse news, this shows that the test is actually wrong. With this PR, we can see

setprecision(BigFloat, 2048)
x=Float16(-1.089e4)
julia> cbrt(big(x))-cbrt(x)
0.0078122 ...
julia> cbrt(big(x))-Float16(cbrt(big(x)))
-0.0078127...

In other words, 2048 bits of precision is not enough for double rounding not to mess things up.

In other words, 2048 bits of precision is not enough for double rounding not to mess things up.

Interestingly, this doesn't seem to be a problem of BigFloat. But rather of double rounding from BigFloat through Float32 down to Float16, which is a separate issue, I guess. Similar example of rounding from Float64 to Float16.

julia> x = -22.164062733931335
-22.164062733931335
julia> abs(Float16(x) - x)
0.007812733931334748
julia> abs(prevfloat(Float16(x)) - x)
0.007812266068665252

IIUC, the above discussion concludes that we should merge this, as it is actually more accurate than the tests. Correct?

I'm not sure we should merge this until #40315 is fixed. Basically right now, Julia does not have a correct way for me to test this since conversion from BigFloat to Float16 is screwed up. As such, the tests are not as reliable as I want them to be. The argument for merging is that this is almost certainly good enough (.5001 ULP would be my guess), and the performance is very real and easy to quantify.

I think I'm still okay merging with knowing that. Aside: do we need to fix the definition of tryparse eventually (which currently parses as Float32) too?