On 2/24/13 1:42 AM, Luc Maisonobe wrote: > Hi all, > > I would like to go back to some discussions we had a while ago: adding > some operations on FieldElement. There was one discussion on the dev > list one year ago (see > <http://commons.markmail.org/thread/lokbafadi2uwin2n>) and a JIRA issue > two years ago (see <https://issues.apache.org/jira/browse/MATH-569>). > > Since that time, we have added at least one new Field/FieldElement > implementation: DerivativeStructure. This one has the same domain of > definition as Dfp, i.e. it mimics real numbers only. It already does > implement all operations, including sqrt (returning NaNs when applied to > negative numbers for example). > > I already needs this kind of objects for 3D vectors and rotations. You > may have noticed I implemented them specifically for > DerivativeStructure, but I think it would make more sense to implemenbt > it as Vector3D<T extend ExtendedField> so we could have both an > implementation using DerivativeStructure and an implementation using Dfp. > > In fact, I think we could later on even add the missing methods to the > Complex class so it could also implement this interface, which would be > closer to the other needs that appeared at least twice on the project. > > At the time the issues were raised, it seems we decided to not implement > this because of lack of time and lack of complete use cases among > Complex. Now we have at least another use case (geometry needs for me), > and most of the work is already available (implementation of these > geometry needs for DerivativeStructure only, with a full test suite with > 100% line coverage). So It may be worth extracting the interface from > DerivativeStructure. After that, adding the methods to the other Field > classes could be done progressively (Dfp would be the first one to > follow, and would be quite simple as almost everything is already > available in the companion class DfpMath). > > What do you think?
I am OK with this as long as the new thing is called "ExtendedField." I assume that the real additions you are talking about are pow and sqrt. The first really says the field is exponentially closed and the second is part of algebraic closure. Two things we might think about, which don't appear to be required by immediate applications are: 0) for pow, add exp (and inverse) explicitly. Call the result of this addition ExponentialField. 1) for sqrt, generalize to nth roots or even go all the way to algebraic closure, yielding AlgebraicallyClosedField. Looking at Complex as a use case, nth roots would definitely be more useful than just sqrt. Extending solvers to handle complex polynomials would be a fair amount of work, so I would say hold off on AlgebraicallyClosedField until we have use cases (and patches) for that. I can't think of immediate uses for ExponentialField by itself for now, so I would also hold off on that and just do ExtendedField. Therefore, I am +1 for ExtendedField, adding pow, exp, ln (or maybe expInverse), root(int n) or nthRoot (would this be hard in DerivativeStructure?). If it is too much work / seems unnecessary to add anything beyond pow, sqrt, I am OK with adding just these to the interface as well. 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
