commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <>
Subject Re: [math] Support for Abelian Groups and Rings?
Date Mon, 03 Oct 2011 16:50:32 GMT
2011/10/3 Sébastien Brisard <>:
> 2011/10/3 Phil Steitz <>:
>> On 10/3/11 7:00 AM, Sébastien Brisard wrote:
>>> Hello,
>>> I'm using quite extensively the Field/FieldElement interfaces, but am
>>> sometimes feeling the need for less stringent sets like Abelian Groups
>>> (no multiplication) and Rings (no division). This would allow me to
>>> carry out some calculations on different types of number simply by
>>> changing the generic type.
>>> I was thinking of adding some interfaces along the lines of the two
>>> above mentioned
>>>   - AbelianGroup<T>, AbelianGroupElement<T>,
>>>   - Ring<T>, RingElement<T>.
>>> Do you think that would be useful?
>> If you have practical applications, then OK; if this is just to have
>> more math abstractions, we have generally been conservative about
>> that (i.e., introduce the abstractions as we need them for practical
>> applications).  Can you describe a little the use cases?
>> Phil
> Hi Phil,
> The application I have in mind is the manipulation of Taylor
> expansions (stored as multivariate polynomials). I'm trying to use
> genericity in order to be able to work with different number
> representations (exact fractions, double values, etc...).
> From this point of view, it would be useful to be able to have a
> wrapper class for (for example) integers. However, this is not
> possible at the moment, since Z is only a ring.
> OK, I could go on, but honestly Phil, I think I won't be able to
> convince you. Indeed, if this feature existed, I would use it, but I
> must admit that I proposed it because I also find such a feature
> "beautiful" (which is not a very good reason for adding it to CM).
> What I'm going to do is implement those mathematical entities on my
> side, and try and use them. If I realize they could be useful to the
> core CM library, I'll raise this issue again later.

Sounds like a good plan.  Don't get me wrong - we added Field for the
same kinds of reasons (needed for some applications and code reuse).


> Thank you for trying to reason me...
> Sébastien
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message