Newest at the top
2025-09-17 11:31:38 +0200 | Square | (~Square4@user/square) (Ping timeout: 248 seconds) |
2025-09-17 11:29:59 +0200 | merijn | (~merijn@77.242.116.146) merijn |
2025-09-17 11:29:06 +0200 | arandombit | (~arandombi@user/arandombit) (Ping timeout: 256 seconds) |
2025-09-17 11:28:53 +0200 | haritz | (~hrtz@user/haritz) haritz |
2025-09-17 11:28:53 +0200 | haritz | (~hrtz@2a01:4b00:bc2e:7000:d5af:a266:ca31:5ef8) (Changing host) |
2025-09-17 11:28:53 +0200 | haritz | (~hrtz@2a01:4b00:bc2e:7000:d5af:a266:ca31:5ef8) |
2025-09-17 11:27:19 +0200 | CiaoSen | (~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) (Ping timeout: 244 seconds) |
2025-09-17 11:24:35 +0200 | arandombit | (~arandombi@user/arandombit) arandombit |
2025-09-17 11:21:23 +0200 | trickard_ | (~trickard@cpe-86-98-47-163.wireline.com.au) |
2025-09-17 11:21:10 +0200 | trickard_ | (~trickard@cpe-86-98-47-163.wireline.com.au) (Read error: Connection reset by peer) |
2025-09-17 11:18:54 +0200 | acidjnk | (~acidjnk@p200300d6e717191211482dfc0bb512ca.dip0.t-ipconnect.de) acidjnk |
2025-09-17 11:18:11 +0200 | comerijn | (~merijn@77.242.116.146) (Ping timeout: 250 seconds) |
2025-09-17 11:16:50 +0200 | tromp | (~textual@2001:1c00:3487:1b00:988d:4246:ce46:c357) (Quit: My iMac has gone to sleep. ZZZzzz…) |
2025-09-17 11:14:15 +0200 | CiaoSen | (~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) CiaoSen |
2025-09-17 11:13:53 +0200 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) (Ping timeout: 248 seconds) |
2025-09-17 11:11:13 +0200 | arandombit | (~arandombi@user/arandombit) (Ping timeout: 248 seconds) |
2025-09-17 11:09:19 +0200 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) humasect |
2025-09-17 11:06:18 +0200 | tremon | (~tremon@83.80.159.219) tremon |
2025-09-17 11:05:52 +0200 | arandombit | (~arandombi@user/arandombit) arandombit |
2025-09-17 11:05:51 +0200 | marinelli | (~weechat@gateway/tor-sasl/marinelli) marinelli |
2025-09-17 11:05:29 +0200 | marinelli | (~weechat@gateway/tor-sasl/marinelli) (Remote host closed the connection) |
2025-09-17 10:58:54 +0200 | vanishingideal | (~vanishing@user/vanishingideal) (Ping timeout: 244 seconds) |
2025-09-17 10:53:58 +0200 | arandombit | (~arandombi@user/arandombit) (Ping timeout: 256 seconds) |
2025-09-17 10:53:24 +0200 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 256 seconds) |
2025-09-17 10:48:50 +0200 | ljdarj | (~Thunderbi@user/ljdarj) ljdarj |
2025-09-17 10:48:19 +0200 | ljdarj | (~Thunderbi@user/ljdarj) (Client Quit) |
2025-09-17 10:47:41 +0200 | hsw | (~hsw@112-104-9-97.adsl.dynamic.seed.net.tw) hsw |
2025-09-17 10:45:45 +0200 | ljdarj | (~Thunderbi@user/ljdarj) ljdarj |
2025-09-17 10:44:58 +0200 | yegor | (~yegor@user/yegor) (Ping timeout: 260 seconds) |
2025-09-17 10:44:29 +0200 | vanishingideal | (~vanishing@user/vanishingideal) vanishingideal |
2025-09-17 10:42:32 +0200 | trickard_ | (~trickard@cpe-86-98-47-163.wireline.com.au) |
2025-09-17 10:39:57 +0200 | trickard | (~trickard@cpe-86-98-47-163.wireline.com.au) (Read error: Connection reset by peer) |
2025-09-17 10:39:09 +0200 | craunts7 | (~craunts@152.32.99.194) |
2025-09-17 10:35:13 +0200 | <tomsmeding> | now they're actually binary, not decimal, but same idea applies |
2025-09-17 10:35:01 +0200 | <tomsmeding> | this leads to more _absolute_ precision (i.e. smaller error epsilon) around small numbers |
2025-09-17 10:34:36 +0200 | <tomsmeding> | were they decimal with four digits of precision, you'd be able to represent 1.234e-4 and 1.234e100 both exactly, but not 1.2341e100 |
2025-09-17 10:33:58 +0200 | <tomsmeding> | floats are "always in scientific notation", with a fixed number of digits of precision |
2025-09-17 10:33:42 +0200 | <tomsmeding> | yes |
2025-09-17 10:33:23 +0200 | <yin> | more precision around small numbers, right? |
2025-09-17 10:33:09 +0200 | mari-estel | (~mari-este@user/mari-estel) (Read error: Connection reset by peer) |
2025-09-17 10:32:20 +0200 | <tomsmeding> | yin: the 5*2^55 scales etc. are arbitrary, just to make you not have to compare 1 % 180143985094819840 and 1 % 90071992547409920 |
2025-09-17 10:31:20 +0200 | mari73827 | (~mari-este@user/mari-estel) mari-estel |
2025-09-17 10:30:46 +0200 | <tomsmeding> | the correct result of the rounded inputs, that is |
2025-09-17 10:30:34 +0200 | <tomsmeding> | you lose precision in the product result, of course, but only after having virtually computed the correct result first |
2025-09-17 10:30:08 +0200 | <tomsmeding> | with n repeated additions, you'd get odd error effects around those boundaries; with a single multiplication, things are more well-behaved, I think |
2025-09-17 10:29:42 +0200 | <tomsmeding> | but multiplication is a one-shot operation, n * x is not x + x + ... + x |
2025-09-17 10:29:18 +0200 | <tomsmeding> | __monty__: that's fair |
2025-09-17 10:29:12 +0200 | <tomsmeding> | yin: ^ |
2025-09-17 10:29:10 +0200 | <tomsmeding> | whereas the error of 0.3 in Double is similar in scale to that of 0.1 and 0.2, and furthermore goes in the other direction, so it makes sense that 0.1 + 0.2 in Double rounds to 0.3 + epsilon |
2025-09-17 10:28:42 +0200 | drlkf | (~drlkf@chat-1.drlkf.net) drlkf |