----- Original Message -----
From: "Phil Steitz"
To: "Commons Developers List"
Sent: Friday, April 24, 2009 6:02 PM
Subject: Re: [math] Questions on Field
> luc.maisonobe@free.fr wrote:
>> ----- "Bill Barker" a écrit :
>>
>>
>>> I've been looking over the Field implementations, and it looks like
>>> it's mostly done except for FieldPolynomial. 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-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org