2025/12/13

Newest at the top

2025-12-13 11:07:15 +0100merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds)
2025-12-13 11:03:28 +0100skum(~skum@user/skum) skum
2025-12-13 11:02:38 +0100merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-12-13 10:53:36 +0100CiaoSen(~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) CiaoSen
2025-12-13 10:53:21 +0100 <tomsmeding> it makes sense
2025-12-13 10:53:20 +0100 <tomsmeding> but if you don't cut off the zeros, it's still 2 digits longer: and indeed, -54 and -56 are 2 apart
2025-12-13 10:53:01 +0100 <tomsmeding> you can't cut off zeros at the end, that reduces the precision
2025-12-13 10:52:54 +0100 <tomsmeding> also no that's the wrong comparison
2025-12-13 10:52:40 +0100 <EvanR> lol
2025-12-13 10:52:37 +0100 <tomsmeding> that's boring
2025-12-13 10:52:34 +0100 <lambdabot> 52
2025-12-13 10:52:33 +0100 <EvanR> > length "3000000000000000444089209850062616169452667236328125"
2025-12-13 10:52:20 +0100 <lambdabot> 55
2025-12-13 10:52:19 +0100 <EvanR> > length "3000000000000000166533453693773481063544750213623046875"
2025-12-13 10:52:04 +0100 <tomsmeding> it actually makes sense after all
2025-12-13 10:52:03 +0100 <EvanR> I just did
2025-12-13 10:51:49 +0100 <tomsmeding> hence our result here is closer to the actual 0.3 than the FPU's result is
2025-12-13 10:51:35 +0100merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds)
2025-12-13 10:51:28 +0100 <tomsmeding> -56 because the 0.1 had that, and I multiplied up the 0.2 to -56-precision with the *10
2025-12-13 10:51:08 +0100 <tomsmeding> we have a number with -56 but still being close to 0.3
2025-12-13 10:50:40 +0100 <tomsmeding> note the 0.3 being -54
2025-12-13 10:50:35 +0100 <lambdabot> [(7205759403792794,-56),(7205759403792794,-55),(5404319552844595,-54)]
2025-12-13 10:50:34 +0100 <tomsmeding> > map decodeFloat [0.1, 0.2, 0.3]
2025-12-13 10:50:26 +0100 <tomsmeding> yeah
2025-12-13 10:50:20 +0100 <EvanR> the result does
2025-12-13 10:49:49 +0100 <tomsmeding> I think?
2025-12-13 10:49:37 +0100 <tomsmeding> oh, EvanR our manual sum here has too much precision
2025-12-13 10:49:35 +0100poscat(~poscat@user/poscat) (Ping timeout: 256 seconds)
2025-12-13 10:49:12 +0100 <EvanR> obv
2025-12-13 10:49:06 +0100 <probie> EvanR: In the Pale Moonlight (DS9) reference?
2025-12-13 10:48:24 +0100 <EvanR> it's a faaaaaake
2025-12-13 10:48:17 +0100 <EvanR> 300000000000000044408920985006261616945266723632812500
2025-12-13 10:48:13 +0100 <tomsmeding> which, interestingly, is not the same number as decodeFloat (0.1 + 0.2) gave
2025-12-13 10:47:58 +0100poscat0x04(~poscat@user/poscat) poscat
2025-12-13 10:47:46 +0100 <lambdabot> 30000000000000001665334536937734810635447502136230468750
2025-12-13 10:47:45 +0100 <tomsmeding> > 10000000000000000555111512312578270211815834045410156250 + 2000000000000000111022302462515654042363166809082031250 * 10
2025-12-13 10:47:40 +0100 <EvanR> oof
2025-12-13 10:47:20 +0100 <lambdabot> 12000000000000000666133814775093924254179000854492187500
2025-12-13 10:47:19 +0100 <EvanR> > 10000000000000000555111512312578270211815834045410156250 + 2000000000000000111022302462515654042363166809082031250
2025-12-13 10:46:55 +0100 <lambdabot> 2000000000000000111022302462515654042363166809082031250
2025-12-13 10:46:54 +0100 <EvanR> > let (m,e) = decodeFloat 0.2 in m * 5 ^ negate e
2025-12-13 10:46:50 +0100merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-12-13 10:46:30 +0100 <tomsmeding> (I didn't actually try it)
2025-12-13 10:46:06 +0100Tuplanolla(~Tuplanoll@91-152-225-194.elisa-laajakaista.fi) Tuplanolla
2025-12-13 10:46:03 +0100 <EvanR> lol
2025-12-13 10:45:52 +0100 <tomsmeding> I'm getting "invalid number"
2025-12-13 10:45:22 +0100 <EvanR> don't think, dial 555 111 5123 now
2025-12-13 10:44:45 +0100tromp(~textual@2001:1c00:3487:1b00:6cd5:9506:337d:4c75) (Quit: My iMac has gone to sleep. ZZZzzz…)
2025-12-13 10:43:40 +0100 <lambdabot> 10000000000000000555111512312578270211815834045410156250
2025-12-13 10:43:39 +0100 <tomsmeding> > let (m,e) = decodeFloat 0.1 in m * 5^(-e)