2025/04/06

Newest at the top

2025-04-06 18:53:22 +0200tromp(~textual@2001:1c00:3487:1b00:c873:d422:44c2:cc0c) (Quit: My iMac has gone to sleep. ZZZzzz…)
2025-04-06 18:43:49 +0200 <ski> er .. i suppose, not with `0'. same issue, though
2025-04-06 18:42:57 +0200 <ski> but we want the neutral element of the given group to be identified with `-1', not with `1', of the group of integers
2025-04-06 18:42:06 +0200 <ski> hmm .. no, that doesn't quite work. coproduct would identify the neutral elements of the two groups
2025-04-06 18:39:39 +0200 <ski> (note, arbitrary groups, not abelian ones)
2025-04-06 18:39:11 +0200 <ski> i suppose you could take coproduct of the given group, and the group of integers
2025-04-06 18:37:40 +0200__monty__(~toonn@user/toonn) (Quit: Lost terminal)
2025-04-06 18:37:21 +0200 <mauke> and inverse x' = -x - 2?
2025-04-06 18:37:19 +0200skiidly ponders making this into a word group
2025-04-06 18:36:05 +0200hattckory(~hattckory@bras-base-toroon4524w-grc-30-70-27-118-207.dsl.bell.ca)
2025-04-06 18:33:46 +0200 <monochrom> Spin-off exercise: Suppose x +++ y = x + y + 1. Prove that +++ is a monoid operation with -1 as the identity. >:)
2025-04-06 18:29:21 +0200 <ski> it sounded like thirdofmay18081814goya wanted something a bit reminiscent of the caching part, but for every bind automatically
2025-04-06 18:28:32 +0200 <ski> i recall doing a CGI monad, which had an `io :: (Show a,Read a) => IO a -> CGI a' operation, caching the result of `IO' operations, serializing them into the generated page (when a query was generated), so that the program could then be resumed, fastforwarded to the point where it left off, to continue on
2025-04-06 18:28:06 +0200 <monochrom> s/is the/in the/
2025-04-06 18:27:50 +0200 <monochrom> Of course we know the right way is to hide the counter increment is the something else.
2025-04-06 18:27:42 +0200 <enikar> let monads do their job :)
2025-04-06 18:27:12 +0200 <monochrom> Not to endorse it, but presumably the monad also does something else, and the author hides a counter increment in bind as a proxy to count cost.
2025-04-06 18:26:58 +0200amadaluzia(~amadaluzi@user/amadaluzia) (Ping timeout: 244 seconds)
2025-04-06 18:24:52 +0200 <monochrom> :)
2025-04-06 18:24:51 +0200 <enikar> I don't understand the use case.
2025-04-06 18:24:34 +0200 <ski> dubious reasons
2025-04-06 18:24:19 +0200 <enikar> why one would want to count bind?
2025-04-06 18:22:52 +0200toby-bro(~toby-bro@user/toby-bro) toby-bro
2025-04-06 18:20:01 +0200 <monochrom> This is what the model "monad/>>= is programmable semicolon" gets right. In C programming, do people even imagine writing a program that counts its own lines of code?
2025-04-06 18:15:45 +0200hattckory(~hattckory@bras-base-toroon4524w-grc-30-70-27-118-207.dsl.bell.ca) (Ping timeout: 248 seconds)
2025-04-06 18:15:22 +0200 <monochrom> But I don't like to tell people about this. Counting binds is every beginners favourite anti-monad anti-pattern.
2025-04-06 18:14:54 +0200 <monochrom> Counting binds does not break the associative law, it just can break the identity laws. But with pure contributing -1, (m >>= pure) has the same count as m because you have x+1-1. SImilarly for the other identity law.
2025-04-06 18:09:08 +0200jmcantrell_(644f1bed9a@user/jmcantrell) jmcantrell
2025-04-06 18:08:59 +0200__jmcantrell__jmcantrell
2025-04-06 18:08:59 +0200Guest7797(644f1bed9a@user/jmcantrell) (Killed (copper.libera.chat (Nickname regained by services)))
2025-04-06 18:08:59 +0200jmcantrellGuest7797
2025-04-06 18:07:40 +0200target_i(~target_i@user/target-i/x-6023099) target_i
2025-04-06 18:02:26 +0200hattckory(~hattckory@bras-base-toroon4524w-grc-30-70-27-118-207.dsl.bell.ca)
2025-04-06 18:01:38 +0200acidjnk_new3(~acidjnk@p200300d6e71c4f1484a8b96e5b185115.dip0.t-ipconnect.de) (Ping timeout: 245 seconds)
2025-04-06 17:51:49 +0200dhil(~dhil@2a0c:b381:52e:3600:4c26:24b1:e3bc:1cdd) (Ping timeout: 248 seconds)
2025-04-06 17:49:56 +0200picnoir(~picnoir@about/aquilenet/vodoo/NinjaTrappeur) NinjaTrappeur
2025-04-06 17:48:12 +0200picnoir(~picnoir@about/aquilenet/vodoo/NinjaTrappeur) (Quit: WeeChat 4.5.1)
2025-04-06 17:31:43 +0200tromp(~textual@2001:1c00:3487:1b00:c873:d422:44c2:cc0c)
2025-04-06 17:26:50 +0200amadaluzia_(~amadaluzi@user/amadaluzia) amadaluzia
2025-04-06 17:26:50 +0200amadaluzia_(~amadaluzi@host81-159-254-182.range81-159.btcentralplus.com) (Changing host)
2025-04-06 17:25:11 +0200amadaluzia_(~amadaluzi@host81-159-254-182.range81-159.btcentralplus.com)
2025-04-06 17:18:58 +0200__jmcantrell__(~weechat@user/jmcantrell) jmcantrell
2025-04-06 17:15:52 +0200mauke(~mauke@user/mauke) mauke
2025-04-06 17:12:52 +0200bitdex(~bitdex@gateway/tor-sasl/bitdex) bitdex
2025-04-06 17:07:22 +0200acidjnk_new3(~acidjnk@p200300d6e71c4f1484a8b96e5b185115.dip0.t-ipconnect.de) acidjnk
2025-04-06 17:07:00 +0200Guest21(~Guest21@2600:6c4c:787f:a0a4:d65b:f01e:6eda:2fac) (Quit: Client closed)
2025-04-06 17:05:45 +0200hattckory(~hattckory@bras-base-toroon4524w-grc-30-70-27-118-207.dsl.bell.ca) (Ping timeout: 276 seconds)
2025-04-06 17:01:46 +0200Guest21(~Guest21@2600:6c4c:787f:a0a4:d65b:f01e:6eda:2fac)
2025-04-06 17:00:51 +0200hattckory(~hattckory@bras-base-toroon4524w-grc-30-70-27-118-207.dsl.bell.ca)
2025-04-06 16:58:00 +0200segfaultfizzbuzz(~segfaultf@23-93-74-222.fiber.dynamic.sonic.net) (Quit: segfaultfizzbuzz)