commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luc Maisonobe <>
Subject Re: [math] discussing ebe like functions for MathArrays
Date Sun, 05 Jul 2015 18:31:39 GMT
Hi all,

Le 05/07/2015 19:12, Gilles a écrit :
> Hi.
> On Sun, 05 Jul 2015 07:20:30 -0700, Phil Steitz wrote:
>> On 7/5/15 12:44 AM, Luc Maisonobe wrote:
>>> Hi all,
>>> A few days ago, several pull requests arrived from github
>>> (<>,
>>> <>,
>>> <> and
>>> <>). They
>>> concern ebe-like functions for MathArrays.
>>> I was ready to commit them, but have second thoughts now. Wouldn't it
>>> be better to have rather an API like:
>>> f, double[] a)
>>> and
>>> f, double[] a, double[] b)
>>> It would avoid adding a bunch of functions.
>>> There were already concerns about inflating API in RealVector
>>> a few years ago and I would prefer not doing again the same errors.
>>> What do you think?
>> Two quick comments:
>> 1. +1 for general weight control. MathArrays has a big obesity
>> risk.  We used to try to limit it to things that are actually needed
>> inside [math] and sometimes I think it would be best to go back to
>> that rule.
> +1 to the principle that methods in "MathArrays" should
> 1. be confined to low-level utilities, and
> 2. not imply that Java arrays are Cartesian coordinates.

So I guess the three methods

  double[] map(final UnivariateFunction f, final double[] a)
  double[] map(final BivariateFunction f,
               final double[] a, final double[] b)
  double[] map(final BivariateFunction f,
               final double[] a, final double b)

are OK. I'll push my commit in a few minutes. It it doesn't fit
well, we can remove them afterwards.

> Even the "cosAngle" which I recently proposed should not be included
> (if we go that route), and existing such methods (like "distance")
> should be deprecated in favour of an abstraction that specifically
> represents such a geometric quantity.
> Use of more robust code could thus be enforced (cf. method "angle"
> in class "o.a.c.m.geometry.euclidean.threed.Vector3D").
> Also, isn't it a problem that we have a "general array" in "RealVector"
> (where the "map" method exists already) while that class also implicitly
> assumes that its elements are Cartesian coordinates?
> I think that we should review and correct this design flaw (there is
> a very old issue about that IIRC).
> A class "VectorND" (of arbitrary but fixed dimension) could be created
> in "o.a.c.m.geometry" and geometrical functionalities such as "distance"
> be defined there rather than in "RealVector" and "ArrayRealVector" (that
> are mutable) and/or in "MathArrays".
> [One potential problem is the performance issue (memory/speed): We should
> have benchmarks that answer the question of whether using "VectorND" is
> the "same" as using a Java raw array.]
>> 2.  I can't find it right now, but I vaguely recall earlier
>> discussion on the smelliness of the ebe methods.  Might be worth
>> looking through the archives.

Yes, this is what I did. There was a thread started about sparse vectors
in June 2012 <> and
another message in another thred in August 2011

> IIRC, it was also an argument in the discussions about cleaning up
> "RealVector" and "RealMatrix"?

Yes. The threads above were really related to linear algebra, not
MathArrays (which is a lower level IMHO).

What was said at that time is still true, and 4.0 is probably a good
opportunity to change this behaviour (I like Ted Dunning suggestion in
the 2011 thread about views). However, as always it needs times and it
seems none of us has time available now.

best regards,

> "ebe" is low level, so it's OK to have them in "MathArrays" (if they
> serve internally).  But they also exist in "RealVector" where it might,
> or might not, be OK depending on the concept defined by such a class
> (which is now a hybrid of "general array" and "Cartesian coordinates").
> Regards,
> Gilles
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message