Deprecate hex2num and num2hex

[simonbyrne]

See #22031. I'm open to suggestions for the deprecation message for hex2num.

[tkelman]

at-deprecate doesn't need the =, right?

[simonbyrne]

Good point.

[rfourquet]

Instead of getting rid of those functions, I would prefer to transfer the functionality somewhere else. I didn't know them until few days ago, but I find num2hex in particular useful, as an alternative to bits which is harder to read (because counting a lot of 0s and 1s on the screen is difficult. So I propose as the path forward:

1. Fix the bugs in those functions (check overflow in hex2num (fix #22031) #22039)
2. deprecate (EDIT: cf. RFC: deprecate hex2num and num2hex, alternative to #22088 #22203), but incorporate num2hex into bits via an additional argument (bits(x, hex=true)), and hex2num maybe in parse (cf. e.g. coalesce (bytes2hex, num2hex, hex) and (bin, bits, etc.) #14418 (comment)).

[ararslan]

I agree that the functionality should still be easily accessible. Having to do reinterpret(Float64, parse(UInt64, s, 16)), for example, is a little unfortunate.

[simonbyrne]

I agree that the functionality should still be easily accessible. Having to do reinterpret(Float64, parse(UInt64, s, 16)), for example, is a little unfortunate.

I disagree: it's not clear exactly what the use case of this function is, and as discussed in #22031 it seems to encourage poor practices.

[rfourquet]

hex2num acts as the opposite of bits, so if one is available in Base, the other should also be available IMHO. As Julia is a language where we can play easily with bits (and even create primitive bit types!), I feel that those functions are a nice fit in the base library. Everyone seems to agree that the names should be changed though.

[joa-quim]

Everyone seems to agree that the names should be changed though.

I do not. Those are the names used in Matlab (not by coincidence I guess) and I feel that a change will only bring pain to Matlab users for no real gain.

[tkelman]

matlab doesn't have dispatch, so a lot of its API naming choices aren't that useful in terms of what we should do (str2num anyone?)

[stevengj]

@rfourquet, if you just want to read the hex format of a floating-point number, why not use reinterpret?

julia> reinterpret(UInt64, 3.7)
0x400d99999999999a

If you really need it as a string you can always use repr or show.

I have yet to see a defensible practical usage of hex2num/num2hex that isn't better to do via reinterpret. bits is different because there is no native Julia type that prints as binary.

[rfourquet]

Yes you are right. Probably when I like to see the bits, in hex or binary form, I think "bits" rather than "reinterpret" in my head ;-) Still, reinterpret needs you to specify an unsigned type with the correct width.

[stevengj]

We could always add a reinterpret(Unsigned, x) method that automatically infers the width.

[rfourquet]

That's exactly how I implemented bits(x, hex) in #22203 ! Still, I find it convenient. And it can be needed also programatically (not only to see it printed on screen).

[stevengj]

The question remains, what real application needs a hex form of a Float number as an actual string object that isn't served at least as well by reinterpret?

As I mentioned in #22031, the only usage of hex2num/num2hex that I found in any package would be greatly improved by switching to reinterpret.

[rfourquet]

I'm all for deprecating num2hex, but I feel it doesn't overload Base too much to add an optional argument to bits to have the number displayed in hex instead of binary.

[stevengj]

I don't see the value of complicating bits in this way, vs. just recommending reinterpret(Unsigned, x). Why have two ways to do this?

[stevengj]

Adding 1.0 milestone since we should really get a decision on this.

[JeffBezanson]

Triage is in favor. Let's rebase and merge.

[simonbyrne]

done.

[fredrikekre]

reintepret -> reinterpret

[ViralBShah]

This needs an entry in NEWS.