Newest at the top
| 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 |
| 2025-10-14 16:08:42 +0200 | MelodyOwO | (~MelodyOwO@user/MelodyOwO) (Quit: Leaving.) |
| 2025-10-14 16:07:48 +0200 | inline | (~inlinE@ip-178-202-059-161.um47.pools.vodafone-ip.de) Inline |
| 2025-10-14 16:07:18 +0200 | inline | (~inlinE@ip-178-202-059-142.um47.pools.vodafone-ip.de) (Ping timeout: 252 seconds) |
| 2025-10-14 16:06:35 +0200 | <tomsmeding> | then the structure of the monoid suddenly comes into play |
| 2025-10-14 16:06:11 +0200 | <tomsmeding> | but yeah I see where my understanding went wrong: I wasn't properly thinking about the fact that this R[G] is supposed to be a _ring_, and what the multiplication operation ought to do |
| 2025-10-14 16:05:05 +0200 | <tomsmeding> | polynomials on Z/2Z have a bunch of such "redundancies" |
| 2025-10-14 16:02:37 +0200 | fp | (~Thunderbi@2001:708:20:1406::10c5) (Ping timeout: 246 seconds) |
| 2025-10-14 16:02:33 +0200 | <ski> | (iirc, in some rings, (ordinary) polynomials can be distinct (having distinct coefficients), while still having the same value at each possible input (being extensionally equal, the corresponding functions to the polynomials being equal)) |
| 2025-10-14 16:01:19 +0200 | <ski> | the "formal" here means that when we write a (finite) sum of products of monoid elements and associated coefficients, this is just a suggestive notation for having a function from the monoid elements to the coefficients, with "finite support" (meaning only finitely many monoid elements map to non-zero coefficients) |
| 2025-10-14 15:59:36 +0200 | <tomsmeding> | thanks :) |