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/MATH569>).
>>
>> 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, email: devunsubscribe@commons.apache.org
>> For additional commands, email: devhelp@commons.apache.org
>>
>>
>
>
> 
> To unsubscribe, email: devunsubscribe@commons.apache.org
> For additional commands, email: devhelp@commons.apache.org
>
>

To unsubscribe, email: devunsubscribe@commons.apache.org
For additional commands, email: devhelp@commons.apache.org
