Newest at the top
2025-04-02 19:36:12 +0200 | preflex | (~preflex@user/mauke/bot/preflex) (Remote host closed the connection) |
2025-04-02 19:36:07 +0200 | mauke | (~mauke@user/mauke) (Remote host closed the connection) |
2025-04-02 19:35:58 +0200 | Rembane | (~Rembane@user/Rembane) (Quit: WeeChat 4.1.1) |
2025-04-02 19:34:49 +0200 | <lambdabot> | "1.5833333333333333" |
2025-04-02 19:34:47 +0200 | <int-e> | > show (19/12) |
2025-04-02 19:34:13 +0200 | sprotte24 | (~sprotte24@p200300d16f1053003d869356f7727199.dip0.t-ipconnect.de) (Ping timeout: 248 seconds) |
2025-04-02 19:33:50 +0200 | <c_wraith> | yeah, it's actually hard to get that behavior from C |
2025-04-02 19:33:28 +0200 | <EvanR> | it doesn't produce "shortest representation that would parse back to the original value" |
2025-04-02 19:33:16 +0200 | <EvanR> | though %g does produce a shorter version if it would end in zeros |
2025-04-02 19:32:53 +0200 | <EvanR> | I guess C is so old they "never thought of it" |
2025-04-02 19:32:29 +0200 | <lambdabot> | 1.141592653589793 |
2025-04-02 19:32:28 +0200 | <int-e> | > read "1.1415926535897929" :: Double |
2025-04-02 19:32:14 +0200 | <EvanR> | c_wraith, right, it seems many languages do this |
2025-04-02 19:32:03 +0200 | <lambdabot> | 1.141592653589793 |
2025-04-02 19:32:01 +0200 | <EvanR> | > read "1.1415926535897930" :: Double |
2025-04-02 19:31:55 +0200 | <lambdabot> | 1.1415926535897931 |
2025-04-02 19:31:54 +0200 | <EvanR> | > read "1.1415926535897931" :: Double |
2025-04-02 19:31:45 +0200 | <c_wraith> | technically, its operating constraint is that it produces the shortest decimal that parses back to the same bit pattern. |
2025-04-02 19:31:25 +0200 | <EvanR> | note to self not a great "random irrational" |
2025-04-02 19:31:11 +0200 | sprotte24_ | (~sprotte24@p200300d16f105300edc0583ef9378a6d.dip0.t-ipconnect.de) |
2025-04-02 19:31:08 +0200 | <EvanR> | lol, pi is like the only one which is short xD |
2025-04-02 19:31:01 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
2025-04-02 19:30:55 +0200 | <lambdabot> | "3.141592653589793" |
2025-04-02 19:30:54 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 252 seconds) |
2025-04-02 19:30:54 +0200 | <EvanR> | > show pi |
2025-04-02 19:29:11 +0200 | <lambdabot> | "1.1415926535897931" |
2025-04-02 19:29:09 +0200 | <int-e> | > show (pi-2) -- checking that theory |
2025-04-02 19:28:24 +0200 | coldmountain | (sid484352@id-484352.helmsley.irccloud.com) (Quit: Connection closed for inactivity) |
2025-04-02 19:27:39 +0200 | ash3en | (~Thunderbi@ip1f10cbd6.dynamic.kabel-deutschland.de) (Ping timeout: 246 seconds) |
2025-04-02 19:27:31 +0200 | <int-e> | (well, I think) |
2025-04-02 19:27:24 +0200 | <int-e> | (it's less likely to use 16 digits between 1 and 2 than between 2 and 4) |
2025-04-02 19:26:51 +0200 | <lambdabot> | "1.5707963267948966" |
2025-04-02 19:26:49 +0200 | <int-e> | > show (pi / 2) |
2025-04-02 19:26:40 +0200 | <lambdabot> | "2.8284271247461903" |
2025-04-02 19:26:38 +0200 | <int-e> | > show (sqrt 8) |
2025-04-02 19:26:17 +0200 | <lambdabot> | "2.8284271247461903" |
2025-04-02 19:26:17 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-04-02 19:26:16 +0200 | <int-e> | > show (sqrt 8) |
2025-04-02 19:25:51 +0200 | <EvanR> | looking for a float which haskell prints out with 17 sigfigs instead of 16, to see if DBL_DECIMAL_DIG is not full of shit xD |
2025-04-02 19:23:12 +0200 | byte | (~mu@user/byte) byte |
2025-04-02 19:16:58 +0200 | byte | (~mu@user/byte) (Ping timeout: 272 seconds) |
2025-04-02 19:15:34 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 268 seconds) |
2025-04-02 19:13:16 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich |
2025-04-02 19:11:01 +0200 | <int-e> | That's all the digits you'll get from GHC's implementation of `show` and `Numeric` |
2025-04-02 19:10:25 +0200 | <yahb2> | ([3,1,4,1,5,9,2,6,5,3,5,8,9,7,9,3],1) |
2025-04-02 19:10:25 +0200 | <int-e> | % GHC.Internal.Float.floatToDigits 10 pi |
2025-04-02 19:10:11 +0200 | <EvanR> | yes but all these other languages are using a "better" (shorter) approximation that still works |
2025-04-02 19:08:15 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-04-02 19:06:50 +0200 | <int-e> | so 3.1415926535897931 is better in that sense than 3.1415926535897930 |
2025-04-02 19:06:24 +0200 | <int-e> | well it should arguable produce a truncated and properly rounded approximation of 3.141592653589793115997963468544185161590576171875 = toRational pi |