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 <https://issues.apache.org/jira/browse/MATH-569>. 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, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
