<https://github.com/eobermuhlner/kotlin-big-math#comparison-with-standard-kotlin-library>

# mathematics

[breandan]

https://github.com/eobermuhlner/kotlin-big-math#comparison-with-standard-kotlin-library

[Iaroslav Postovalov]

👀

[breandan]

cc: @Eric Obermuhlner @voddan

[breandan]

https://github.com/Kotlin/KEEP/issues/49

[breandan]

@Ugi https://github.com/ionspin/kotlin-multiplatform-bignum

[Ugi]

Hey Brendan, could you give me a short overview on what's the discussion here?

[breandan]

I was just looking at your code and trying to figure out if maybe there was a common solution to these precision and type conversion issues:

https://github.com/JetBrains/kotlin/blob/master/libraries/stdlib/jvm/src/kotlin/util/BigDecimals.kt

https://github.com/ionspin/kotlin-multiplatform-bignum/blob/master/bignum/src/commonMain/kotlin/com/ionspin/kotlin/bignum/decimal/BigDecimalExtensions.kt

https://github.com/eobermuhlner/kotlin-big-math/blob/master/ch.obermuhlner.math.big.kotlin/src/main/kotlin/ch/obermuhlner/math/big/kotlin/bigdecimal/BigDecimalMathOperators.kt

[Ugi]

If you have any suggestion on how to improve the BigDecimal, feel free share your thoughts, the API is still up for improvements, especially since I was mostly concentrating on BigInteger API.

[altavir]

We've recently added our own implementation of BigInteger based on Commons-math to Kmath: https://github.com/mipt-npm/kmath/blob/dev/kmath-core/src/commonMain/kotlin/scientifik/kmath/operations/BigInt.kt. I personally do not use Big number much, so I do not know what are the requirements. And it is not the code I wrote myself, so the review and comments are welcome. Also I think it does not make a lot of sense to have separate implementations. If one of those is better than the others, I propose to join forces. Of course, for Kmath we are mostly interested in multiplatform implementations.

[breandan]

Personally, I would prefer if toString() matched the behavior of Python, e.g. valueOf(2.0) / valueOf(3.0) / valueOf(0.7) should return 0.09523809523 instead of 1.0 (as it currently does in the stdlib)

[breandan]

To do it properly, I think you need some kind of symbolic representation like MST, but maybe there is a simpler solution IDK

[breandan]

Ideally, you would never loose precision as more operators are added to the expression

[Ugi]

Ah, I see, well pull requests or an issue with a detailed description/plan is welcome! I don't have time to work on it at the moment but would love to see improvements on that side at some point. Thanks for bringing it up!

[Ugi]

Also I think it does not make a lot of sense to have separate implementations. If one of those is better than the others, I propose to join forces.

@altavir I agree, I'll look into possibilities of unifying efforts. Currently I'm a bit limited on time, and I have a hard requirement for native implementation (especially linux Arm64), so I'll keep slowly pushing on my implementation, but keep unifying the code in mind.

[altavir]

@Ugi We sadly do not currently support native, because it requires a lot of work. But I expect to support native since Kotlin 1.4 And multiplatform algoritms should work there.