Le 27/10/2010 12:46, Gilles Sadowski a écrit :
> 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);
> }
> }
> ---CUT---
+1
>
> 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.]
+1
> 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:
>
> 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---
These functions where a request from a user, but I agree they are quite
cumbersome, so also +1 here.
>
> 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.
-0, I don't see much added value to specific functions implementations.
In many cases, the functions for real world problem are specific whereas
the functions in unit tests are really basic and not reusable.
Luc
>
>
> 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
