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 🙏🏽

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

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.

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)?

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,
)

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

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!

Got it, thanks for clarifying!

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?

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

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

?

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...

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.

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...