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