https://kotlinlang.org logo
Channels
100daysofcode
100daysofkotlin
100daysofkotlin-2021
advent-of-code
aem
ai
alexa
algeria
algolialibraries
amsterdam
android
android-architecture
android-databinding
android-studio
androidgithubprojects
androidthings
androidx
androidx-xprocessing
anime
anko
announcements
apollo-kotlin
appintro
arabic
argentina
arkenv
arksemdevteam
armenia
arrow
arrow-contributors
arrow-meta
ass
atlanta
atm17
atrium
austin
australia
austria
awesome-kotlin
ballast
bangladesh
barcelona
bayarea
bazel
beepiz-libraries
belgium
benchmarks
berlin
big-data
books
boston
brazil
brikk
budapest
build
build-tools
bulgaria
bydgoszcz
cambodia
canada
carrat
carrat-dev
carrat-feed
chicago
chile
china
chucker
cincinnati-user-group
cli
clikt
cloudfoundry
cn
cobalt
code-coverage
codeforces
codemash-precompiler
codereview
codingame
codingconventions
coimbatore
collaborations
colombia
colorado
communities
competitive-programming
competitivecoding
compiler
compose
compose-android
compose-desktop
compose-hiring
compose-ios
compose-mp
compose-ui-showcase
compose-wear
compose-web
confetti
connect-audit-events
corda
cork
coroutines
couchbase
coursera
croatia
cryptography
cscenter-course-2016
cucumber-bdd
cyprus
czech
dagger
data2viz
databinding
datascience
dckotlin
debugging
decompose
decouple
denmark
deprecated
detekt
detekt-hint
dev-core
dfw
docs-revamped
dokka
domain-driven-design
doodle
dsl
dublin
dutch
eap
eclipse
ecuador
edinburgh
education
effective-kotlin
effectivekotlin
emacs
embedded-kotlin
estatik
event21-community-content
events
exposed
failgood
fb-internal-demo
feed
firebase
flow
fluid-libraries
forkhandles
forum
fosdem
fp-in-kotlin
framework-elide
freenode
french
fritz2
fuchsia
functional
funktionale
gamedev
ge-kotlin
general-advice
georgia
geospatial
german-lang
getting-started
github-workflows-kt
glance
godot-kotlin
google-io
gradle
graphic
graphkool
graphql
graphql-kotlin
graviton-browser
greece
grpc
gsoc
gui
hackathons
hacktoberfest
hamburg
hamkrest
helios
helsinki
hexagon
hibernate
hikari-cp
hire-me
hiring
hongkong
hoplite
http4k
hungary
hyderabad
image-processing
india
indonesia
inkremental
intellij
intellij-plugins
intellij-tricks
internships
introduce-yourself
io
ios
iran
israel
istanbulcoders
italian
jackson-kotlin
jadx
japanese
jasync-sql
java-to-kotlin-refactoring
javadevelopers
javafx
javalin
javascript
jdbi
jhipster-kotlin
jobsworldwide
jpa
jshdq
juul-libraries
jvm-ir-backend-feedback
jxadapter
k2-early-adopters
kaal
kafka
kakao
kalasim
kapt
karachi
karg
karlsruhe
kash_shell
kaskade
kbuild
kdbc
kgen-doc-tools
kgraphql
kinta
klaxon
klock
kloudformation
kmdc
kmm-español
kmongo
knbt
knote
koalaql
koans
kobalt
kobweb
kodein
kodex
kohesive
koin
koin-dev
komapper
kondor-json
kong
kontent
kontributors
korau
korean
korge
korim
korio
korlibs
korte
kotest
kotest-contributors
kotless
kotlick
kotlin-asia
kotlin-beam
kotlin-by-example
kotlin-csv
kotlin-data-storage
kotlin-foundation
kotlin-fuel
kotlin-in-action
kotlin-inject
kotlin-latam
kotlin-logging
kotlin-multiplatform-contest
kotlin-mumbai
kotlin-native
kotlin-pakistan
kotlin-plugin
kotlin-pune
kotlin-roadmap
kotlin-samples
kotlin-sap
kotlin-serbia
kotlin-spark
kotlin-szeged
kotlin-website
kotlinacademy
kotlinbot
kotlinconf
kotlindl
kotlinforbeginners
kotlingforbeginners
kotlinlondon
kotlinmad
kotlinprogrammers
kotlinsu
kotlintest
kotlintest-devs
kotlintlv
kotlinultimatechallenge
kotlinx-datetime
kotlinx-files
kotlinx-html
kotrix
kotson
kovenant
kprompt
kraph
krawler
kroto-plus
ksp
ktcc
ktfmt
ktlint
ktor
ktp
kubed
kug-leads
kug-torino
kvision
kweb
lambdaworld_cadiz
lanark
language-evolution
language-proposals
latvia
leakcanary
leedskotlinusergroup
lets-have-fun
libgdx
libkgd
library-development
lincheck
linkeddata
lithuania
london
losangeles
lottie
love
lychee
macedonia
machinelearningbawas
madrid
malaysia
mathematics
meetkotlin
memes
meta
metro-detroit
mexico
miami
micronaut
minnesota
minutest
mirror
mockk
moko
moldova
monsterpuzzle
montreal
moonbean
morocco
motionlayout
mpapt
mu
multiplatform
mumbai
munich
mvikotlin
mvrx
myndocs-oauth2-server
naming
navigation-architecture-component
nepal
new-mexico
new-zealand
newname
nigeria
nodejs
norway
npm-publish
nyc
oceania
ohio-kotlin-users
oldenburg
oolong
opensource
orbit-mvi
osgi
otpisani
package-search
pakistan
panamá
pattern-matching
pbandk
pdx
peru
philippines
phoenix
pinoy
pocketgitclient
polish
popkorn
portugal
practical-functional-programming
proguard
prozis-android-backup
pyhsikal
python
python-contributors
quasar
random
re
react
reaktive
realm
realworldkotlin
reductor
reduks
redux
redux-kotlin
refactoring-to-kotlin
reflect
refreshversions
reports
result
rethink
revolver
rhein-main
rocksdb
romania
room
rpi-pico
rsocket
russian
russian_feed
russian-kotlinasfirst
rx
rxjava
san-diego
science
scotland
scrcast
scrimage
script
scripting
seattle
serialization
server
sg-user-group
singapore
skia-wasm-interop-temp
skrape-it
slovak
snake
sofl-user-group
southafrica
spacemacs
spain
spanish
speaking
spek
spin
splitties
spotify-mobius
spring
spring-security
squarelibraries
stackoverflow
stacks
stayhungrystayfoolish
stdlib
stlouis
strife-discord-lib
strikt
students
stuttgart
sudan
swagger-gradle-codegen
swarm
sweden
swing
swiss-user-group
switzerland
talking-kotlin
tallinn
tampa
teamcity
tegal
tempe
tensorflow
terminal
test
testing
testtestest
texas
tgbotapi
thailand
tornadofx
touchlab-tools
training
tricity-kotlin-user-group
trójmiasto
truth
tunisia
turkey
turkiye
twitter-feed
uae
udacityindia
uk
ukrainian
uniflow
unkonf
uruguay
utah
uuid
vancouver
vankotlin
vertx
videos
vienna
vietnam
vim
vkug
vuejs
web-mpp
webassembly
webrtc
wimix_sentry
wwdc
zircon
Powered by
Title
g

groostav

03/27/2023, 7:25 PM
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?
e

ephemient

03/27/2023, 7:29 PM
you've already lost precision by writing the literal
0.1
in code
g

groostav

03/27/2023, 7:29 PM
but
Double.toString()
knew how to get it back?
what else does it know how ot get back?
e

ephemient

03/27/2023, 7:30 PM
.toString()
finds the shortest string representation that produces the same value, not the exact representation
0.1000000000000000055511151231257827021181583404541015625 == 0.1
g

groostav

03/27/2023, 7:30 PM
right
0x3FB999999999999A
thanks i hate it
XD
e

ephemient

03/27/2023, 7:31 PM
toString()
produces the latter,
BigDecimal
captures all of the former
g

groostav

03/27/2023, 7:37 PM
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.
e

ephemient

03/27/2023, 7:38 PM
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
g

groostav

03/27/2023, 7:39 PM
well if i was in closure it would be, but i take your point
i really really wish i could get a
ratio
primative in kotlin, i wonder if thats already an issue
e

ephemient

03/27/2023, 7:41 PM
you'd have to write 1/10 to get a ratio in clojure, 0.1 is still a IEEE floating point
or suffix M I think?
g

groostav

03/27/2023, 7:42 PM
i thought you could write like
0.1r
, but im digressing
yeah
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?
e

ephemient

03/27/2023, 7:44 PM
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
g

groostav

03/27/2023, 7:48 PM
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
are there other bitpatterns that correspond to the same value
0.1
?
e

ephemient

03/27/2023, 7:49 PM
your wording still indicates some real confusion to me
g

groostav

03/27/2023, 7:50 PM
so i understand that
0.1 == 0.100000000000000005  && 0.1 == 0.0.100000000000000005999
is true
e

ephemient

03/27/2023, 7:50 PM
"0.099999999999999999".toDouble() == "0.1".toDouble()
g

groostav

03/27/2023, 7:50 PM
right
e

ephemient

03/27/2023, 7:51 PM
are you asking if there are any other values of
Double
which will
.toString()
to
"0.1"
?
g

groostav

03/27/2023, 7:51 PM
yes i suppose i am
a value of double other than `0x3FB999999999999A``
e

ephemient

03/27/2023, 7:51 PM
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-
there have been bugs, but generally in the other direction: https://bugs.openjdk.org/browse/JDK-4511638
g

groostav

03/27/2023, 7:58 PM
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?
my understanding is that there is an exact sparse mapping, every member of the <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
e

ephemient

03/27/2023, 8:01 PM
under what I believe is the common definition of sig fig: no
1.1E-323 == 1.2E-323
g

groostav

03/27/2023, 8:02 PM
I didnt think double representations could be that small
e

ephemient

03/27/2023, 8:04 PM
1.8E308 == 1.9E308
g

groostav

03/27/2023, 8:04 PM
i think 1.9E308 is also bigger than Double.MaxValue but
i take your point
with E307
well wait
e

ephemient

03/27/2023, 8:07 PM
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"
g

groostav

03/27/2023, 8:07 PM
yeah i saw
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()
given that I cant simply replace the stored type with BigDecimal
i dont understand why so much of the mentissa would be ignored when the exponent is really large
but im willing to write this off as "FP being wierd"
e

ephemient

03/27/2023, 8:12 PM
0.0 == -0.0
(0.0).toString() != (-0.0).toString()
g

groostav

03/27/2023, 8:12 PM
yeah and of course negative zero
good ol' sign bit problems
but im not actually sure thats against my question
-0.0
is denotable differently than
0.0
, so the fact that it gives you different representation doesnt violate the rule
as long as
-0.0.toString() == "-0.0"
its fine
thanks for your help
e

ephemient

03/27/2023, 8:16 PM
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
and it would prevent you from entering 10000000.0 without scientific notation
g

groostav

03/27/2023, 8:21 PM
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
i suppose what might be nicer is a
DoubleConverter
or
DecimalFormat
thats a bit more strict about this
so ill look into that
e

ephemient

03/27/2023, 8:25 PM
DecimalFormat still gets 1e23 wrong since it's built on the same operation
if you just want to keep 14 sigfigs, `.toBigDecimal().round(MathContext(14))`will do that