Newest at the top
2025-10-14 17:13:55 +0200 | mreh | (~matthew@host86-146-25-125.range86-146.btcentralplus.com) |
2025-10-14 17:10:13 +0200 | inline | (~inlinE@ip-178-202-059-161.um47.pools.vodafone-ip.de) Inline |
2025-10-14 17:09:48 +0200 | dhil | (~dhil@5.151.29.137) (Remote host closed the connection) |
2025-10-14 17:06:27 +0200 | gustrb | (~gustrb@191.243.134.87) (Ping timeout: 244 seconds) |
2025-10-14 17:06:24 +0200 | Zemy | (~Zemy@syn-076-184-041-021.res.spectrum.com) (Ping timeout: 256 seconds) |
2025-10-14 17:05:15 +0200 | mreh | (~matthew@host86-146-25-125.range86-146.btcentralplus.com) (Ping timeout: 256 seconds) |
2025-10-14 17:03:57 +0200 | infinity0 | (~infinity0@pwned.gg) (Ping timeout: 250 seconds) |
2025-10-14 17:02:47 +0200 | Zemy_ | (~Zemy@2600:100c:b0a0:3fd9:78c1:9aff:fe21:5d9e) |
2025-10-14 16:47:26 +0200 | Square3 | (~Square@user/square) Square |
2025-10-14 16:41:44 +0200 | jreicher | (~user@user/jreicher) (Ping timeout: 260 seconds) |
2025-10-14 16:39:08 +0200 | trickard_ | (~trickard@cpe-54-98-47-163.wireline.com.au) |
2025-10-14 16:38:55 +0200 | trickard_ | (~trickard@cpe-54-98-47-163.wireline.com.au) (Read error: Connection reset by peer) |
2025-10-14 16:35:38 +0200 | Googulator18 | (~Googulato@2a01-036d-0106-03fa-dc7a-fb6e-71bb-aaf0.pool6.digikabel.hu) |
2025-10-14 16:35:36 +0200 | Googulator6 | (~Googulato@2a01-036d-0106-03fa-dc7a-fb6e-71bb-aaf0.pool6.digikabel.hu) (Quit: Client closed) |
2025-10-14 16:29:48 +0200 | Beowulf | (florian@2a01:4f9:3b:2d56::2) |
2025-10-14 16:27:04 +0200 | Unicorn_Princess | (~Unicorn_P@user/Unicorn-Princess/x-3540542) Unicorn_Princess |
2025-10-14 16:24:58 +0200 | mochie | (~mochie@user/mochie) mochie |
2025-10-14 16:24:21 +0200 | Beowulf | (florian@2a01:4f9:3b:2d56::2) (Quit: = "") |
2025-10-14 16:22:49 +0200 | <ski> | no worries. was fun to ponder a bit |
2025-10-14 16:22:36 +0200 | <ski> | ("free" is relative to the target category (monoids, commutative monoids, commutative idempotent monoids, ..), and also to the source category (sets, monoids, ..). "free commutative monoid on a monoid" means we force multiplication to be commutative, generally causing a lot of previously distinct elements to now be identified with each other. the "abelianization" of a monoid) |
2025-10-14 16:21:02 +0200 | tomsmeding | has to go, sorry |
2025-10-14 16:20:32 +0200 | <ski> | "bags/sets are not quite free" -- they are free, just not free *plain* monoids |
2025-10-14 16:20:03 +0200 | <ski> | hmm .. `Map (k0,k1) v -> Map k0 v -> Map k1 v' would be a similar operation |
2025-10-14 16:17:58 +0200 | <ski> | like, how in relational algebra, division of relations is useful to express queries of the form "for all ..., ..." |
2025-10-14 16:17:43 +0200 | inline | (~inlinE@ip-178-202-059-161.um47.pools.vodafone-ip.de) (Remote host closed the connection) |
2025-10-14 16:17:29 +0200 | <ski> | it might be useful to want a (lower approximation to) division, wrt this multiplication |
2025-10-14 16:17:29 +0200 | <tomsmeding> | hm, I guess subsets of a very small universe set could have the required very-non-injective property |
2025-10-14 16:17:08 +0200 | <tomsmeding> | yes I know that bags/sets are not quite free |
2025-10-14 16:16:47 +0200 | <ski> | yes |
2025-10-14 16:16:46 +0200 | <tomsmeding> | something which makes a datastructure grow quadratically in size is not something you use very often |
2025-10-14 16:16:23 +0200 | <tomsmeding> | furthermore, for this to be useful as an abstraction, I'd expect the operation to be used more than, say, once in a program |
2025-10-14 16:16:19 +0200 | <ski> | ((finite) bags are free *commutative* monoids. (finite) sets are free *commutative* *idempotent* monoids) |
2025-10-14 16:16:15 +0200 | luna___ | (~luna@fedora/bittin) () |
2025-10-14 16:15:31 +0200 | <ski> | mm, right, scratch the "lists" |
2025-10-14 16:15:12 +0200 | <tomsmeding> | even with Sum/Product the maps still grow quadratically |
2025-10-14 16:14:57 +0200 | <ski> | or `Sum a' or `Product a' |
2025-10-14 16:14:50 +0200 | <tomsmeding> | aren't those free and thus very injective? |
2025-10-14 16:14:29 +0200 | <ski> | like, the keys are lists, bags, or sets ? |
2025-10-14 16:14:01 +0200 | <ski> | unless the key monoid is highly non-injective, i guess |
2025-10-14 16:13:43 +0200 | <tomsmeding> | that's not usually what you want in practice |
2025-10-14 16:13:42 +0200 | <ski> | right |
2025-10-14 16:13:30 +0200 | <tomsmeding> | yes, the other problem is that the maps get very big this way |
2025-10-14 16:13:25 +0200 | <ski> | wanting all combinations of the keys in one map, with the keys in the other map |
2025-10-14 16:12:57 +0200 | <ski> | yea .. it kinda has a "tensor feel" |
2025-10-14 16:12:30 +0200 | <tomsmeding> | *originals |
2025-10-14 16:12:21 +0200 | <tomsmeding> | feels a bit far-fetched to me, not least because the result "invents new keys" that were not there in the original |
2025-10-14 16:10:58 +0200 | <ski> | now .. is there a use case for wanting to multiply `Map k v's, given `Monoid k' ? |
2025-10-14 16:09:47 +0200 | <ski> | so you can no longer keep track of a single element per group (monoid)) |
2025-10-14 16:09:41 +0200 | <ski> | the direct sum case involves a function, with *finite support*, from the family indices to elements of the corresponding groups (monoids), while for direct product, it's arbitrary such functions. for arbitrary (not necessarily commutative/abelian) groups (monoids), though, the categorical coproduct case (called "free product") becomes a larger object. `g_0 * h * g_1' is no longer equal to `(g_0 * g_1) * h', |
2025-10-14 16:09:35 +0200 | <ski> | (oh, and when i said "formal polynomial", above, i had "formal power series in mind" .. so wondering whether that would involve a cofree, rather than free, monoid. cf. how direct sum (categorical coproduct) and direct product (categorical product) for *commutative* groups (as well as monoids) coincide, for a *finite* family of groups (or monoids), but are distinct for an infinite family. difference is that |