0.3.4 narrowing function change is a breaking change for me

[skolson]

FYI haven't dug into the patterns yet, but this narrowing stuff defaulting to exactRequired is a breaking change. I'm currently trying to determine how bad it is :-). Stuff that used to work is now barfing, will see if I can see what kinds of values are failing now. I may have to fin every use of a narrowing function on floats and doubles and set them all false.

[skolson]

Hmm, maybe this is an actual issue, not sure. I have a BigDecimal = "999111.999111" and calling doubleValue(false) on that value in the debugger shows the resulting Double = 999111.999111. Why does this throw an ArithmeticException if doubleValue() is called on the same instance? I haven't debugged in, but is this expected?

[skolson]

FYI the debug content of the above BigDecimal is 9.99111999111E+5 and a null DecimalMode

[ionspin]

Hey Steven, I'm not near my computer and won't be this weekend, but yeah, it is a breaking change, and is marked as such in the changelog. I think it's important because people are unaware of precision loss when converting. Your example is a great one because it cant be represented correctly in kotlin float/double, you can try it on this site I found a moment ago, but it represents the problem nicely https://www.h-schmidt.net/FloatConverter/IEEE754.html

[ionspin]

Oh and the reason you are seeing the correct value in the debugger is because toString on double applies rounding and that is what the debugger is calling to show the current value. Here is an example

        val doubleString1 = "999111.999111"
        val doubleString2 = "999111.9991109999828040599823"
        println(doubleString1.toDouble())
        println(doubleString2.toDouble())

Prints:

999111.999111
999111.999111

[ionspin]

Here is an explanation of that, which honestly I haven't read in detail :)
https://stackoverflow.com/questions/56905293/how-does-double-tostring-work-if-a-fraction-number-cannot-be-precisely-represe/56905831#56905831