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] discussing ebe like functions for MathArrays
Date Sun, 05 Jul 2015 17:12:27 GMT
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
>> (<https://github.com/apache/commons-math/pull/6>,
>> <https://github.com/apache/commons-math/pull/7>,
>> <https://github.com/apache/commons-math/pull/8> and
>> <https://github.com/apache/commons-math/pull/9>). 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:
>>
>>   MathArrays.map(UnivariateFunction f, double[] a)
>>
>> and
>>
>>   MathArrays.map(BivariateFunction 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.

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.

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

"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: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message