commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Barker" <>
Subject Re: [math] Questions on Field
Date Sat, 25 Apr 2009 02:21:50 GMT

----- Original Message ----- 
From: "Phil Steitz" <>
To: "Commons Developers List" <>
Sent: Friday, April 24, 2009 6:02 PM
Subject: Re: [math] Questions on Field

> wrote:
>> ----- "Bill Barker" <> 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 

>>> 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:
>>> For additional commands, e-mail:
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message