Newest at the top
2025-04-28 14:08:14 +0200 | <tomsmeding> | kqr: toRational for Double simply takes the "exponent * fraction" representation that the IEEE float literally encodes, and gives you that as a Rational |
2025-04-28 14:05:46 +0200 | <haskellbridge> | <Liamzee> did haddock ever fix the reusable named chunk problem? |
2025-04-28 14:05:37 +0200 | akegalj | (~akegalj@144-188.dsl.iskon.hr) (Ping timeout: 248 seconds) |
2025-04-28 14:04:21 +0200 | <tomsmeding> | kqr: anything that has something in the denominator that is not a power of 2 is not representable exactly. |
2025-04-28 14:01:32 +0200 | <kqr> | But I think I can work around it by rounding myself at some appropriate precision. |
2025-04-28 13:59:18 +0200 | <kqr> | effect due to the above! |
2025-04-28 13:59:15 +0200 | <kqr> | In my case I have a bunch of old code that uses Doubles but accidentally ran into these errors in calculations, so I'm working my way through the code to convert them to fixed-precision numbers. However, in the meantime I need a way to convert back and forth between doubles and fixed precision numbers. The primitive way I tried first was fromRational . toRational but that didn't have the intended |
2025-04-28 13:56:59 +0200 | <opqdonut> | but there's a lot of design choices to make here, and quite a bit of old research papers written as well |
2025-04-28 13:55:35 +0200 | <opqdonut> | 2.3 gets converted to float as 2.29999995231628417969, which then gets printed as 2.3 because we can know that this is the closest float to 2.3, so there can be no confusion |
2025-04-28 13:50:53 +0200 | <opqdonut> | yeah, they're interested in something like reproducability |
2025-04-28 13:49:08 +0200 | <kqr> | Wow, more numbers than I thought are irrepresentable – only double-handling functions tend to round them off so I never notice. |
2025-04-28 13:48:27 +0200 | <kqr> | I'm guessing the toRational implementation truncates the value instead of rounding it. |
2025-04-28 13:48:02 +0200 | <kqr> | You're right. I was working with too little precision to detect the difference. Thanks |
2025-04-28 13:47:41 +0200 | <kqr> | Or no, it's not |
2025-04-28 13:47:39 +0200 | <opqdonut> | 1/10 is not representable as float anyway |
2025-04-28 13:47:36 +0200 | <kqr> | If you click the double tab it shows that 2.3 is representable with double precision |
2025-04-28 13:47:29 +0200 | <opqdonut> | yeah but it's the same |
2025-04-28 13:47:24 +0200 | <kqr> | No, wait, that's for a single-precision float. |
2025-04-28 13:46:15 +0200 | <kqr> | Oh. I wonder where I went wrong in my calculations! |
2025-04-28 13:43:40 +0200 | <opqdonut> | see eg. https://float.exposed/0x40133333 |
2025-04-28 13:43:36 +0200 | <opqdonut> | it's not perfectly representable, though |
2025-04-28 13:42:37 +0200 | prdak | (~Thunderbi@user/prdak) (Read error: Connection reset by peer) |
2025-04-28 13:40:03 +0200 | mari-estel | (~mari-este@user/mari-estel) mari-estel |
2025-04-28 13:35:47 +0200 | ColinRobinson | (~juan@user/JuanDaugherty) (Quit: praxis.meansofproduction.biz (juan@acm.org)) |
2025-04-28 13:35:02 +0200 | <kqr> | Is this known/expected only I've missed something? |
2025-04-28 13:34:55 +0200 | <kqr> | I find that toRational @Double 2.3 yields something close to 2.299999999 rather than 23 % 10 as I would expect. This seems strange to me because as far as I can tell, 2.3 is perfectly representable as a double-precision value. |
2025-04-28 13:30:13 +0200 | mari-estel | (~mari-este@user/mari-estel) (Ping timeout: 276 seconds) |
2025-04-28 13:27:24 +0200 | alexherbo2 | (~alexherbo@2a02-8440-250b-b0ac-7850-9e9f-0d14-2cca.rev.sfr.net) (Remote host closed the connection) |
2025-04-28 13:26:06 +0200 | prdak | (~Thunderbi@user/prdak) prdak |
2025-04-28 13:24:14 +0200 | alexherbo2 | (~alexherbo@2a02-8440-250b-b0ac-7850-9e9f-0d14-2cca.rev.sfr.net) alexherbo2 |
2025-04-28 13:23:56 +0200 | alexherbo2 | (~alexherbo@2a02-8440-250b-b0ac-7850-9e9f-0d14-2cca.rev.sfr.net) (Remote host closed the connection) |
2025-04-28 13:23:24 +0200 | alexherbo2 | (~alexherbo@2a02-8440-250b-b0ac-7850-9e9f-0d14-2cca.rev.sfr.net) alexherbo2 |
2025-04-28 13:23:07 +0200 | alexherbo2 | (~alexherbo@2a02-8440-250b-b0ac-7850-9e9f-0d14-2cca.rev.sfr.net) (Remote host closed the connection) |
2025-04-28 13:21:55 +0200 | AlexZenon | (~alzenon@178.34.151.238) |
2025-04-28 13:21:04 +0200 | AlexNoo | (~AlexNoo@178.34.151.238) |
2025-04-28 13:15:28 +0200 | typedfern_ | (~Typedfern@242.red-83-37-36.dynamicip.rima-tde.net) (Remote host closed the connection) |
2025-04-28 13:11:41 +0200 | JuanDaugherty | ColinRobinson |
2025-04-28 13:09:59 +0200 | Digit | (~user@user/digit) Digit |
2025-04-28 13:08:20 +0200 | AlexNoo | (~AlexNoo@178.34.151.238) (Read error: Connection reset by peer) |
2025-04-28 13:04:20 +0200 | AlexZenon | (~alzenon@178.34.151.238) (Quit: ;-) |
2025-04-28 13:02:01 +0200 | jespada | (~jespada@r186-49-240-45.dialup.adsl.anteldata.net.uy) jespada |
2025-04-28 12:51:52 +0200 | acidjnk_new | (~acidjnk@p200300d6e71c4f61394430d048071491.dip0.t-ipconnect.de) |
2025-04-28 12:49:22 +0200 | down200 | (~down200@shell.lug.mtu.edu) down200 |
2025-04-28 12:48:37 +0200 | acidjnk_new | (~acidjnk@p200300d6e71c4f61394430d048071491.dip0.t-ipconnect.de) (Ping timeout: 268 seconds) |
2025-04-28 12:44:24 +0200 | j1n37- | (~j1n37@user/j1n37) (Ping timeout: 260 seconds) |
2025-04-28 12:43:18 +0200 | j1n37 | (~j1n37@user/j1n37) j1n37 |
2025-04-28 12:38:01 +0200 | yin | (~z@user/zero) (Ping timeout: 252 seconds) |
2025-04-28 12:37:59 +0200 | mceresa | (~mceresa@user/mceresa) (Ping timeout: 260 seconds) |
2025-04-28 12:37:24 +0200 | qaotsap | (~paotsaq@2001:818:ea0e:8300:6733:50c0:6d2:30c2) (Ping timeout: 260 seconds) |
2025-04-28 12:37:12 +0200 | JuanDaugherty | (~juan@user/JuanDaugherty) JuanDaugherty |