2025/04/28

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 +0200akegalj(~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 +0200prdak(~Thunderbi@user/prdak) (Read error: Connection reset by peer)
2025-04-28 13:40:03 +0200mari-estel(~mari-este@user/mari-estel) mari-estel
2025-04-28 13:35:47 +0200ColinRobinson(~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 +0200mari-estel(~mari-este@user/mari-estel) (Ping timeout: 276 seconds)
2025-04-28 13:27:24 +0200alexherbo2(~alexherbo@2a02-8440-250b-b0ac-7850-9e9f-0d14-2cca.rev.sfr.net) (Remote host closed the connection)
2025-04-28 13:26:06 +0200prdak(~Thunderbi@user/prdak) prdak
2025-04-28 13:24:14 +0200alexherbo2(~alexherbo@2a02-8440-250b-b0ac-7850-9e9f-0d14-2cca.rev.sfr.net) alexherbo2
2025-04-28 13:23:56 +0200alexherbo2(~alexherbo@2a02-8440-250b-b0ac-7850-9e9f-0d14-2cca.rev.sfr.net) (Remote host closed the connection)
2025-04-28 13:23:24 +0200alexherbo2(~alexherbo@2a02-8440-250b-b0ac-7850-9e9f-0d14-2cca.rev.sfr.net) alexherbo2
2025-04-28 13:23:07 +0200alexherbo2(~alexherbo@2a02-8440-250b-b0ac-7850-9e9f-0d14-2cca.rev.sfr.net) (Remote host closed the connection)
2025-04-28 13:21:55 +0200AlexZenon(~alzenon@178.34.151.238)
2025-04-28 13:21:04 +0200AlexNoo(~AlexNoo@178.34.151.238)
2025-04-28 13:15:28 +0200typedfern_(~Typedfern@242.red-83-37-36.dynamicip.rima-tde.net) (Remote host closed the connection)
2025-04-28 13:11:41 +0200JuanDaughertyColinRobinson
2025-04-28 13:09:59 +0200Digit(~user@user/digit) Digit
2025-04-28 13:08:20 +0200AlexNoo(~AlexNoo@178.34.151.238) (Read error: Connection reset by peer)
2025-04-28 13:04:20 +0200AlexZenon(~alzenon@178.34.151.238) (Quit: ;-)
2025-04-28 13:02:01 +0200jespada(~jespada@r186-49-240-45.dialup.adsl.anteldata.net.uy) jespada
2025-04-28 12:51:52 +0200acidjnk_new(~acidjnk@p200300d6e71c4f61394430d048071491.dip0.t-ipconnect.de)
2025-04-28 12:49:22 +0200down200(~down200@shell.lug.mtu.edu) down200
2025-04-28 12:48:37 +0200acidjnk_new(~acidjnk@p200300d6e71c4f61394430d048071491.dip0.t-ipconnect.de) (Ping timeout: 268 seconds)
2025-04-28 12:44:24 +0200j1n37-(~j1n37@user/j1n37) (Ping timeout: 260 seconds)
2025-04-28 12:43:18 +0200j1n37(~j1n37@user/j1n37) j1n37
2025-04-28 12:38:01 +0200yin(~z@user/zero) (Ping timeout: 252 seconds)
2025-04-28 12:37:59 +0200mceresa(~mceresa@user/mceresa) (Ping timeout: 260 seconds)
2025-04-28 12:37:24 +0200qaotsap(~paotsaq@2001:818:ea0e:8300:6733:50c0:6d2:30c2) (Ping timeout: 260 seconds)
2025-04-28 12:37:12 +0200JuanDaugherty(~juan@user/JuanDaugherty) JuanDaugherty