Newest at the top
| 2025-12-12 22:26:27 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-12 22:19:45 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-12-12 22:16:46 +0100 | Lycurgus | (~juan@user/Lycurgus) (Quit: alsoknownas.renjuan.org ( juan@acm.org )) |
| 2025-12-12 22:14:34 +0100 | trickard_ | (~trickard@cpe-83-98-47-163.wireline.com.au) |
| 2025-12-12 22:14:21 +0100 | trickard | (~trickard@cpe-83-98-47-163.wireline.com.au) (Read error: Connection reset by peer) |
| 2025-12-12 22:13:57 +0100 | <EvanR> | but not 1.23 plus 100 zeros |
| 2025-12-12 22:13:28 +0100 | <EvanR> | yes, 1.23 |
| 2025-12-12 22:13:09 +0100 | <monochrom> | I think it's because at the limited precision of 18 digits, the thing is indistinguishable from 1.23 |
| 2025-12-12 22:12:55 +0100 | <EvanR> | which I was trying to demonstrate for reasons |
| 2025-12-12 22:12:50 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-12 22:12:36 +0100 | <EvanR> | leading me to the conclusion that: truncating "the string" of a positive float is not the same as rounding down |
| 2025-12-12 22:12:17 +0100 | <lambdabot> | (19,1.23) |
| 2025-12-12 22:12:16 +0100 | <monochrom> | > let s = "1.22999999999999999" in (length s, read s :: Double) |
| 2025-12-12 22:12:12 +0100 | <monochrom> | let s = "1.22999999999999999" in (length s, read s :: Double) |
| 2025-12-12 22:11:16 +0100 | <EvanR> | not really, I'm sure, but that's the effect |
| 2025-12-12 22:11:07 +0100 | <EvanR> | in this case |
| 2025-12-12 22:11:05 +0100 | <EvanR> | basically it's taking the liberty of rounding up |
| 2025-12-12 22:09:43 +0100 | <lambdabot> | 18 |
| 2025-12-12 22:09:42 +0100 | <monochrom> | > length "1.2299999999999999" |
| 2025-12-12 22:06:15 +0100 | <monochrom> | Oh! Now I see what you mean. |
| 2025-12-12 22:05:53 +0100 | <EvanR> | (1.229999999999999982236431605997495353221893310546875) |
| 2025-12-12 22:05:28 +0100 | <EvanR> | but in the case of 1.23 it's not the correct digits |
| 2025-12-12 22:05:16 +0100 | <EvanR> | I know |
| 2025-12-12 22:05:04 +0100 | <monochrom> | Even if you're just printing 0. |
| 2025-12-12 22:05:01 +0100 | <EvanR> | maybe if you ask for over 17 significant digits it just slaps 0 on the rest |
| 2025-12-12 22:04:49 +0100 | <monochrom> | So I think the author just decided that if you have "Just n" then it unconditionally ensures n digits. |
| 2025-12-12 22:03:51 +0100 | <EvanR> | which is fine but it takes Just something for seemingly a reason |
| 2025-12-12 22:03:46 +0100 | <lambdabot> | "0.0000000000000000000000000000000000000000000000000000000000000000000000000... |
| 2025-12-12 22:03:45 +0100 | <monochrom> | > showFFloat (Just 100) 0 "" |
| 2025-12-12 22:03:14 +0100 | <EvanR> | yes Nothing seems to evoke the blessed algorithm |
| 2025-12-12 22:03:02 +0100 | <Lycurgus> | *fun |
| 2025-12-12 22:02:59 +0100 | <lambdabot> | "1.23" |
| 2025-12-12 22:02:58 +0100 | <monochrom> | > showFFloat Nothing 1.23 "" |
| 2025-12-12 22:02:53 +0100 | <Lycurgus> | engrish is so much funl, case in point, that is the 'even' of exasperation |
| 2025-12-12 22:02:47 +0100 | <EvanR> | 1.2300000000000000000000000000000 just seems absurd |
| 2025-12-12 22:01:43 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds) |
| 2025-12-12 22:00:47 +0100 | <EvanR> | what the heck is showFFloat even doing, hopefully getting performance out of its corner cutting |
| 2025-12-12 22:00:36 +0100 | Lycurgus | (~juan@user/Lycurgus) Lycurgus |
| 2025-12-12 21:58:27 +0100 | <lambdabot> | 122999999999999998223643160599749535322189331054687500 % 1 |
| 2025-12-12 21:58:25 +0100 | <int-e> | > toRational (1.23) * 10^53 |
| 2025-12-12 21:57:02 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-12 21:56:57 +0100 | jmcantrell_ | (~weechat@user/jmcantrell) jmcantrell |
| 2025-12-12 21:54:42 +0100 | <EvanR> | is there a "show float with more decimals but correctly" |
| 2025-12-12 21:54:18 +0100 | <EvanR> | so you have the floats 1.2299999999999998, 1.23, and 1.2300000000000002. The 1.23 is really 1.229999999999999982236431605997495353221893310546875, but no matter what I give showFFloat it shows 1.230000000000000000000, just zeros after this |
| 2025-12-12 21:50:53 +0100 | califax | (~califax@user/califx) califx |
| 2025-12-12 21:50:35 +0100 | trickard_ | trickard |
| 2025-12-12 21:45:55 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds) |
| 2025-12-12 21:42:45 +0100 | califax | (~califax@user/califx) (Remote host closed the connection) |
| 2025-12-12 21:41:15 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-12 21:39:52 +0100 | <haskellbridge> | <loonycyborg> There are some dedicated libraries for partial orders, like that one: https://hackage.haskell.org/package/pomaps-0.2.0.1/docs/Data-POSet.html |