commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <gil...@harfang.homelinux.org>
Subject Re: [Math][Numbers] Move Field, etc. to numbers?
Date Mon, 25 Dec 2017 01:40:23 GMT
On Sun, 24 Dec 2017 19:47:23 -0500, Raymond DeCampo wrote:
> On Sat, Dec 23, 2017 at 8:11 PM, Gilles 
> <gilles@harfang.homelinux.org>
> wrote:
>
>> On Sat, 23 Dec 2017 15:35:14 -0500, Raymond DeCampo wrote:
>>
>>> What would you do with FieldElement and in particular
>>> FieldElement.getField()?
>>>
>>
>> I was thinking of a new interface to represent the "field"
>> concept:
>> ---CUT---
>> /**
>>  * @param <T> Type of field element.
>>  */
>> public interface MathField<T> {
>>   T add(T a, T b);
>>   T multiply(T a, T b);
>>   // etc.
>>   T one();
>>   T zero();
>> }
>> ---CUT---
>> to contain all the field-defining methods.
>>
>> Some algorithm that can be defined on any field would be
>> instantiated with a reference to a "MathField":
>> ---CUT---
>> public class LinearCombination<T> {
>>   private MathField<T> field;
>>
>>   public LinearCombination<T>(MathField<T> field) {
>>     this.field = field;
>>   }
>>
>>   public T compute(T[] a, T[] b) {
>>     T result = field.zero();
>>     for (int i = 0; i < a.length; i++) {
>>       result = field.add(result, field.multiply(a[i], b[i]));
>>     }
>>     return result;class
>>   }
>> }
>> ---CUT---
>>
>> Does that make sense?
>>
>>
> Then we would have something like:
>
> public class FractionField implements MathField<Fraction> {
>
>     public Fraction add(Fraction a, Fraction b) {
>         return a.add(b);
>     }
>     // etc.
> }
>
> Maybe we should create a branch in either numbers

I'll do that.

> or CM

I'm overwhelmed by the number of changes needed in huge classes
such as "FieldMatrix" and "FieldVector". [And I feel that those
are misnomers...]

> (or both) to play
> with it and see how it goes?  But probably not until after the 
> holiday.

OK. Have a nice holidays.

>
> I'm still thinking it would be nice to have an interface which 
> Fraction,
> Complex, etc could implement allowing a base MathField 
> implementation:
>
> public abstract class AbstractMathField<T extends FieldElement> 
> implements
> MathField<T> {
>
>     public T add(T a, T b) {
>         return a.add(b);
>     }
>     // etc.
> }
>
> Then there would be less repeated boilerplate in MathField 
> implementations.

It is probably fine to have a "FieldElement" interface (in module
"commons-numbers-core"): apart from its "advanced" usage in tools
such as exist in CM, it could be seen, in "Numbers", as a way to
ensure consistent naming of the basic operators.

The "AbstractMathField" class can also contain code for a singleton
instance for each type of field.


Gilles


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


Mime
View raw message