commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Barker" <billwbar...@verizon.net>
Subject Re: [Math] Package for "UnivariateRealFunction"s
Date Fri, 29 Oct 2010 07:55:27 GMT


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

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message