alright friends I cant think of a better place to put this s

Question

alright friends I cant think of a better place to put this so im plopping it in here I need to understand IEEE 754 and error with respect to writing values For my problem there are no math operations to induce error only attempts to represent a double value the code ```val firstDbl Double = 0 1 val firstStr String = 0 1 val firstBigStr = BigDecimal 0 1 val firstBigDbl = BigDecimal 0 1 ``` has some funny equality implications ```firstDbl == firstStr toDouble true firstBigStr == firstBigDbl false firstBigStr toDouble == firstBigDbl toDouble false 0 1 = 0 0 555 firstBigDb toString 0 1000000000000000055511151231257827021181583404541015625``` Can somebody help me understand where this error came from Should i be calling a different BigDecimal constructor

ephemient · Answer

you ve already lost precision by writing the literal `0 1` in code

groostav · Answer

but `Double toString ` knew how to get it back

groostav · Answer

what else does it know how ot get back

ephemient · Answer

` toString ` finds the shortest string representation that produces the same value not the exact representation

ephemient · Answer

`0 1000000000000000055511151231257827021181583404541015625 == 0 1`

groostav · Answer

right

groostav · Answer

`0x3FB999999999999A`

groostav · Answer

thanks i hate it

groostav · Answer

XD

ephemient · Answer

`toString ` produces the latter `BigDecimal` captures all of the former

ephemient · Answer

tl dr <https wiki sei cmu edu confluence display java NUM10 J +Do+not+construct+BigDecimal+objects+from+floating point+literals>

groostav · Answer

so I have some legacy model code that is using `double` fields to store some input from a user Its pretty straight forward I was aware that the first time you do an operation on that value you ve incurred a loss but I had thought that any value that was denotable within the precision limits of IEEE 754 was how should I say recoverable as its denotation within those bounds IE if i wrote `0 1` in a text field or indeed in intelliJ as a constant the I would get the bits `0x3FB999999999999A` and like an ASCII coding of `A` to `0x41` i could convert back and forth between them as I saw fit

ephemient · Answer

the floating point value that you get when you write `0 1` is not actually `0 1` as you think of it as that cannot be exactly represented

groostav · Answer

well if i was in closure it would be but i take your point

groostav · Answer

i really really wish i could get a `ratio` primative in kotlin i wonder if thats already an issue

ephemient · Answer

you d have to write 1 10 to get a ratio in clojure 0 1 is still a IEEE floating point

ephemient · Answer

or suffix M I think

groostav · Answer

i thought you could write like `0 1r` but im digressing

groostav · Answer

yeah

groostav · Answer

given that I write `val myDouble = doubleParsedFromDenotableUserText text ` how safe is it to write `val bigDecimal = BigDecimal myDouble toString ` I guess my question is how much of a perfect dual operation is `text toDouble ` and `double toString ` when will the two not produce a result that agrees

ephemient · Answer

`double toString toDouble ` is supposed to round trip for finite values on JVM not JS but `string toDouble toString ` is not as there are many possible string representations for the same floating point value

groostav · Answer

I mean i understand the concept that with the nature of finite storage and truncation we re trying to encode a range on the real number line to a single bit pattern

groostav · Answer

are there other bitpatterns that correspond to the same value `0 1`

ephemient · Answer

your wording still indicates some real confusion to me

groostav · Answer

so i understand that `0 1 == 0 100000000000000005 amp amp 0 1 == 0 0 100000000000000005999` is true

ephemient · Answer

` 0 099999999999999999 toDouble == 0 1 toDouble `

groostav · Answer

right

ephemient · Answer

are you asking if there are any other values of `Double` which will ` toString ` to ` 0 1 `

groostav · Answer

yes i suppose i am

groostav · Answer

a value of double other than `0x3FB999999999999A``

ephemient · Answer

on JVM no there are not if the JVM is not buggy this is specified by <https docs oracle com javase 8 docs api java lang Double html toString double >

ephemient · Answer

there have been bugs but generally in the other direction <https bugs openjdk org browse JDK 4511638>

groostav · Answer

ok so lets say the Denotable numbers is the set of decimal numbers that can be written down This is a strict subset of rational numbers 1 3 is a ratio but is not part of my set can all members of the set of denotable numbers with less than 14 sig figs be converted from its denotation to a `double` and back again losslessly

groostav · Answer

my understanding is that there is an exact sparse mapping every member of the lt 14 sig fig Denotables would map to exactly one representation under IEEE754 double and that given such a `double` value IE a double value we knew was parsed from a Denotable we could get that denotable representation back

ephemient · Answer

under what I believe is the common definition of sig fig no

ephemient · Answer

1 1E 323 == 1 2E 323

groostav · Answer

I didnt think double representations could be that small

ephemient · Answer

1 8E308 == 1 9E308

groostav · Answer

i think 1 9E308 is also bigger than Double MaxValue but

groostav · Answer

i take your point

groostav · Answer

with E307

groostav · Answer

well wait

ephemient · Answer

the example in the bug I linked before applies to Java 17 although it s in violation of `Double toString` docs `1 0E23 toString == 9 999999999999999E22 `

groostav · Answer

yeah i saw

groostav · Answer

the tl dr is that I wish I had used a `BigDecimal` on my model istead of a `double` but im trying to understand the scope of the failures I can see with the use of `double` It seems like perhalps a reasonable intermediate fix is to do a `double toString toDouble` as a kind of validation on user input and then do something if `input = input toDouble toString `

groostav · Answer

given that I cant simply replace the stored type with BigDecimal

groostav · Answer

i dont understand why so much of the mentissa would be ignored when the exponent is really large

groostav · Answer

but im willing to write this off as FP being wierd

ephemient · Answer

```0 0 == 0 0 0 0 toString = 0 0 toString ```

groostav · Answer

yeah and of course negative zero

groostav · Answer

good ol sign bit problems

groostav · Answer

but im not actually sure thats against my question

groostav · Answer

` 0 0` is denotable differently than `0 0` so the fact that it gives you different representation doesnt violate the rule

groostav · Answer

as long as ` 0 0 toString == 0 0 ` its fine

groostav · Answer

thanks for your help

ephemient · Answer

`require input == input toDouble toString ` may force you to enter certain values differently on different JVMs aside from the bug above the representation is supposed to be minimal but not necessarily unique

ephemient · Answer

and it would prevent you from entering 10000000 0 without scientific notation

groostav · Answer

i probably wouldnt do it as a requirement i would just make it a filter and replace the user entered value with the one that i get from `toDouble toString ` where appropriate

groostav · Answer

i suppose what might be nicer is a `DoubleConverter` or `DecimalFormat` thats a bit more strict about this

groostav · Answer

so ill look into that

ephemient · Answer

DecimalFormat still gets 1e23 wrong since it s built on the same operation

ephemient · Answer

if you just want to keep 14 sigfigs ` toBigDecimal round MathContext 14 `will do that