commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sébastien Brisard <sebastien.bris...@m4x.org>
Subject Re: [math] Are all FieldElement Numbers?
Date Thu, 09 Feb 2012 10:18:43 GMT
Hi Luc,
>
> 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.
>
Ooops, I missed that

>
> 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.
>
That's exactly the reason why I use FieldElement (in my case :
multipole expansions).

>
> 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.
>
Also agreed. Interfacing with JAS would be an option (see recent
posts). Maybe in the (not so near) future 5.0, 6.0 ;) ?

>
> 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
>
I see your point and was going to suggest that we only add a
doubleValue() method to the interface FieldElement. But that does not
work with Complex!
So I'll have to think of something else...
Sébastien


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message