QuoteOriginally posted by: outrunhereQuoteQuantiletemplate <class RealType, class Policy>RealType quantile(const Distribution-Type<RealType, Policy>& dist, const RealType& p);The quantile is best viewed as the inverse of the Cumulative Distribution Function, it returns a value x such that cdf(dist, x) == p.This is also known as the percent point function, or percentile, or fractile, it is also the same as calculating the lower critical value of a distribution.This function returns a domain_error if the probability lies outside [0,1]. The function may return an overflow_error if there is no finite value that has the specified probability.This last statement should be revise to the open interval (0,1)? Because when p = 1 erf_inv gives overflow.

QuoteCould you share with me some of the code you use Cuchulainn? So that I could analyse how the accuracy evolves on them, and how I can improve it.No problem. Here is the code to compute quantiles based on Banach fixed point and Newton-Raphson. You can compile and stress test it The objective is to get numbers.

Here's quantile Boost odeint vs Boost Math

In some code they demand p is in the open interval (0,1). If that's the contract then OK.

Hi,thanks a lot for all of this, I start to analyze this ASAP !

QuoteOriginally posted by: ioualalenHi,thanks a lot for all of this, I start to analyze this ASAP !You're welcome :)In one file I also have multiprecision type as well. Let me know if you find any gems or potholes

QuoteOriginally posted by: CuchulainnIn some code they demand p is in the open interval (0,1). If that's the contract then OK.Just out of curiosity, is this open interval constraint and internal test robust with respect to denormal/subnormal floating point values? It looks like various compiler options might force a denormal number to zero which would successfully be caught by the test. But what about extremely small numbers that might be non-zero at first but then reduced into the denormal range by some internal math operation?

QuoteOriginally posted by: Traden4AlphaQuoteOriginally posted by: CuchulainnIn some code they demand p is in the open interval (0,1). If that's the contract then OK.Just out of curiosity, is this open interval constraint and internal test robust with respect to denormal/subnormal floating point values? It looks like various compiler options might force a denormal number to zero which would successfully be caught by the test. But what about extremely small numbers that might be non-zero at first but then reduced into the denormal range by some internal math operation?Not sure. Could be any one of QuoteError: ?A difference?between a computed result and the correct result?Fault: ?An incorrect step, process, or data definition in a computer program?Failure: ?The [incorrect] result of a fault?Mistake: ?A human action that produces an incorrect result?

QuoteOriginally posted by: CuchulainnQuoteOriginally posted by: Traden4AlphaQuoteOriginally posted by: CuchulainnIn some code they demand p is in the open interval (0,1). If that's the contract then OK.Just out of curiosity, is this open interval constraint and internal test robust with respect to denormal/subnormal floating point values? It looks like various compiler options might force a denormal number to zero which would successfully be caught by the test. But what about extremely small numbers that might be non-zero at first but then reduced into the denormal range by some internal math operation?Not sure. Could be any one of QuoteError: ?A difference?between a computed result and the correct result?Fault: ?An incorrect step, process, or data definition in a computer program?Failure: ?The [incorrect] result of a fault?Mistake: ?A human action that produces an incorrect result?Well at least normal operation has been ruled out, what?

QuoteOriginally posted by: Traden4AlphaQuoteOriginally posted by: CuchulainnQuoteOriginally posted by: Traden4AlphaQuoteOriginally posted by: CuchulainnIn some code they demand p is in the open interval (0,1). If that's the contract then OK.Just out of curiosity, is this open interval constraint and internal test robust with respect to denormal/subnormal floating point values? It looks like various compiler options might force a denormal number to zero which would successfully be caught by the test. But what about extremely small numbers that might be non-zero at first but then reduced into the denormal range by some internal math operation?Not sure. Could be any one of QuoteError: ?A difference?between a computed result and the correct result?Fault: ?An incorrect step, process, or data definition in a computer program?Failure: ?The [incorrect] result of a fault?Mistake: ?A human action that produces an incorrect result?Well at least normal operation has been ruled out, what?At least we know where we stand. Action is needed in the software contract. It boils down to deciding how to represent mathematical infinity in floating point and letting the client know. It's kind of tricky.

QuoteOriginally posted by: CuchulainnQuoteOriginally posted by: Traden4AlphaQuoteOriginally posted by: CuchulainnQuoteOriginally posted by: Traden4AlphaQuoteOriginally posted by: CuchulainnIn some code they demand p is in the open interval (0,1). If that's the contract then OK.Just out of curiosity, is this open interval constraint and internal test robust with respect to denormal/subnormal floating point values? It looks like various compiler options might force a denormal number to zero which would successfully be caught by the test. But what about extremely small numbers that might be non-zero at first but then reduced into the denormal range by some internal math operation?Not sure. Could be any one of QuoteError: ?A difference?between a computed result and the correct result?Fault: ?An incorrect step, process, or data definition in a computer program?Failure: ?The [incorrect] result of a fault?Mistake: ?A human action that produces an incorrect result?Well at least normal operation has been ruled out, what?At least we know where we stand. Action is needed in the software contract. It boils down to deciding how to represent mathematical infinity in floating point and letting the client know. It's kind of tricky.It's not just the representation of infinity but also the representation of near-zero numbers. In fact, there's at least three categories of gaps in which fixed-bit floating point numbers fail to encode underlying real numbers: 1) the large number to infinity gap; 2) the tiny number near zero gap; and the 3) successive float machine epsilon gap.

Here's quantile boundary checking; sounds kind of logical I suppose (?)