Newest at the top
| 2025-04-22 18:21:03 +0200 | merijn | (~merijn@77.242.116.146) (Ping timeout: 276 seconds) |
| 2025-04-22 18:20:55 +0200 | tzh | (~tzh@c-76-115-131-146.hsd1.or.comcast.net) |
| 2025-04-22 18:17:53 +0200 | wootehfoot | (~wootehfoo@user/wootehfoot) wootehfoot |
| 2025-04-22 18:17:50 +0200 | harveypwca | (~harveypwc@2601:246:d080:f6e0:27d6:8cc7:eca9:c46c) (Quit: Leaving) |
| 2025-04-22 18:17:27 +0200 | euleritian | (~euleritia@ip4d17f82f.dynamic.kabel-deutschland.de) |
| 2025-04-22 18:17:09 +0200 | euleritian | (~euleritia@dynamic-176-000-129-028.176.0.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2025-04-22 18:06:14 +0200 | <haskellbridge> | <Liamzee> last update in 2024 |
| 2025-04-22 18:06:08 +0200 | <haskellbridge> | <Liamzee> https://github.com/orgs/polimorphic/repositories |
| 2025-04-22 18:05:25 +0200 | <haskellbridge> | <Liamzee> https://www.polimorphic.com |
| 2025-04-22 18:05:25 +0200 | <haskellbridge> | <Liamzee> huh, they're still alive? |
| 2025-04-22 18:04:13 +0200 | sprotte24 | (~sprotte24@p200300d16f2aeb0085c5313dace495b4.dip0.t-ipconnect.de) (Quit: Leaving) |
| 2025-04-22 18:01:46 +0200 | inca | (~inca@pool-96-255-212-224.washdc.fios.verizon.net) |
| 2025-04-22 18:00:58 +0200 | xstill_ | (xstill@fimu/xstill) xstill |
| 2025-04-22 18:00:07 +0200 | xstill_ | (xstill@fimu/xstill) (Ping timeout: 244 seconds) |
| 2025-04-22 17:59:52 +0200 | UltraFuzzy | (~UltraFuzz@c-24-12-96-73.hsd1.il.comcast.net) () |
| 2025-04-22 17:59:21 +0200 | euleritian | (~euleritia@dynamic-176-000-129-028.176.0.pool.telefonica.de) |
| 2025-04-22 17:59:21 +0200 | P1RATEZ | (~piratez@user/p1ratez) P1RATEZ |
| 2025-04-22 17:57:29 +0200 | euleritian | (~euleritia@dynamic-176-000-197-007.176.0.pool.telefonica.de) (Ping timeout: 252 seconds) |
| 2025-04-22 17:56:47 +0200 | Guest55 | (~Guest55@149.115.69.184) (Client Quit) |
| 2025-04-22 17:56:06 +0200 | Guest55 | (~Guest55@149.115.69.184) |
| 2025-04-22 17:53:49 +0200 | inca | (~inca@pool-96-255-212-224.washdc.fios.verizon.net) (Ping timeout: 252 seconds) |
| 2025-04-22 17:53:14 +0200 | UltraFuzzy | (~UltraFuzz@c-24-12-96-73.hsd1.il.comcast.net) |
| 2025-04-22 17:52:30 +0200 | chele | (~chele@user/chele) (Remote host closed the connection) |
| 2025-04-22 17:51:25 +0200 | <tomsmeding> | okay that makes sense |
| 2025-04-22 17:51:18 +0200 | <lambdabot> | 0.1 |
| 2025-04-22 17:51:16 +0200 | <tomsmeding> | > 1/20 + 19/20 * 1/19 |
| 2025-04-22 17:50:40 +0200 | <EvanR> | lol |
| 2025-04-22 17:50:39 +0200 | <int-e> | EvanR: That only works for binary answers. |
| 2025-04-22 17:50:35 +0200 | <tomsmeding> | if only you could make wrong code right by passing it through a NOT gate |
| 2025-04-22 17:50:15 +0200 | <EvanR> | I feel like monochrome should suggest taking the 100% wrong LLM and post process it with a NOT gate |
| 2025-04-22 17:50:08 +0200 | amadaluzia | (~amadaluzi@2a00:23c7:ed8b:6701:6e86:b77b:c1b:7762) (Quit: Hi, this is Paul Allen. I'm being called away to London for a few days. Meredith, I'll call you when I get back. Hasta la vista, baby.) |
| 2025-04-22 17:49:46 +0200 | <int-e> | . o O ( 19 hoomans and one LLM ) |
| 2025-04-22 17:49:12 +0200 | <int-e> | But really... it becomes a modelling question. Maybe you have 20 programmers, and 19 of them are perfect while one of them produces faulty code all the time, and you assign two programmers to implement the two functions (one each). |
| 2025-04-22 17:49:11 +0200 | <tomsmeding> | if f1 is faulty in 5% of the cases and f2 is also faulty in 5% of the cases, _at most_ 10% of the cases see one of the two functions being faulty |
| 2025-04-22 17:48:42 +0200 | <tomsmeding> | no |
| 2025-04-22 17:48:37 +0200 | <EvanR> | could you go below 90% |
| 2025-04-22 17:48:34 +0200 | inca | (~inca@pool-96-255-212-224.washdc.fios.verizon.net) |
| 2025-04-22 17:48:23 +0200 | <tomsmeding> | 90% is a lower bound; any less maliciously correlated and the probability will be higher than 90% |
| 2025-04-22 17:48:00 +0200 | <tomsmeding> | but the combination has only 90% chance of being correct |
| 2025-04-22 17:47:40 +0200 | <tomsmeding> | 95% chance |
| 2025-04-22 17:47:35 +0200 | <int-e> | heck f1 and f2 could share code, though that would likely move the probability in the opposite direction |
| 2025-04-22 17:47:32 +0200 | <tomsmeding> | both now have 95% of being correct |
| 2025-04-22 17:47:30 +0200 | <EvanR> | like, one is implemented using the other |
| 2025-04-22 17:47:27 +0200 | <tomsmeding> | roll a d20 and introduce a bug in f1 if it's 1, and introduce a bug in f2 if it's 2 |
| 2025-04-22 17:47:18 +0200 | <int-e> | it's a modelling problem |
| 2025-04-22 17:47:00 +0200 | <EvanR> | how would they be correlated |
| 2025-04-22 17:46:35 +0200 | <tomsmeding> | (if faultiness of f1 and f2 is uncorrelated, then that second 5% will partially overlap with the first) |
| 2025-04-22 17:46:22 +0200 | <int-e> | too slow :) |
| 2025-04-22 17:46:05 +0200 | <int-e> | EvanR: it's possible that each function has a 5% chance of being implemented incorrectly, but that at least one of them is always correct, so those 5% never overlap in the probability space |
| 2025-04-22 17:46:04 +0200 | <tomsmeding> | then in 5 + 5 = 10% of the universes, either f1 or f2 is faulty |