commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Heinz Kredel <>
Subject Re: [Math] Proposal for a set of interoperable interfaces for mathematical structures
Date Sun, 29 Jan 2012 13:36:42 GMT
Am Mittwoch 25 Januar 2012, 19:13:25 schrieb Axel:
> To extend JAS with the commons-math methods the easiest way is to extend
> the
> edu.jas.structure.AbelianGroupElem like this:
> public interface AbelianGroupElem<C extends AbelianGroupElem<C>>
>          extends Element<C>, FieldElement<C>
> and add the methods:
> add() and
> getField() in all derived classes.
> But there's already an add() method in the AbelianGroupElem interface which
> is called sum().
> This is probably to avoid the method name add() which is often used in the
> Java Collection framework.
> (see

may be the names are not so important at the moment. I have given one reason 
for choosing sum() as name - some protection against my own stupidity. There 
may be other reasons to choose other names. For JAS I would not bother to 
change names in the current 2.4 release. My plan is to have such things/issues 
resolved and fixed for the 3.0 release.

There are other methods which we have to discuss, e.g. the toScript() method 
in Element. As far as I can see this method is useless in the current setting 
of ACMath. Only if ACMAth would have some interest/future plans to provide a 
scripting frontend to the library, for example like Octave or Scilab, it would 
make sense. So we must face the problem that not all methods are equally 
important for the different libraries. What we should have is a minimal set 
which provides the best interoperability and has enough mathematical methods 
to be useful. So continuing with Axels example we would have the following:

edu.jas.structure would be revised and go to org.apache.commons.math.structure 
(or what ever package ACMath sees fit). I would then restructure 
edu.jas.structure to extend the interfaces from 
org.apache.commons.math.structure and add interfaces as required. For example 

public interface Scripting {
   String toScript();

it would be in JAS

public interface RingElem<C extends RingElem<C>> extends 
   org.apache.commons.math.structure.RingElem, Scripting {

JAS has already some of such explicit return value interfaces, e.g. Rational, 
Modular and ModularRingfactory in edu.jas.arith. (It only makes reading of the 
class definition a bit more difficult.)

One can do similar extensions for missing methods for ACMath usage if 


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message