"Phil Steitz" <phil.ste...@gmail.com> wrote in message news:49f320bc.1000...@gmail.com... > 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 >> ? >>
Yes, happy to help. But would like comments on my latest copy/paste implementation. Reading over it again, there should be an AbstractIntHashMap class that does the duplicated code. But if you are planning to release soon, that could be pushed to v2.1. In any case SparseFieldMatrix and SparseFieldVector don't depend on the implementation details of OpenToFieldHashMap, so I can start on those. > +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
