On Sun, 24 Dec 2017 19:47:23 -0500, Raymond DeCampo wrote:
On Sat, Dec 23, 2017 at 8:11 PM, Gilles
<gil...@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-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
