In private mail Ralf Hemmecke wrote about commot 1119:
> > > > Support polynomial rings over semirings.
> > >
> > > You cannot really mean that.
> > >
> > > I don't question that the construction is useful, but I question the
> > > naming of things.
> > >
> > > Now we have that an AbelianMonoidRing is no longer a Ring or rather is
> > > only a ring under certain contitions. I think that is confusing.
My reply:
> > My feeling is that this is within usual abuse of notation which is
> > common in mathematics (for example "simple Lie group" is not
> > necesserily a "simple group").
>
> I'm more in favour of avoiding such abuse in the context of computer
> algebra as much as possible.
>
> > What do you propose? AbelianMonoidSemiRing is heavy and still
> > somewhat inaccurate
>
> I've currently not yet exactly analysed what algebraic structure your
> new AbelianMonoidRing actually is (and thus I don't yet have a good name
> for it), but for any future changes I'd rather prefer that the name
> stands for a thing with the same meaning. I know that this is hard.
>
> But you have done a good job when you introduced SemiR(i)ng. You've
> simply added a new category in the middle of the hierarchy.
>
> For AbelianMonoidRing one could do the same. So let it be as it was
> before and introduce AbelianMonoidRingWaldek as a new category that now
> gets most of the functionality of AbelianMonoidRing (except the stuff
> that deals with Ring). Then AbelianMonoidRing would inherit from your
> new AbelianMonoidRingWaldek.
The point of change is every current user of AbelianMonoidRing
optionally gets new functionality: if user proviedes a Ring as
an argument that the category should be as before. If user
supplies it with a semiring, then one gets new behaviour.
In other words, if we introduce a new category we should
at the same time remove AbelianMonoidRing and replace
all uses of AbelianMonoidRing by the new category.
> > There is also problem of code stablity: we will from time to time
> > generalize various constructors.
>
> Yes that's a problem and should be done with great care. I'm not totally
> against such generalisations. But in the case of AbelianMonoidRing, I'd
> like to keep it a Ring.
This is not an option. Either AbelianMonoidRing will surrend its
ambition of always beeing a Ring or it will be exterminated.
As I wrote in the message about products I think that more exports
should be conditional. Spad compiler had problems with such
exports and this probably forced current form of algebra. But
now several problems with conditional exports are fixed and
we can use them.
> > If we keep changing names to accuratly reflect increased generalty,
> > then we will be forced to update rest of code to new names. This may
> > be significant burden for developers. For this reason AFAIK many
> > software project limit renaming.
>
> Introducing a new generalised constructor does not mean that old code
> has to be changed in any place. Only in such places where the new
> generalisation would be relevant.
Yes if new contructor just gets place between existing constructors
(like SemiRing). But not the in current case, where we want option
to generalize all users.
> Ralf
>
--
Waldek Hebisch
[email protected]
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/fricas-devel?hl=en.
