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 fractionbased 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 <https://issues.apache.org/jira/browse/MATH569>. 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. ;)
Best,
Gilles

To unsubscribe, email: devunsubscribe@commons.apache.org
For additional commands, email: devhelp@commons.apache.org
