Support for hexadecimal floats

Language Design
1

I don’t see why hexadecimal floats like 0x2.468p6 and 0x0.8421p5 where p is the exponent of 2 wouldn’t be added.
I’d like Kotlin to add hexadecimal floats along with binary floats.

Example

fun main() {
    println(0x1.2345p6) // 72.8173828125
    println(0b1.101010p3) // 13.25
}
1 Like
2

I can’t really come up with any argument that would be against this proposal. The only one I see is that I can’t think of any use case for this and it would be confusing to read for nearly everyone.

Also do you have any link that explains how those numbers work exactly? My guess is that it is something like

hexToDecimal(0xA.BpC) = (hexToDecimal(A) + (hexToDecimal(B) / 16^hexDigitCount(B))) * 2 ^ C
with A, B and C as hexadecimal numbers

In the end you should probably create a feature request at https://kotl.in/issue with an explanation of how the numbers work and as many usecases as you know of. That said, unless you have a very good usecase I don’t think this will be a priority and you might need to wait quite some time for this to be implemented in kotlin (if ever).
Also if you are confident enough you can try to write a compiler plugin that allows you to use such numbers. Even though those are still experimental and undocumented there are a number of talks/videos on how to use them (I think they will be released in a more official if still experimental form with kotlin 1.5). This might also help in getting this added to kotlin as a default.

1 Like
3

Given how many people seem to misunderstand what binary floating-point types are (viz. the number of questions that get asked about them…), and how often they’re used when totally unsuitable (e.g. for currency values), I’m very wary of providing any more ways to create them, or being seen to encourage their use at all!

(Also, I can’t recall a single case where I would ever have found a hex literal format for floats remotely useful.⠀I can’t help thinking that it must be a very niche use.)

If anything, I think we should be providing easier ways to create BigDecimals (which seem much more likely to be appropriate).⠀Especially since Kotlin makes them so natural and easy to use!

3 Likes
4

I have some code I’m looking at converting to Kotlin which wants these:

        /** Relative threshold for small singular values.  */
        private const val EPS: Double = 0x1.0p-52

        /** Absolute threshold for small singular values.  */
        private const val TINY: Double = 0x1.0p-966

My options are now:

  1. Pick new values in base 10 since the exact values may not actually matter.

  2. Use 2.0.pow(-52) to get the value, but for annoying reasons powers are not considered constants by the compiler.

I’ve also found a want for Double.MIN_NORMAL, which seems like it was arbitrarily dropped from Double.

The use case here is numerical calculation. I’d actually love to use fixed precision, but it’s far from usable today.

5

You’re right

You’re also right

Good for you, but that’s your individual experience

Possibly

Nobody talks about encouraging anyone to anything.

Here, you’re very wrong. You concluded that there shouldn’t be any way in a language to construct a literal of a precise floating point number, even though such a value is supported by the underlying type, from the fact that you never needed to do that and the fact the floating point values are easy to misunderstand.

What alternatives to floating point numbers are you recommending for dozens of fields where they are used because nothing better was ever invented for a given purpose? Are CAD applications supposed to use integers? How would you unit test that you geometrical algorithm doesn’t crash on a corner case (I don’t know, some close to zero subnormal values…), when you can’t even write these numbers in the source code?

Java authors were never enthusiastic with adding new and unnecessary bits to the language, and Kotlin should support hex float literals even for the single reason that Java supports them. And no, it wasn’t one of mistakes like null.

6

I don’t have a strong opinion on the main case, but do you believe engineers will be able to write unit tests by guessing the correct internal representation of a float number for a given case? Even if they could, such tests would be entirely unreadable.

7

A good engineer who understands floating point would be able to write such tests by knowing the internal representation, but I agree the tests would be unreadable by most engineers, unless suitably commented. However, self-describing code is better than comments, so in such cases the engineer should use suitable Kotlin methods to show exactly what they want, such as 1.0.nextUp(), 1.0.nextDown(), Double.MAX_VALUE, etc. instead of hard-coded numbers.

3 Likes