luc.maison...@free.fr wrote:
----- "Bill Barker" <billwbar...@verizon.net> a écrit :
----- 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.
OK. So we wait before adding new fields.
I created the first implementations to address some problems I have with ODE: I
need to solve linear systems involving only rational numbers to compute some
coefficients very accurately. I also wanted to replace the old BigMatrix with
something more consistent with the new linear package. So I think it is
interesting to finish this work on linear algebra and add the SparseFieldMatrix
and SparseFieldVector classes.
Do you agree with this and would Bill accept to give an hand on this work ?
+1 - like I said not pushing back and I understand why you did what you
with Field and that is consistent with what I meant.
Phil
Luc
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
---------------------------------------------------------------------
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
