On 2/24/13 9:03 AM, Phil Steitz wrote: > 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.
Doh! I forgot we added that a few years back ;) So making *this* the interface method saves work there ;) > 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
