In fact, the opposite. I'm trying to have a really...

# getting-started

[benleggiero]

In fact, the opposite. I'm trying to have a really strong reason to always have them match. So, when I distribute a JAR for 64-bit machines, I want all integers and fractions to be 64-bit. On the other hand, when I distribute the 32-bit, I want all integers and fractions to be 32-bit. I don't like this mixed approach.

[dalexander]

…But why do you want to do that? That sounds like asking for random problems to crop up.

[benleggiero]

This is how Apple does it with Foundation's NSInteger (Int in Swift) and CGFloat

[benleggiero]

That leads to a more stable and faster application, since the number is already in a form the processor can understand

[dalexander]

That… is not true. Ints should be as fast or faster on an 64 bit system because of the reduced pressure on the memory subsystem compared to longs, if the JIT thinks it will be faster it can easily translate the items into longs at runtime but I find that very unlikely to be the case. The same is true with floats for similar reasons, even though as I mentioned elsewhere the x86 FPU operates on an 80-bit object.

[benleggiero]

I'm not concerned about speed with integers so much (except that 64-bit on a 32-bit platform has extra steps) as I am with floating-point performance and memory usage (32-bit platforms being limited to 4GB).

Another topic is "why don't we have Float80 in Kotlin?"...

[dalexander]

Because the JVM doesn’t support a Float80, and such a construct would only be relevant a subset of all processors? For floating point performance you always want to use floats unless you need the extra precision a double provides. The size of the ALU (it. 32-bit vs. 64-but processor) has nothing to do with the size of the FPU.

[dalexander]

The way the JVM defines floating point behavior is fairly specific in that it tries not to use things which are platform-dependent. So if you write some C++ code targeting an x86 processor that does floating point math you might end up with slightly different results depending on if your intermediate values are stored back to registers or stay in the FPU. As far as I know that shouldn’t happen with Java.

[mattpeterson]

Even in the Swift universe Float80 is not supported by all platforms, which would be anathema for Java and, by extension, Kotlin.

[benleggiero]

If you want to use`Float` by default, and only Double when necessary, why is the default literal a Double? This goes back to my confusion about the mixed approach