luc.maisonobe@free.fr wrote:
>  "Bill Barker" <billwbarker@verizon.net> a écrit :
>
>
>>  Original Message 
>> From: "Phil Steitz" <phil.steitz@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.maisonobe@free.fr wrote:
>>>
>>>>  "Bill Barker" <wbarker@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 algebratainted 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 applicationsdriven 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 cm 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,
>>>>
>> MATH172). 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, email: devunsubscribe@commons.apache.org
>>>>> For additional commands, email: devhelp@commons.apache.org
>>>>>
>>>>>
>>>>
>> 
>>
>>>> To unsubscribe, email: devunsubscribe@commons.apache.org
>>>> For additional commands, email: devhelp@commons.apache.org
>>>>
>>>>
>>>>
>>>
>>>
>> 
>>
>>> To unsubscribe, email: devunsubscribe@commons.apache.org
>>> For additional commands, email: devhelp@commons.apache.org
>>>
>>>
>>>
>> 
>> To unsubscribe, email: devunsubscribe@commons.apache.org
>> For additional commands, email: devhelp@commons.apache.org
>>
>
> 
> To unsubscribe, email: devunsubscribe@commons.apache.org
> For additional commands, email: devhelp@commons.apache.org
>
>

To unsubscribe, email: devunsubscribe@commons.apache.org
For additional commands, email: devhelp@commons.apache.org
