2025/09/17

Newest at the top

2025-09-17 11:31:38 +0200Square(~Square4@user/square) (Ping timeout: 248 seconds)
2025-09-17 11:29:59 +0200merijn(~merijn@77.242.116.146) merijn
2025-09-17 11:29:06 +0200arandombit(~arandombi@user/arandombit) (Ping timeout: 256 seconds)
2025-09-17 11:28:53 +0200haritz(~hrtz@user/haritz) haritz
2025-09-17 11:28:53 +0200haritz(~hrtz@2a01:4b00:bc2e:7000:d5af:a266:ca31:5ef8) (Changing host)
2025-09-17 11:28:53 +0200haritz(~hrtz@2a01:4b00:bc2e:7000:d5af:a266:ca31:5ef8)
2025-09-17 11:27:19 +0200CiaoSen(~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) (Ping timeout: 244 seconds)
2025-09-17 11:24:35 +0200arandombit(~arandombi@user/arandombit) arandombit
2025-09-17 11:21:23 +0200trickard_(~trickard@cpe-86-98-47-163.wireline.com.au)
2025-09-17 11:21:10 +0200trickard_(~trickard@cpe-86-98-47-163.wireline.com.au) (Read error: Connection reset by peer)
2025-09-17 11:18:54 +0200acidjnk(~acidjnk@p200300d6e717191211482dfc0bb512ca.dip0.t-ipconnect.de) acidjnk
2025-09-17 11:18:11 +0200comerijn(~merijn@77.242.116.146) (Ping timeout: 250 seconds)
2025-09-17 11:16:50 +0200tromp(~textual@2001:1c00:3487:1b00:988d:4246:ce46:c357) (Quit: My iMac has gone to sleep. ZZZzzz…)
2025-09-17 11:14:15 +0200CiaoSen(~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) CiaoSen
2025-09-17 11:13:53 +0200humasect(~humasect@dyn-192-249-132-90.nexicom.net) (Ping timeout: 248 seconds)
2025-09-17 11:11:13 +0200arandombit(~arandombi@user/arandombit) (Ping timeout: 248 seconds)
2025-09-17 11:09:19 +0200humasect(~humasect@dyn-192-249-132-90.nexicom.net) humasect
2025-09-17 11:06:18 +0200tremon(~tremon@83.80.159.219) tremon
2025-09-17 11:05:52 +0200arandombit(~arandombi@user/arandombit) arandombit
2025-09-17 11:05:51 +0200marinelli(~weechat@gateway/tor-sasl/marinelli) marinelli
2025-09-17 11:05:29 +0200marinelli(~weechat@gateway/tor-sasl/marinelli) (Remote host closed the connection)
2025-09-17 10:58:54 +0200vanishingideal(~vanishing@user/vanishingideal) (Ping timeout: 244 seconds)
2025-09-17 10:53:58 +0200arandombit(~arandombi@user/arandombit) (Ping timeout: 256 seconds)
2025-09-17 10:53:24 +0200ljdarj(~Thunderbi@user/ljdarj) (Ping timeout: 256 seconds)
2025-09-17 10:48:50 +0200ljdarj(~Thunderbi@user/ljdarj) ljdarj
2025-09-17 10:48:19 +0200ljdarj(~Thunderbi@user/ljdarj) (Client Quit)
2025-09-17 10:47:41 +0200hsw(~hsw@112-104-9-97.adsl.dynamic.seed.net.tw) hsw
2025-09-17 10:45:45 +0200ljdarj(~Thunderbi@user/ljdarj) ljdarj
2025-09-17 10:44:58 +0200yegor(~yegor@user/yegor) (Ping timeout: 260 seconds)
2025-09-17 10:44:29 +0200vanishingideal(~vanishing@user/vanishingideal) vanishingideal
2025-09-17 10:42:32 +0200trickard_(~trickard@cpe-86-98-47-163.wireline.com.au)
2025-09-17 10:39:57 +0200trickard(~trickard@cpe-86-98-47-163.wireline.com.au) (Read error: Connection reset by peer)
2025-09-17 10:39:09 +0200craunts7(~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 +0200mari-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 +0200mari73827(~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 +0200drlkf(~drlkf@chat-1.drlkf.net) drlkf