#stdlib
Title
z

Zoltan Demant

07/10/2023, 12:22 PM
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 🙏🏽
1
s

Sam

07/10/2023, 12:25 PM
j

Joffrey

07/10/2023, 12:26 PM
Yeah I guess the question is rather, why are you trying to sum up `Float`s and not `Double`s?
z

Zoltan Demant

07/10/2023, 12:32 PM
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.
j

Joffrey

07/10/2023, 12:33 PM
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``
``0.1f``
(a less precise float)?
z

Zoltan Demant

07/10/2023, 12:36 PM
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):
Copy code
``````@Composable
fun CircularProgressIndicator(
progress: Float,
)``````
j

Joffrey

07/10/2023, 12:44 PM
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``
``f``
So in your case, you would just need to use
``Double``
``Float``
in your composable example, and drop the
``f``
suffixes in your literals, and everything would work the same (but with more precision)
z

Zoltan Demant

07/10/2023, 1:02 PM
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!
👌 1
j

Joffrey

07/10/2023, 1:03 PM
Got it, thanks for clarifying!
m

Mervyn McCreight

07/10/2023, 1:03 PM
``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?
y

yschimke

07/10/2023, 2:02 PM
Isn't there some edge cases with repeated operations on floats, compounding errors?
j

Joffrey

07/10/2023, 2:02 PM
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``
?
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.
2
f

Fleshgrinder

07/12/2023, 5:47 AM
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...
y

yschimke

07/12/2023, 6:08 AM
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.
f

Fleshgrinder

07/12/2023, 6:19 AM
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...
1
4 Views