commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luc Maisonobe <Luc.Maison...@free.fr>
Subject Re: [math] extension to FieldElement
Date Sun, 24 Feb 2013 17:19:26 GMT
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-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message