2011/10/3 Sébastien Brisard <sebastien.bris...@m4x.org>: > 2011/10/3 Phil Steitz <phil.ste...@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-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
