--------------------------------------------------
From: "Gilles Sadowski" <gil...@harfang.homelinux.org>
Sent: Wednesday, October 27, 2010 3:46 AM
To: <dev@commons.apache.org>
Subject: [Math] Package for "UnivariateRealFunction"s
Hi.
What do you think of creating a "function" package that would contain all
the usual functions as classes implementing the "UnivariateRealFunction"
interface? I.e. for example:
---CUT---
package org.apache.commons.math.function;
import org.apache.commons.math.util.FastMath;
public class Cos implements UnivariateRealFunction {
public double value(double x) {
return FastMath.cos(x);
}
}
+1
---CUT---
In the above, there is also a hidden request: I would like to remove the
checked "FunctionEvaluationException" from the interface. As mentioned
recently in a [VFS] thread, the only argument in favor of checked
exceptions
is in situations where the code really implements local retries. What
would
you retry here? [If the answer is "Another value for the parameter x",
that
would just mean that we should instead throw an "IllegalArgumentException"
for the x that lead to failure.]
This will hugely simplify user (and CM) code.
I will create a new (unchecked) "FunctionEvaluationException" in package
"exception" so that current users of the exception would just have to do a
global search and replace:
I'm -0 on having it unchecked. But as long as it is documented in the
javadocs, I don't have a problem. Unlike {VFS}, it is more likely that
[math] users want to catch and handle something like sqrt(-1). I'd be -1 to
removing the exception all together, since it is a major pain to try and
figure out why you got a NaN value when debugging your code.
import org.apache.commons.math.FunctionEvaluationException
--> import org.apache.commons.math.exception.FunctionEvaluationException
And their existing try/catch blocks will continue to work seamlessly.
Coming back to the first issue, the advantage of having function objects
is
that, for example, we could remove quite some repetitive code in the
interface "RealVector" and its "ArrayRealVector" implementation: All the
"map...ToSelf" methods could be reduced to:
---CUT---
public ArrayRealVector mapToSelf(UnivariateRealFunction f) {
for (int i = 0; i < data.length; i++) {
data[i] = f.value(data[i]);
}
return this;
}
---CUT---
+1, that one never got cleaned up
We could also move all the already existing function objects used in the
unit tests; after all, they might be useful for CM users for devising the
unit tests for their own code.
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
