Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (nike.apache.org: local policy)
Date: Thu, 9 Feb 2012 13:09:05 +0100
From: Gilles Sadowski <gilles@harfang.homelinux.org>
To: dev@commons.apache.org
Subject: Re: [math] Are all FieldElement Numbers?
Message-ID: <20120209120905.GX26355@dusk.harfang.homelinux.org>
Mail-Followup-To: dev@commons.apache.org
References: 
 <CAGRH7HpTNydgqnSfvTRbnoaemi_UZtR+LvmAO5QaGFfTtdPcZQ@mail.gmail.com>
 <4F33999D.8060502@free.fr>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <4F33999D.8060502@free.fr>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-DCC-scarlet.be-Metrics: eir 20001; Body=1 Fuz1=1 Fuz2=1
X-Virus-Scanned: clamav-milter 0.97.1-exp at eir
X-Virus-Status: Clean
X-Virus-Checked: Checked by ClamAV on apache.org

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