Newest at the top
| 2025-12-05 12:18:19 +0100 | chromoblob | (~chromoblo@user/chromob1ot1c) (Read error: Connection reset by peer) |
| 2025-12-05 12:15:01 +0100 | Enrico63 | (~Enrico63@host-212-171-79-170.retail.telecomitalia.it) Enrico63 |
| 2025-12-05 12:11:37 +0100 | chromoblob | (~chromoblo@user/chromob1ot1c) chromoblob\0 |
| 2025-12-05 12:11:07 +0100 | chromoblob | (~chromoblo@user/chromob1ot1c) (Ping timeout: 264 seconds) |
| 2025-12-05 12:06:30 +0100 | acidjnk | (~acidjnk@p200300d6e7171916e981ce74d2c64e2e.dip0.t-ipconnect.de) (Read error: Connection reset by peer) |
| 2025-12-05 12:02:46 +0100 | divlamir | (~divlamir@user/divlamir) divlamir |
| 2025-12-05 12:00:28 +0100 | takuan | (~takuan@d8D86B9E9.access.telenet.be) |
| 2025-12-05 11:57:19 +0100 | fp | (~Thunderbi@130.233.70.22) (Ping timeout: 260 seconds) |
| 2025-12-05 11:52:13 +0100 | divlamir | (~divlamir@user/divlamir) (Ping timeout: 264 seconds) |
| 2025-12-05 11:51:38 +0100 | jyf | (~jyf@user/jyf) () |
| 2025-12-05 11:50:45 +0100 | mulk | (~mulk@pd9514972.dip0.t-ipconnect.de) (Ping timeout: 245 seconds) |
| 2025-12-05 11:48:46 +0100 | jyf | (~jyf@user/jyf) jyf |
| 2025-12-05 11:37:55 +0100 | lambda_gibbon | (~lambda_gi@2603:7080:ee00:37d8:35d4:1aac:9a2f:cd11) (Ping timeout: 246 seconds) |
| 2025-12-05 11:37:02 +0100 | divlamir | (~divlamir@user/divlamir) divlamir |
| 2025-12-05 11:34:40 +0100 | trickard_ | (~trickard@cpe-85-98-47-163.wireline.com.au) |
| 2025-12-05 11:34:08 +0100 | chencheng | (~chencheng@user/chencheng) (Quit: Client closed) |
| 2025-12-05 11:33:37 +0100 | trickard_ | (~trickard@cpe-85-98-47-163.wireline.com.au) (Ping timeout: 264 seconds) |
| 2025-12-05 11:33:25 +0100 | lambda_gibbon | (~lambda_gi@2603:7080:ee00:37d8:35d4:1aac:9a2f:cd11) |
| 2025-12-05 11:24:44 +0100 | chencheng | (~chencheng@user/chencheng) chencheng |
| 2025-12-05 11:24:44 +0100 | chencheng | (~chencheng@38.207.158.7) (Changing host) |
| 2025-12-05 11:24:30 +0100 | chencheng | (~chencheng@38.207.158.7) |
| 2025-12-05 11:23:50 +0100 | tromp | (~textual@2001:1c00:3487:1b00:4ec:c6c9:2447:6676) |
| 2025-12-05 11:23:24 +0100 | trickard_ | (~trickard@cpe-85-98-47-163.wireline.com.au) |
| 2025-12-05 11:23:10 +0100 | trickard | (~trickard@cpe-85-98-47-163.wireline.com.au) (Read error: Connection reset by peer) |
| 2025-12-05 11:20:13 +0100 | tromp | (~textual@2001:1c00:3487:1b00:4ec:c6c9:2447:6676) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2025-12-05 11:06:26 +0100 | __monty__ | (~toonn@user/toonn) toonn |
| 2025-12-05 10:52:31 +0100 | xff0x | (~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) (Ping timeout: 264 seconds) |
| 2025-12-05 10:44:56 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) humasect |
| 2025-12-05 10:44:11 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) (Remote host closed the connection) |
| 2025-12-05 10:43:15 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) humasect |
| 2025-12-05 10:33:37 +0100 | trickard_ | trickard |
| 2025-12-05 10:32:36 +0100 | lambda_gibbon | (~lambda_gi@2603:7080:ee00:37d8:35d4:1aac:9a2f:cd11) (Ping timeout: 252 seconds) |
| 2025-12-05 10:29:45 +0100 | <ski> | since it is uniform in the dimensions, you only need to consider an arbitrary dimension, yes |
| 2025-12-05 10:28:58 +0100 | <lucabtz> | i suppose maybe it can be shown for 1D grids where there a are few cases and then handled inductively for all dimensions |
| 2025-12-05 10:28:35 +0100 | <ski> | you just have to handle all the cases |
| 2025-12-05 10:28:10 +0100 | lambda_gibbon | (~lambda_gi@2603:7080:ee00:37d8:35d4:1aac:9a2f:cd11) |
| 2025-12-05 10:23:12 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-05 10:23:01 +0100 | <lucabtz> | though honestly idk if it is so trivial to come up with an actual proof, maybe it is |
| 2025-12-05 10:22:24 +0100 | <lucabtz> | i dont see why associativity wouldnt be satified here because this is just about tiling up the grids to match the bigger grid, if the grids are all equal then associativity is a consequence of associativity of ., if some have dimension 1 it shouldn't matter when you tile them bigger |
| 2025-12-05 10:22:21 +0100 | <ski> | hm, yea, i think you're right (after pondering the conditions) |
| 2025-12-05 10:20:07 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds) |
| 2025-12-05 10:19:49 +0100 | <ski> | (yea .. in terms of `liftA2 (,) :: Applicative i => i a -> i b -> i (a,b)', we're asking whether this operation is associative, up to reassociating the `((a,b),c)' vs. `(a,(b,c))' in the result. it's just that we then have rexpressed this (not "on the nose") associative law in terms of its equivalent condition in terms of `(<*>)') |
| 2025-12-05 10:19:03 +0100 | <lucabtz> | i still think it is satified by broadcasting, for example say in order you have (w, 1) <*> (1, h) <*> (w, h), associating on the left you have (w, 1) <*> (1, h) = (w, h) and then (w, h) <*> (w, h) = (w, h), on the right (1, h) <*> (w, h) = (w, h) and then (w, 1) <*> (w, h) = (w, h) |
| 2025-12-05 10:17:38 +0100 | <ski> | anyway, the question is whether in `(M * N) * O' and `M * (N * O)', where `*' is some operation doing this kind of broadcasting, whether `M * N' and then `(M * N) * O' is well-defined is equivalent to `N * O' and then `M * (N * O)' being well-defined |
| 2025-12-05 10:16:53 +0100 | <lucabtz> | literal associativity of <*> makes no sense because the domains of the operator on the left and right are different |
| 2025-12-05 10:16:16 +0100 | <lucabtz> | it's not literal associativity of <*> but i get it makes sense to call is associativity |
| 2025-12-05 10:15:38 +0100 | <lucabtz> | it's okay i understood already from u <*> (v <*> w) = pure (.) <*> u <*> v <*> w |
| 2025-12-05 10:15:16 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-05 10:14:47 +0100 | <ski> | liftA2 (uncurry . f) ia (liftA2 (,) ib ic) = liftA2 (uncurry f) (liftA2 (,) ia ib) ic -- or, with an arbitrary function `f', rather than triples |
| 2025-12-05 10:13:16 +0100 | <lucabtz> | yeah i get what you mean |