commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <>
Subject Re: [math] Are all FieldElement Numbers?
Date Thu, 09 Feb 2012 12:56:52 GMT
On 9 February 2012 10:02, 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 this is vital design information, which should be added to the
class documentation.

> Luc
>> * 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:

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

View raw message