I'm mourning the fact that there's no sumOf for fl...

# stdlib

[Zoltan Demant]

I'm mourning the fact that there's no sumOf for float values. Does anyone know why that is, considering that alternatives exist for so many other number types? I've added it myself locally - so really just curious 🙏🏽

[Sam]

https://kotlinlang.slack.com/archives/C0B8MA7FA/p1663320897246749

[Joffrey]

Yeah I guess the question is rather, why are you trying to sum up `Float`s and not `Double`s?

[Zoltan Demant]

Interesting point wrt: "like Byte and Short, Float's use should usually be limited to storage, not computation. even Android has dropped FloatMath since Math on Double is faster."

@Joffrey Probably just routine. Whenever I work with fractions, float values make the most sense to me. 0.1f = 10% etc.

[Joffrey]

Whenever I work with fractions, float values make the most sense to me. 0.1f = 10% etc.

I'm sorry I don't get that, why not just 0.1 (a double) instead of 0.1f (a less precise float)?

[Zoltan Demant]

Its the pattern Ive come to know over too many years 😅 Not saying that its the ultimate way to do things, maybe Ill have to reconsider it moving forward -- see one example that comes to mind below (from m3 compose):

@Composable
fun CircularProgressIndicator(
    progress: Float,
)

[Joffrey]

Its the pattern Ive come to know over too many years

What pattern?

You might be missing my point. Double is also a IEEE 754 floating-point value, just like Float, but it's 64bit instead of 32bit, which is more precise and can represent larger numbers. It's also the default for decimal literals like 0.1 (unless you force the less precise 32-bit Float type by adding an f). That's why I was asking this question.

More info: https://docs.oracle.com/javase/tutorial/java/nutsandbolts/datatypes.html

[Joffrey]

So in your case, you would just need to use Double instead of Float in your composable example, and drop the f suffixes in your literals, and everything would work the same (but with more precision)

[Zoltan Demant]

I understand the precision part. What I meant by pattern is that most components I use, make extensive use of floats for their values - the CircularProgressIndicator above was just one of them (these are all part of M3, but same thing applies to other libraries).

I dont know if this has changed, but I do recall early versions of Android promoting floats over doubles as they consumed less memory. I can be wrong about that, it was a long long time ago 😛 Either way, Im not exactly sure why all (most) components use floats over doubles, could be this, could be something completely different; this has sparked my curiosity about it though!

[Joffrey]

Got it, thanks for clarifying!

[Mervyn McCreight]

but it's 64bit instead of 32bit - i think the language should not force you to use doubles. what if i’m fully aware of what a float is and i decide that this is all i need for my use-case?

[yschimke]

Isn't there some edge cases with repeated operations on floats, compounding errors?

[Joffrey]

what if i’m fully aware of what a float is and i decide that this is all i need for my use-case?

Then... just use a Float?

[Joffrey]

the language should not force you to use doubles

It doesn't. You still have the option to use the Float type, it's not even deprecated.

But the language should definitely make it more convenient to do the right thing, and avoid making the wrong things easy to do. So if the right thing is to use Double most of the time (unless you have special requirements) then the current state is a good thing. If you have those special requirements, then you should know how you want to sum up your floats and deal with the imprecision.

[Fleshgrinder]

Following this logic would mean that every Int ought to be a Long and that the language is doing it wrong right now... not sure if...

[yschimke]

This is not talking about overflow. Any sequence of int operations not overflowing, will be the exact answer. So I wouldn't worry about ints. For floats it's the rounding and imprecision, certain cases are worse I think like subtraction on a huge and tiny number, and the compound effect can dominate results.

[Fleshgrinder]

Which is also true for any other floating point number including double. Precise results can only be guaranteed by using precise libraries. Sure, double is more precise than float, but BigDecimal is more precise than double, it does not follow that we should use it everywhere. These are all trade offs. In case of integers we trade space for range and in case of floats we trade space for precision. The right choice depends. Otherwise there wouldn't be types like f8, f16, ... That the JVM only knows i32, i64, f32, and f64 doesn't mean that other ranges or precisions are bad, it's a JVM design decision. Summing a bunch of floats might be perfectly fine, might be entirely wrong, it depends...