Hi Phil, Le 24/02/2013 18:03, Phil Steitz a écrit : > 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.
Well, I already have all methods: exp, expm1, log, log1p, sin, cos, tan, asin, acos, atan, atan2, the hyperbolic counterparts, pow with different types like double and int, linear combinations ... In my use case, I really need the trigonometric functions. I have added the necessary methods so that Decimal64, Dfp and DerivativeStructures implement the interface. One caveat was that Dfp already had a log10 method that returned an int, which was incompatible with returning a ExtendedField. So I changed the name original method of Dfp to be intlog10. This is an incompatibility, but I don't think it will create any problem so I think we could accept it. I have also replaced my recent Vector3DDS and RotationDS with FieldVector3D<ExtendedField> and Rotation<ExtendedField>. Everything runs smoothly. I propose to commit what I have in my workspace so we can review it together and see how we split the interface into the layers you propose, as I'm not sure I understand the global layout you think about. Splitting an interface in several layers is trivial. best regards, Luc > > 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
