On 9 February 2012 10:02, Luc Maisonobe <luc.maison...@free.fr> 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 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: 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
