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.
Can you give an illustrating use case where your generalization is
important? What did you have in mind when you made this generalization?
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.
Of course, we could do that, but I find AbelianMonoidRing a rather
important category that deserves its own existence. Yes, it is always
questionable how to construct a good category hierarchy. In my opinion,
we should simply take established mathematical structures and try to map
them into the FriCAS category hierarchy. We anyway have already a
problem that usually mathematical concepts do not always map well into a
computational (i.e. constructive) context.
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.
I don't really understand what you want to say by this. As I said. I
want AbelianMonoidRing to always be a Ring.
As I wrote in the message about products I think that more exports
should be conditional.
Waldek, can you give a pointer? I don't really know what you are
referring to.
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.
I've nothing against conditional exports, but I also think that they are
not always well designed.
Look at
if R has CharacteristicZero then CharacteristicZero
if R has CharacteristicNonZero then CharacteristicNonZero
It's unfortunate that one must have two categories. But OK, it's a
different issue.
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.
I really don't see a benefit if AbelianMonoidRing loses the Ring
property. I'd be much more favor of introducing a new generalised
category and change all occurences of AbelianMonoidRing to this new name
if the generalisation is relevant.
But again, what idea did you have in mind and what is the corresponding
mathematical concept for your new AbelianMonoidRing? In which context is
it used?
Ralf
--
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.
