commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <phil.ste...@gmail.com>
Subject Re: [math] Support for Abelian Groups and Rings?
Date Mon, 03 Oct 2011 16:50:32 GMT
2011/10/3 Sébastien Brisard <sebastien.brisard@m4x.org>:
> 2011/10/3 Phil Steitz <phil.steitz@gmail.com>:
>> 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).

Phil


> Thank you for trying to reason me...
> Sébastien
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message