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 ? 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: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
