On 2/24/13 9:19 AM, Luc Maisonobe wrote: > 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.
+1 to commit what you have so we have something concrete to talk about. The reason I suggested just exp/ln is that this is what *defines* pow and exp is really what makes the exponential field. Phil > > 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
