I wonder if Kotlin will have sumBy and sum for Lis...
# announcements
t
I wonder if Kotlin will have sumBy and sum for List<BigDecimal> in the future? Useful in banking system, and one does not have to write his own:);)
r
#C0B8Q383C
t
Thxs:)
👍 1
m
For now you can use fold. Or create an extension function until it makes it into std Lib.
t
I know:) And I have this function, but should be a part of Kotlin:);)
r
I think you'll fine "it should be part of Kotlin" to be a rather controversial statement. Personally, I don't think it should.
👍 2
e
Why not? Kotlin stdlib has a separated package for JVM-specific collections and predefined set of overloaded `operator`s to work with Java Big*s. Also, summing a lot of those is quite an operation, which is better be written and optimized once and for all
Forget about summing, though, it is pretty fast
k
I don't think there's any optimization to be done on
.fold(BigInteger.ZERO, BigInteger::add)
t
Than why is it part of stdlib for double, byte, int?:)
e
@karelpeeters the problem I thought might be that you create a new object of
BigInteger
every time (because you do), but that's exactly what's not an issue, I've discovered yesterday
a
.fold(BigInteger.ZERO, BigInteger::add)
Why not
.reduce(BigInteger::add)
? 😛
k
@Egor Trutenko Yeah you'll have to create one anyway, they're immutable.
@arekolek Because that doesn't work for empty lists!
👍 2
e
@karelpeeters ikr. You might avoid creating new BigIntegers if you operate on bytearrays. This way, you'll have only one instance of a bytearray, which will in the end of operations be converted to resulting BigInteger, for example. But again - it's not worth a try, Big*s in Java are insanely fast, even though you'll create 10000 instances of BigInteger just to sum 10000 input BigIntegers
k
Turns out you can get better performance with reflection: https://stackoverflow.com/questions/7863023/java-mutable-biginteger-class, of course that's still a bad idea.