commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles Sadowski <>
Subject Re: [math] Are all FieldElement Numbers?
Date Thu, 09 Feb 2012 12:09:05 GMT
On Thu, Feb 09, 2012 at 11:02:05AM +0100, Luc Maisonobe wrote:
> Le 09/02/2012 10:15, Sébastien Brisard a écrit :
> > Hi,
> Hi Sébastien,
> > I'm doing some calculations with FieldElement, and need at the end to
> > convert the result to double. I notice that in the current CM, all
> > classes that implement FieldElement also implement Number, which would
> > be exactly what I need. My question therefore is
> > * Should we have the interface FieldElement extend Number? I know we
> > could think of fields which are *not* numbers, but we are, after all,
> > a project dedicated to numerical computations...
> Yes, all FieldElement are expected to be numbers, or at least there is
> an homomorphism mapping the elements to numbers. However, FieldElement
> cannot implement Number because number is a class, not an interface. If
> we want to have this hierarchy, we also have to change FieldElement to
> an abstract class.
> This interface was introduced in order to have one common ancestor
> between Fraction and BigReal. This common ancestor then allowed
> trivially to support some important linear algebra algorithms on
> fractions by just slightly adapting what did exist for BigReal.
> Typically, we needed an LU factorization on fraction-based matrices to
> compute exactly some coefficients in various other algorithms (think
> high order approximation, derivatives ...). Field just seemed the right
> name because we really needed only the basic field operations.
> This interface was not intended as a step towards complete algebra
> support. There have been some questions about that, but we chose to not
> go this way (at that time), as we still have very limited resources. We
> do not have Group, AbelianGroup or Ring interfaces for example.
> There was also a Jira issue about adding more operations (typically
> sqrt, which would for example allow support for Cholesky decomposition).
> See <>. This would clearly
> imply at least one additional interface level since for example sqrt is
> not an internal operation for fractions. We finally decided not to
> implement this, as the initial need was limited to Complex only.
> I am slightly reluctant to change FieldElement to an abstract class.
> What do other people think  about this ?

I think that we should think about it... Later. ;-)


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

View raw message