Clojurians Log v2

Jeg må slutte å stole på javascript, selv til de enkleste ting 😆

😂

Float's gonna float

Testet i clojure nå og det skjer jo faktisk der også 🤯

Trodde ikke det var en klassisk "flyttallsfeil" siden det var så lite tall. Men jeg skjønner tydeligvis ikke hvordan flyttall fungerer

Floats er aldri nøyaktige, så det er bare et spørsmål om hvor langt illusjonen strekker.

JavaScript har ikke engang heltall - alt er flyttall. Men den beholder illusjonen så lenge du gjør heltallsberegninger 😅

Ja, det visste jeg jo. Men jeg trodde illusjonen strakk seg litt lenger enn det laughcry

Ikke lett å holde styr på når det går gæernt, så i viktige beregniner er det lurt å være veldig eksplisitt på hvilken presisjon du trenger

Evt ikke gjøre viktige beregninger i nettleseren til folk 😁

Det går vel på at maskiner gjør kalkuleringer i base 2 (binær), mens vi mennesker bruker base 10. Det er i denne translasjonen mellom baser at det kan forekomme rariteter

Det er noe sånt, tror jeg 🤔

Ja, det stemmer det 👍

Som litt reklame for https://github.com/anteoas/broch, så gjør den alle beregninger i ratio-land og konverterer bare tilbake til double om det ikke taper presisjon. Det gjør at det er 100% presist by default, i bytte mot noe ytelse da selvfølgelig. Men til beregninger med "domenetall", som mengder, så er presisjon viktigst synes jeg.

vi serialiserer BigDecimal til string i vårt API, for å si det sånn

(vscode/commands.executeCommand "simpleBrowser.show" (str "https://" (+ 0.1 0.2) ".com"))

i et annet API vi jobber med så må man representere tall i JSON som tall. Heldigvis støtter serialiseringsbiblioteket vårt å skrive BigDecimal som tall i JSON, og å parse dem ut igjen riktig, uten å gå via float eller double. Og de gjør det visst riktig på andre enden. Men det der bryter jo sammen så fort du kommer til JSON.parse i en browser

Big.js ftw

JVM Clojure:

(+ 0.1 0.2) => 0.30000000000000004
(+ 0.1M 0.2) => 0.30000000000000004
(+ 0.1 0.2M)  => 0.30000000000000004
(+ 0.1M 0.2M) => 0.3M

(double (+ 1/10 2/10)) => 0.3

Orättvist mot JavaScript ju. 😃

Vi bruker denne i frontend (kun til presentasjon for avledede verdier): https://github.com/MikeMcl/big.js/

Og som @christian767 sier: flyttall er flyttall! Spiller ingen rolle om det er .net, jvm, javascript eller c++

Holder på å dra inn big.js akkurat nå 😄

this is the way

Jeg har selvfølgelig lært alt dette før. Men når noe føles som det er problem bare "i teorien" er det lett at det går i glemmeboken. Når det biter deg i ræven husker man det bedre. Brent barn, og så videre...

friends don't let friends use floating point numbers for business logic

Fixed point ints er også en løsning jeg ofte griper til, spesielt om det er litt ytelse med i bildet.

Jeg tror dette er (grunnlaget for) løsningen på problemet: https://github.com/cjohansen/nexus/commit/c1b66ae911d9c484fa2f918e95f7000a9f00be6d Jeg skal følge opp med noen justeringer på action loggen som bruker dette. Skal også ta noen grep for å gjøre feil langt mer synlige i loggen.

Interessant! 😄 Helt fair dette, du har gjort et ærlig stykke arbeid med å dokumentere en bug og foreslå en løsning. Jeg kommer ikke til å merge inn kode jeg selv ikke forstår, uavhengig av hvem som har skrevet den. Fint at du er upfront om prosess, men jeg tror ærlig talt ikke dette er så veldig forskjellig fra andre PRs. Jeg kommer sikkert til å være mer kritisk til koden enn vanlig med denne kunnskapen i bakhodet, men usikkert om det er rasjonelt 😄

Det kommer veldig an på hvordan det presenteres tenker jeg. Her har du i det minste gjort en ærlig jobb med å forklare prosessen, og er åpen for at det å åpne PRer der du selv ikke forstår koden er noe noen prosjekter ikke vil godta. Mye av spørsmålet er jo hvor mye "gratisarbeid" du skal legge på OSS-folk. Se f.eks. https://github.com/ocaml/ocaml/pull/14369 på hvordan det ikke skal gjøres. Om det blir en haug med mye mer review fordi folk ikke er villig til å sette seg inn i koden og bare gulper opp AI-slop er det ikke rart folk ikke lenger ønsker å vedlikeholde prosjektene sine.

Suksessfaktoren i PR-en til @msolli er at han evner å formidle til meg hva problemet er. Så kan man jo diskutere om det er en PR eller et issue, kanskje ikke så veldig viktig.

Men jeg syns poenget ditt om gratisarbeid er godt @hypirion! Dårlig forklarte/begrunnede issues og PR skaper ganske mye jobb for motparten. Vet ikke om dere så videoen som Peter Taoussanis nylig lagde på temaet, men han hadde mange gode poenger i denne retningen.

Det kunne vært et issue med en feilende test, som du sier, @christian767. Det meste av arbeidet var å komme dit. Burde kanskje stoppet der, men det var fristende å se hva løsningen kunne være! (Jeg hadde håpet at løsningen var enklere å forstå.)

Dessuten løser koden i PR-en et faktisk problem som vi har på jobb. Digg, da, at vi kan kjøre på den vha. git-koordinater i deps.edn.

Den OCaml-PR-en var grotesk, @hypirion. Utover LLM-problematikken som er sentral der, så er det et klassisk problem at noen bruker masse tid på å koke opp en løsning på et problem uten noen designprosess først.

Forøvrig reiser jeg bort for helga i morgen tidlig, så mulig denne blir hengende over helga @msolli!

For all del! Som sagt, vi har en løsning som funker for oss.

Den ble ikke bare hengende over helga 😅 🙈 Men nå har jeg endelig hatt overskudd til å se på dette @msolli. Har etterlyst litt mer innsikt i use caset ditt på PR-en 😊

Takk for at kikker på det! Jeg er i fjellheimen noen dager nå, men skal svare deg så snart jeg får anledning.

Det morsomme er at jeg var veldig prima for den feilen da jeg kom til den i går. Etter å ha jobba litt med justeringen på når effekter blir kjørt og state oppdatert så hadde jeg sittet og grunnet litt på hvordan man egentlig skulle kunne trekke linjer fra toppnivå dispatch til async dispatch og eventuelle feil. Jobber med å få på plass litt mer lim for å gi bedre kontroll på det.