----- Original Message -----
From: "Phil Steitz" <phil.ste...@gmail.com>
To: "Commons Developers List" <dev@commons.apache.org>
Sent: Friday, April 24, 2009 6:02 PM
Subject: Re: [math] Questions on Field
luc.maison...@free.fr wrote:
----- "Bill Barker" <wbar...@wilshire.com> a écrit :
I've been looking over the Field<T> implementations, and it looks like
it's mostly done except for FieldPolynomial<T>. I'm not really sure
which
SparseFieldMatrix and SparseFieldVector are also missing for now.
package this should go in, since o.a.c.m.analysis.polynomial seems to
be about Real polynomials. Any hints would be appreciated.
I'm not sure either.
I wonder if an algebra package would make sense or not. If so, it could
contain the Field top interfaces as well as field polynomials, Z/pZ,
rational functions and BigReal. If such an algebra were created I think
polynomials should be moved there.
Polynomials (and rational functions) are at the boundary between algebra
and analysis, at least when using double coefficients only. When using
Field coefficients, they are more algebra-tainted to me.
What do other people think about this ?
I agree that we could go in this direction and certainly polynomials over
arbitrary fields are algebraic objects, so an algebra package would make
sense if we do this. Building all of this out, however, is sort of a
slippery slope that leads away from an applications-driven applied math
library into a more abstract framework. I have always maintained that we
should introduce mathematical abstractions as we need them, with "need"
driven by applied math problems that we and our users have to solve. So
here I would ask, what applied problems are we trying to solve and what
additional algebraic structure do we need to solve them? I am not pushing
back here, just wanting to understand what applications people have in
mind.
I, personally, have no use for it. The main use case I could see is for
somebody that wants to use c-m to implement elliptic curve crypto (or higher
dimension variants). And this would only be for Z/pZ or finite extentions
of it. So I'm happy with waiting until there is a Jira issue requesting
this.
I could provide implementations for SimplePrimeFieldElement
(representing Z/pZ), and even SimplePadicFieldElement (with a
representation similar
to double). Not certain that it is useful for 2.0 without greatly
delaying the release. Most algebraist want to use finite extensions as
well.
I would really like to see 2.0 be published as soon as possible, but even
my own tasks keep being delayed (ODE for stiff equations, MATH-172). I
would like to target a release near end of May.
+1 - I would really like to get 2.0 out. I should have my stuff wrapped
up in the next couple of weeks.
Phil
Luc
---------------------------------------------------------------------
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
