Le 27/01/2012 13:55, Sébastien Brisard a écrit :
> Hi
>>
>> It thus becomes urgent to tackle the remaining blocking issues.
>> Can we please make a list of those, and of all practical matters that
>> prevent the preparation of the release?
>>
>
> MATH-731 is pretty much solved, but I still need a piece of advice.
> Let me explain : the triangular distribution is so simple that
> explicit formula have been implemented for
> inverseCumulativeProbability(double) (see below).
>
> {code}
> public double inverseCumulativeProbability(double p)
> throws OutOfRangeException {
> if (p < 0.0 || p > 1.0) {
> throw new OutOfRangeException(p, 0, 1);
> }
> if (p == 0.0) {
> return a;
> }
> if (p == 1.0) {
> return b;
> }
> final double pc = (c - a) / (b - a);
> if (p == pc) {
> return c;
> }
> if (p < pc) {
> return a + FastMath.sqrt(p * (b - a) * (c - a));
> }
> return b - FastMath.sqrt((1 - p) * (b - a) * (b - c));
> }
> {code}
>
> My problem is that I do not know what getSolverAbsoluteAccuracy()
> should return. I see three options
> 1. Have getSolverAbsoluteAccuracy() throw an
> UnsupportedOperationException, as the solver is *never* invoked.
> 2. Return a default value, and specify in the Javadoc that it is
> meaningless or not really meaningful ;).
> 3. Return an estimate of the absolute accuracy of the explicit above
> expressions, namely a + FastMath.sqrt(p * (b - a) * (c - a)) and b -
> FastMath.sqrt((1 - p) * (b - a) * (b - c)).
>
> My preferred option is 1. I dislike option 2, because users might
> actually be using the returned value, believing it to somehow reflect
> the accuracy of the value returned by
> inverseCumulativeProbability(double). Option 3 would be a good
> compromise, but I certainly do not have the level of expertise to come
> up with this estimate... Any help would be most welcome!
I don't like UnsupportedOperationException. In this case, I would say
the explicit formula is some kind of "perfect" solver which has a
theoretical accuracy of zero (or 1 ulp). So I would return this value.
Luc
>
> What do you think?
> Sébastien
>
>
> ---------------------------------------------------------------------
> 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
