commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luc Maisonobe <>
Subject Re: [math] Are all FieldElement Numbers?
Date Thu, 09 Feb 2012 10:02:05 GMT
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 ?


> * Alternatively, may I introduce a NumberFieldElement which extends
> both Number and FieldElement? In this case, I would recommend that
> BigFraction, BigReal, Complex, Dfp, DfpDec, Fraction all implement
> this interface (which does not change anything, actually).
> Thanks for your feedback!
> Sébastien
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message