Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sums and products over arbitrary finite types #1367

Open
wants to merge 33 commits into
base: master
Choose a base branch
from

Conversation

lowasser
Copy link
Contributor

In preparation for polynomials and formal power series, most notably multiplication of formal power series (#1357), this starts digging into sums over arbitrary finite types, and generalizes from sums on e.g. semirings to products on monoids -- mostly commutative monoids, since they're the ones where arbitrary finite sums make sense.

There is some tension with naming over whether group-theory.products-monoids should indicate the monoid on the Cartesian product of two other monoids, or products of elements in a monoid. Since monoids (and groups in general) use multiplicative terminology, we can't get away with what rings have done by differentiating sums and products. (And we don't have any support for products of elements of rings, either, though the generalization to commutative monoids is intended to make that possible down the road.)

This is marked a draft because there's one last thing I want to prove, which is that you can split sums over coproducts of arbitrary finite types.

@lowasser lowasser marked this pull request as ready for review March 17, 2025 01:17
@fredrik-bakke
Copy link
Collaborator

fredrik-bakke commented Mar 17, 2025

There is some tension with naming over whether group-theory.products-monoids should indicate the monoid on the Cartesian product of two other monoids, or products of elements in a monoid. Since monoids (and groups in general) use multiplicative terminology, we can't get away with what rings have done by differentiating sums and products. (And we don't have any support for products of elements of rings, either, though the generalization to commutative monoids is intended to make that possible down the road.)

Some patterns we've used elsewhere to differentiate are the following:

  1. In foundation we use "cartesian product" for the construction taking the cartesian product of two (underlying carrier) types.
  2. In category-theory we write "products of categories" and "products in categories" to distinguish between two notions of product (*although both are about products of objects in some category, not about multiplication operations in your sense).
  3. For Minkowski products we used "Minkowski multiplication" to disambiguate from products of carrier types.

Depending on the generality of the relevant binary operation (i.e., is it associative, does it distribute over the underlying binary operation?), you might want to go with simply "binary operations on monoids", or something other than "product".

@fredrik-bakke
Copy link
Collaborator

I think "cartesian product" may be appropriate in this setting, to disambiguate from the "free product of monoids" which, perhaps counterintuitively, is the coproduct in the category of monoids.

@lowasser
Copy link
Contributor Author

FWIW, I discovered that a very early attempt at the precise operation we want already existed in group-theory.products-of-tuples-of-elements-commutative-monoids.lagda.md. I have moved all the logic there and adopted the existing naming conventions there.

@fredrik-bakke
Copy link
Collaborator

Hmm, I suppose actually our linear-algebra namespace is better described as finite-dimensional-linear-algebra, since that is all it supports! The more general concept of a module over a ring, which allows for vectors in arbitrary dimensions, can be found in ring-theory for instance.

@fredrik-bakke
Copy link
Collaborator

I suppose, in computer science, the term "vector" is used for a list of a specified finite length, but this conflicts with the mathematical concept of a vector as an element of a vector space. Anyways, these are just random thoughts.

snoc-functional-vec-Monoid = snoc-functional-vec
```

### Zero vector on a ring
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Neither terminology "zero" nor "unit" vector works here, since you've adopted the multiplicative terminology for this file.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually -- perhaps we should name this the one vector? That isn't nearly so overloaded.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's also a possibility

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants