On 02/12/2016 01:47 PM, Waldek Hebisch wrote: >> According to documentation of IndexedDirectProductCategory, >> elements of the respective domains must have finite support. > > I see nothing like this. In IndexedDirectProductObject there is > assumption that supports are finite, but category is more general. > Note: text between IndexedDirectProductCategory and > IndexedDirectProductObject applies to IndexedDirectProductObject.
Oh. OK, then I take it back. Sorry. >> In contrast, AbelianMonoidRing explicitly states that its elements >> need not have finite support, while MonoidRing claims finite >> support. > Again, I see no _explicit_ assumption of finite support in > MonoidRingCategory. That is true. From the software technical part, the assumption of finite support is unnecesary, I only argue that monoid ring is known by mathematicians to have finite support. If we use monoid ring also for infinite support, that would at least confuse the mathematicians among us. I'd rather say, let's make IndexedDirectProduct be the infinite support line and MonoidRing (or perhaps IndexedDirectSum) be the finite support line. Shouldn't we take the concepts from category theory? > There is some inconsistency, AbelianMonoidRing is a category while > MonoidRing is a domain and category is called MonoidRingCategory. That should certainly be corrected. I think Johannes Grabmeier recently made this comment. And he is listed as one of the authors of MonoidRingCategory. I think, we should rename MonoidRing --> ??? MonoidRingCategory --> MonoidRing >> Given that (https://en.wikipedia.org/wiki/Monoid_ring) a monoid >> ring is defined with element of finite support. I tend to change to >> that meaning in our Algebra library. Otherwise we confuse >> mathematicians. > > I do not thing so. While in algebra usually one assumes finite > support in other branches of math one uses more general functions. > And there is long tradition in math of generalizing definitions. At > first such generalized definition may use word 'generalized' but with > time it gets dropped... Well, of course, I can hardly argument against this opinion. I simply think that a monoid ring is a direct sum (coproduct), and that is an established concept. I've nothing against implementing in SPAD a category hierarchy for direct products. In fact, we already have IndexedDirectProductCategory. >> A monoid ring is more like a direct sum over the index set while I >> would more naturally think of elements of a direct product indexed >> by some set having infinite support. >> >> I'd rather think we should have >> >> IndexedDirectProductCategory with possibly infinite support, >> MonoidRing and AbelianMonoidRing with finite support. >> >> That means that FiniteMonoidRing should go away. > > AFAICS current MonoidRing and AbelianMonoidRing allowing infinite > support are fundamental. We will modify them, but the essence will > stay. So it looks that you want just to rename them. I think that > current names are actually quite good. And renaming means that > everybody using them must adjust to new names. This is pain, and for > that reason I tried to keep renaming to minimum. For MonoidRing see above. I wouldn't want to rename AbelianMonoidRing. I only want to make it explicit that a ...MonoidRing will have elements with finite support. So a function coefficients: % -> List Coef is known to always return a list and never an ërror. Yes, renaming is a pain, but FriCAS does not have millions of users. I think it's better to plan for something better now then later. We can postpone the renaming to later and first put in the release notes a warning that in an upcoming version some reanaming will happen. Ralf -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
