It would be nice if BigDecimal implemented the (currently internal) interface in BigNumber of NarrowingOperations to support changing BigDecimals back to all the various basic types; Int, Long, Short, Float, Double, UInt, UShort, ULong, Byte and UByte,

Since BigDecimal is not "open" extension functions are required to do this. An example of one is below.

/**
 * Returns a long value that truncates any digits to the right of the decimal.
 *
 * @param exactRequired if true and non-zero truncation error would result
 * @throws ArithmeticException if the value is to large or too small for a long, or if
 * exactRequired true and value to right of decimal is non-zero
 */
fun BigDecimal.longValue(exactRequired: Boolean = false): Long {
    val limit = BigDecimal.fromLong(Long.MAX_VALUE)
    val lowLimit = BigDecimal.fromLong(Long.MIN_VALUE)
    if (this > limit || this < lowLimit)
        throw ArithmeticException("Narrowing to Long would lose significant digits")
    return checkTruncation(exactRequired)
}

private fun BigDecimal.checkTruncation(exactRequired: Boolean):Long {
    val result = this.divideAndRemainder(BigDecimal.ONE)
    if (exactRequired && !result.second.isZero()) {
        throw ArithmeticException("Narrowing would lose precision")
    }
    val work = this.minus(result.first)
    return work.significand.longValue(exactRequired)
}

This would provide a superset of the narrowing operations provided in java's BigDecimal

Describe the bug Hello. I'm migrating to Kotlin/Native and use your BigNum library as actual declaration for BigDecimal. on JVM I have Java's BigDecimal. Many of my tests are failing because the result of calculation on Native with your lib is different. I provide some examples. Since the migration to native is a long process I can't know all possible errors with the calculations because I comment failing tests one-by-one. The more I comment, the more errors I see. If I may I'll add more errors later.

To Reproduce All this values are not equal to what your lib show. So you can just compare both libs and find a cause of different result.

println(BigDecimal("1").divide(BigDecimal("110"), 15,RoundingMode.CEILING ).toPlainString())

println(BigDecimal("6075.6").divide(BigDecimal("0.5"), 0,RoundingMode.CEILING ).toPlainString())

println(BigDecimal("6075.7").divide(BigDecimal("0.5"), 0,RoundingMode.CEILING ).toPlainString())

println(BigDecimal("6075.8").divide(BigDecimal("0.5"), 0,RoundingMode.CEILING ).toPlainString())

println(BigDecimal("6075.9").divide(BigDecimal("0.5"), 0,RoundingMode.CEILING ).toPlainString())

println(BigDecimal("0.001294914096").divide(BigDecimal("0.000001"), 0,RoundingMode.CEILING ).toPlainString())

println(BigDecimal("93545.3695").divide(BigDecimal("1"), 0,RoundingMode.FLOOR ).toPlainString())

Another problem I met is that I can't leave decimalPrecision like default value 0 when have a scale specified. Which is strange because default value 0 should be "unlimited precision" as per the docs. I always have to provide it. I think it's not right. I only interested in scale and don't need to limit precision. Right?

Expected behavior I think the results of the lib should be the same as in Java's BigDecimal

Also there is a difference of how BigNum shows output of toExpandedString in comparison to Java's solution. It always strips zeroes from the end of a string. Is it expected? If so, why? In some places it's useful to have a text like "0.00" which gives a hint on scale of the number shown in UI. Maybe it would be a good idea to show zeroes at the end and make another function like toExpandedWithoutZeroes() or even better to change toPlainString() to show zeroes? That for would be great. Both functions will be useful then. What to you think?

Platform Linuxx64, JVM

Additional context Add any other context about the problem here.

Hi @ionspin !

I am having problem with figure rounding. I have an application that can support trailing decimal point number configuration. We have a setting that will configure this thing, so it will be dynamic.

Let's say the total decimal point number set is 3. So given number 12.5671, it will round to 12.567, if it is 2, it becomes 12.56 and so on.

I have a test case like following

and here is my round function

The purpose why I convert to BigInteger first is to get the number before the decimal point, and then use the value from the setting to add the trailing decimal point. The test case above will result to java.lang.reflect.InvocationTargetException

Can you guide me on how to directly use the BigDecimal number and then use my custom setting value to set the trailing decimal point number?

If it is still unclear to you, please let me know, so I can explain more to you. Thanks for this amazing library!

Narrowing functions that resolves #111 are mostly working. Fix #118 involved not using a roundDiscarded function when using unlimited precision. Also did some minor cleanup of Lint warnings in BigDecimal. Still needs comments, and some changes to BigInteger to allow unit tests to work in certain cases, and probably other stuff.

Describe the bug When performing two sequential BigDecimal exponentiations, the second exponentiation will hang.

To Reproduce Run the following code:

val decimalMode = DecimalMode(6L, RoundingMode.CEILING, -1L)

val a = BigDecimal.parseStringWithMode("-8.40575E+306", decimalMode)
val b = BigDecimal.parseStringWithMode("-1.77408E+308", decimalMode)

a.pow(b.longValue(false))

val c = BigDecimal.parseStringWithMode("-3.74044E+307", decimalMode)
val d = BigDecimal.parseStringWithMode("-2.22553E+8", decimalMode)

c.pow(d.longValue(false)) // Hangs here

Expected behavior Both exponentiations complete without issue.

Platform JVM and JS

Additional context For me this occurs on a multiplatform project with the browser JS and JVM targets.

Given this JVM snippet:

    val testDouble = 999111.999111
    val testBig = BigDecimal.fromDouble(testDouble)
    val newDouble = testBig.doubleValue(true)
    assertEquals(testDouble, newDouble, 0.0)

assert should work, but assert fails: java.lang.AssertionError: Expected :999111.999111 Actual :9991119.99111

I haven't tried other scenarios yet, have not finished debugging. This was using 0.2.0.

The problematic line in BigDecimal.kt is:

            this.significand.longValue(true).toDouble() / double10pow[exponent.toInt()]

In debugger, state of BigDecimal before this line is this:

this = {BigDecimal@859} "9.99111999111E+5" precision = 12 precisionLimit = 0 roundingMode = {RoundingMode@864} "NONE" significand = {BigInteger@865} "999111999111" exponent = 5 scale = -1 usingScale = false decimalMode = null

It looks like this should work but it doesn't. Still digging.

Environment is AS 4.1, Kotlin 1.4.10

Describe the bug Numbers rounded to specific number of of digits after decimal point multiply incorrectly.

To Reproduce Steps to reproduce the behavior:

val a = "5.61".toBigDecimal().roundToDigitPositionAfterDecimalPoint( 2, RoundingMode.ROUND_HALF_AWAY_FROM_ZERO)
val b = "2.95".toBigDecimal().roundToDigitPositionAfterDecimalPoint( 2, RoundingMode.ROUND_HALF_AWAY_FROM_ZERO)
val res = a.multiply(b).roundToDigitPositionAfterDecimalPoint( 2, RoundingMode.ROUND_HALF_AWAY_FROM_ZERO)
assertEquals("16.55", res.toStringExpanded())

expected:<16.5[5]> but was:<16.5[]>
Expected :16.55
Actual   :16.5

Expected behavior

Result should not loose precision same way java BigDecimal.setScale(2, RoundMode.HALF_UP)

BigDecimal bd1 = new BigDecimal("5.61").setScale(2, RoundingMode.HALF_UP); 
BigDecimal bd2  = new BigDecimal("2.95").setScale(2, RoundingMode.HALF_UP); 
BigDecimal bs3 = bd2.multiply(bd1).setScale(2, RoundingMode.HALF_UP); 
String str = "Result is " +bs3;
System.out.println(str); 

Platform JVM (commonTest run by testDebugUnitTest)

Given this code:

val x = BigDecimal.fromShort(Short.MIN_VALUE)
val result = x.divideAndRemainder(BigDecimal.ONE)

x is displayed in debugger with correct value -3.2768E+4. Result.first should be the same, and result.second should be zero. Instead, this is displayed in debugger: result.first = -3.2769E+4 result.second = 1.0

So far this is the only case I've hit in early unit testing, so am unsure what other ways the underlying bug may manifest. It's possible this happens whenever signs of numerator and divisor differ.

Environment: kotlin 1.4.0-rc com.ionspin.kotlin:bignum:0.1.6-1.4.0-rc-SNAPSHOT running junit5 unit test using Kotest 4.2.0 invoking multiplatform common functions using BigDecimal

Describe the bug There is an exception thrown when processing negative numbers

To Reproduce

println((-6.0).toBigDecimal().toStringExpanded().toDouble()) 

Expected behavior

The library will process the number same as positive numbers

Version : 0.1.5-SNAPSHOT

Image above is the reference

See the description of issue #130, the same exact bugs are in floatValue and fromFloat. Sorry I should have caught this during the issue 130 work, Anyway while unit testing the fix to the two float functions I hit a different bug/feature and am unsure which it is - bug or feature. Given this code snippet:

        f = BigDecimal.fromFloat(Float.MIN_VALUE)
        assertEquals(Float.MIN_VALUE, f.floatValue(true))
        val f2 = f.divide(BigDecimal.TEN)

The value of Float.MIN_VALUE is 1.4E-45. As expected f2 is 1.4E-46. But here is the state inside f2:

f2 = {BigDecimal@2111} "1.4E-46"
 precision = 11
 precisionLimit = 0
 roundingMode = {RoundingMode@1966} "NONE"
 significand = {BigInteger@1937} "14000000000"
 exponent = -46
 scale = -1
 usingScale = false
 decimalMode = {DecimalMode@1903} "DecimalMode(decimalPrecision=0, roundingMode=NONE, scale=-1)"

is the precision number and the significand correct in this case? Or should all those trailing zeroes have been trimmed and the precision set to 2? If this is correct behavior lemme know, because there is current code in the narrowing stuff that expected this result to have precision = 2 and significand = 14. Because it doesn't, the precision limit check in floatValue() is incorrect. And it likely there are cases where the doubleValue() precision limit check is incorrect for the same reason. Both use the precision value in the same way as a limit check.

Let me know what the correct behavior of precision and significand is in the above case, and I'll proceed from there to get fixes and unit tests developed for the above.

Describe the bug BigDecimalWhole.isWholeNumber() wrong when DecimalMode set

To Reproduce

    @Test
    fun testIsWhole() {
        val bigDecimalWhole = "1.1234567826".toBigDecimal(
            decimalMode = DecimalMode(18, RoundingMode.ROUND_HALF_CEILING, 18)
        ).moveDecimalPoint(9)

        assertEquals("1123456782.6", bigDecimalWhole.toPlainString())
        assertEquals(false, bigDecimalWhole.isWholeNumber())
    }

Platform JVM and JS

Additional context Works correct when no DecimalMode is set, but I have to set it to work around #237

Is your feature request related to a problem? Please describe. I am unable to obtain a com.ionspin.kotlin.bignum.integer.BigInteger from a java.math.BigInteger.

Describe the solution you'd like An extension method on java.math.BigInteger to perform the conversion.

Describe alternatives you've considered Implementing it myself on each project.

Is your feature request related to a problem? Please describe. Kotlin collections provides helper method like sumOf { }, but some methods are defined with the explicit types (there is a Iterable<T>.sumOf(selector: (T) -> Long): Long and a Iterable<T>.sumOf(selector: (T) -> Int): Int for example).

data class Foo(val data: Double)
val fooList = listOf(Foo(0.1), Foo(0.2))
val sum = fooList.sumOf { it.data }

It could be nice to provide those methods for BigInteger and BigDecimal.

Describe the solution you'd like

data class Bar(val data: BigDecimal)
val barList = listOf(Bar(BigDecimal.fromDouble(0.1)), Bar(BigDecimal.fromDouble(0.2)))
val sum = barList.sumOf { it.data }

Describe alternatives you've considered

It's still possible to use fold to compute a sum (just a bit less convenient).

val sum2 = barList.fold(BigDecimal.ZERO) { acc, it -> acc + it.data }

Is your feature request related to a problem? Please describe.

The calculator app I've written (not currently using this library, but I'm certainly considering it) currently works in bases 10 and 12, and I'm considering adding support for base 16.

BigDecimal is (as the name says) only for base 10, not allowing me to pass in a radix.

Describe the solution you'd like

A BigNumber class or similar where the radix can be specified would be ideal. BigDecimal could possibly remain as a specialisation of a big number for base 10, but any radix-independent methods could be moved to the superclass.

Describe alternatives you've considered

a. do all the maths in decimal and convert each way. I'd get rounding errors here and there, but it can't be any worse than using double precision. b. make my own BigRational or BigNumber utilities, possibly building on top of BigInteger.

Added:

• exp (by infinite series)
• cos (by infinite series)
• sin (by infinite series)
• tan (by cos/sin)
• cosh (by infinite series)
• sinh (by infinite series)
• tanh (by cosh/sinh)

Not added:

• ln - might not be too hard but converges very slowly so need another trick
• arcsin(x) = arctan(x / √(1 - x²))
• arccos(x) = arctan(√(1 - x²) / x)
• arctan - conceivably possible to do similarly, but the series only converges for small values, so need to use Euler's trick
• arsinh(x) = ln(√(1 + x²) + x)
• arcosh(x) = ln(x + √(x - 1)√(x + 1)) = ln(√(x² - 1) + x)
• artanh(x) = ½ ln(x + 1) - ½ ln(1 - x)

Currently this library is lacking advanced math features, such as: sin, cos, sqrt, nroot, log, etc.

Are these within the scope of this library?

If not, what workaround would you suggest?