native frexp function

[simonbyrne]

This implements the frexp function in native julia. It is roughly 10x faster than calling the libm function (as it avoids passing by reference), and doesn't require keeping a global array around (so no threading issues).

[JeffBezanson]

💯 !!

[johnmyleswhite]

@simonbyrne, world famous floating-point badass.

[quinnj]

This is awesome! I actually started a version grisu based on frexp that aimed to avoid a whole bunch of code from the native library, but the performance gains were minor. I'll have to resurrect that since it was BigFloat compatible as well. Thanks @simonbyrne!

[tkelman]

Apparently these are the first hex floats in Base. MSVC can't handle these yet, so #7761 can't bootstrap any more after rebasing this in. Can we just spell these out?

[simonbyrne]

@tkelman Sure. Maybe keep it in as a comment though, so it's clear why it multiplies by 18014398509481984.0.

[tkelman]

Like this? tkelman@a72ccd9

[simonbyrne]

Yes, that's what I had in mind.

[ivarne]

I think something like

# x *= 0x1p54 # normalise significand
x *= 1.8014398509481984e16 # normalise significand

is clearer, but that seems like a matter of taste.

[StefanKarpinski]

The hex version is infinitely clearer IMO, but that might just be me.

[ivarne]

I also prefer hex when it contains lots of 0 and F. I meant that it was clearer to have the full hex version as a comment above, not in a comment on the side.

[tknopp]

Although the hex float version is of course clearer, I think it should be ok to make a comment like @ivarne proposed. It makes @tkelman life a lot simpler for now and we should really appreciate that he moves on the MSVC support.

If there are various places like this we would have to rethink how to proceed, but a single hex-float should get a gentle exception.

By the way, #6349 is the issue that MSVC does not support hex parsing. Maybe this could be added to the comment.