- Cuchulainn
**Posts:**64669**Joined:****Location:**Drosophila melanogaster-
**Contact:**

QuoteOriginally posted by: outrunThat's indeed a good solution.In C++11 this is also available in stdIf it's performance critical then you can use a branch free (no if statement) using this:QuoteIf the source type is bool, the value false is converted to zero and the value true is converted to one.So "return (x<0);" is all you need in the body!Yes, it's the Boost Maths quantile code from John M. Quotereturn (x<0)We lose the mathematical subtleties with this unreadable code; semantically it could mean anything. It is a harmful 'optimisation'. IMO

Last edited by Cuchulainn on December 21st, 2015, 11:00 pm, edited 1 time in total.

"Compatibility means deliberately repeating other people's mistakes."

David Wheeler

http://www.datasimfinancial.com

http://www.datasim.nl

David Wheeler

http://www.datasimfinancial.com

http://www.datasim.nl

- Traden4Alpha
**Posts:**23951**Joined:**

QuoteOriginally posted by: CuchulainnHere's quantile boundary checking; sounds kind of logical I suppose (?)Does Boost distinguish between numerical infinity (i.e., numbers too large to represent in the chosen floating point format) and analytic infinity (i.e., a true infinity)?In the case of heavy-tailed distributions (e.g., the Cauchy distribution), some numerical infinity values might correspond to a non-zero values of the CDF complement.

- Cuchulainn
**Posts:**64669**Joined:****Location:**Drosophila melanogaster-
**Contact:**

QuoteOriginally posted by: Traden4AlphaQuoteOriginally posted by: CuchulainnHere's quantile boundary checking; sounds kind of logical I suppose (?)Does Boost distinguish between numerical infinity (i.e., numbers too large to represent in the chosen floating point format) and analytic infinity (i.e., a true infinity)?In the case of heavy-tailed distributions (e.g., the Cauchy distribution), some numerical infinity values might correspond to a non-zero values of the CDF complement.Indeed.I had a look at Boost Cauchy: an overflow occurs when p = 0,1. Otherwise the quantile return a std::tan(...) (AFAIR the std trigos functions do not throw exception).So we need to know if the return type is an approximation to math infinity or if it is a "spurious" infinity?

"Compatibility means deliberately repeating other people's mistakes."

David Wheeler

http://www.datasimfinancial.com

http://www.datasim.nl

David Wheeler

http://www.datasimfinancial.com

http://www.datasim.nl

- Traden4Alpha
**Posts:**23951**Joined:**

QuoteOriginally posted by: CuchulainnQuoteOriginally posted by: Traden4AlphaQuoteOriginally posted by: CuchulainnHere's quantile boundary checking; sounds kind of logical I suppose (?)Does Boost distinguish between numerical infinity (i.e., numbers too large to represent in the chosen floating point format) and analytic infinity (i.e., a true infinity)?In the case of heavy-tailed distributions (e.g., the Cauchy distribution), some numerical infinity values might correspond to a non-zero values of the CDF complement.Indeed.I had a look at Boost Cauchy: an overflow occurs when p = 0,1. Otherwise the quantile return a std::tan(...) (AFAIR the std trigos functions do not throw exception).So we need to know if the return type is an approximation to math infinity or if it is a "spurious" infinity?Maybe. It depends on whether programmers are using infinity as a specific logical mathematical condition (i.e., the symbolic evaluation of the algorithm would yield infinity which signals a very specific condition in the inputs) or as an indicator that the result is unknown due to a numerical overflow (i.e., a more general condition arising from a broad range of numerical situations). In the case of a CDF, the positive and negative mathematical infinities corresponds to respective specific points in the distribution but a numerical overflow infinity may correspond to a range of values, not a point in the distribution.For example, what is exp(710)? It's not infinity in the mathematical sense but it is too large to fit in a float or double. So if exp(x) returns infinity, what are we to infer? Is x = infinity or is x some unknown value?My guess is that most programmers (and their programs) treat infinity as a mathematical event (which may be wrong) rather than a numerical failure but I've not studied enough programs to have a valid sample size.

- Traden4Alpha
**Posts:**23951**Joined:**

One could also say that there are two types of NaN: not a real number and not a floating-point number. In the first case, the solution does not exist in the real number set (e.g., sqrt(-1)) and in the second case, it does not exist in the digital floating point number set (e.g., exp(710) ).

- Cuchulainn
**Posts:**64669**Joined:****Location:**Drosophila melanogaster-
**Contact:**

QuoteOriginally posted by: Traden4AlphaOne could also say that there are two types of NaN: not a real number and not a floating-point number. In the first case, the solution does not exist in the real number set (e.g., sqrt(-1)) and in the second case, it does not exist in the digital floating point number set (e.g., exp(710) ).The quiet NaN or a signaling NaN?

"Compatibility means deliberately repeating other people's mistakes."

David Wheeler

http://www.datasimfinancial.com

http://www.datasim.nl

David Wheeler

http://www.datasimfinancial.com

http://www.datasim.nl

- Traden4Alpha
**Posts:**23951**Joined:**

QuoteOriginally posted by: CuchulainnQuoteOriginally posted by: Traden4AlphaOne could also say that there are two types of NaN: not a real number and not a floating-point number. In the first case, the solution does not exist in the real number set (e.g., sqrt(-1)) and in the second case, it does not exist in the digital floating point number set (e.g., exp(710) ).The quiet NaN or a signaling NaN?That's an orthogonal issue: the specific cause of the error (i.e., not a real number vs. not a valid 64-bit floating point number) may be independent of the response to the error (i.e., quiet vs. signaling).

- Cuchulainn
**Posts:**64669**Joined:****Location:**Drosophila melanogaster-
**Contact:**

QuoteOriginally posted by: Traden4AlphaQuoteOriginally posted by: CuchulainnQuoteOriginally posted by: Traden4AlphaOne could also say that there are two types of NaN: not a real number and not a floating-point number. In the first case, the solution does not exist in the real number set (e.g., sqrt(-1)) and in the second case, it does not exist in the digital floating point number set (e.g., exp(710) ).The quiet NaN or a signaling NaN?That's an orthogonal issue: the specific cause of the error (i.e., not a real number vs. not a valid 64-bit floating point number) may be independent of the response to the error (i.e., quiet vs. signaling).design by contractThat's what we are missing.

David Wheeler

http://www.datasimfinancial.com

http://www.datasim.nl

- Traden4Alpha
**Posts:**23951**Joined:**

QuoteOriginally posted by: CuchulainnQuoteOriginally posted by: Traden4AlphaQuoteOriginally posted by: CuchulainnQuoteOriginally posted by: Traden4AlphaOne could also say that there are two types of NaN: not a real number and not a floating-point number. In the first case, the solution does not exist in the real number set (e.g., sqrt(-1)) and in the second case, it does not exist in the digital floating point number set (e.g., exp(710) ).The quiet NaN or a signaling NaN?That's an orthogonal issue: the specific cause of the error (i.e., not a real number vs. not a valid 64-bit floating point number) may be independent of the response to the error (i.e., quiet vs. signaling).design by contractThat's what we are missing.Exactly!Yet are there contracts that are detailed enough to cover all these cases of not-a-real-number, not-a-float-number, etc.? Moreover, in a complex library, how does one ensure that ALL library items share the same contract patterns so there's no misinterpretation of what qNaN, sNaN, ±INF, etc. mean.

- Cuchulainn
**Posts:**64669**Joined:****Location:**Drosophila melanogaster-
**Contact:**

QuoteOriginally posted by: Traden4AlphaQuoteOriginally posted by: CuchulainnQuoteOriginally posted by: Traden4AlphaQuoteOriginally posted by: CuchulainnQuoteOriginally posted by: Traden4AlphaOne could also say that there are two types of NaN: not a real number and not a floating-point number. In the first case, the solution does not exist in the real number set (e.g., sqrt(-1)) and in the second case, it does not exist in the digital floating point number set (e.g., exp(710) ).The quiet NaN or a signaling NaN?That's an orthogonal issue: the specific cause of the error (i.e., not a real number vs. not a valid 64-bit floating point number) may be independent of the response to the error (i.e., quiet vs. signaling).design by contractThat's what we are missing.Exactly!Yet are there contracts that are detailed enough to cover all these cases of not-a-real-number, not-a-float-number, etc.? Moreover, in a complex library, how does one ensure that ALL library items share the same contract patterns so there's no misinterpretation of what qNaN, sNaN, ±INF, etc. mean.From David Goldberg's seminal articleQuoteUnfortunately, the IEEE standard does not guarantee that the same program will deliver identical results on all conforming systems. Most programs will actually produce different results on different systems for a variety of reasons. For one, most programs involve the conversion of numbers between decimal and binary formats, and the IEEE standard does not completely specify the accuracy with which such conversions must be performed. For another, many programs use elementary functions supplied by a system library, and the standard doesn't specify these functions at all. Of course, most programmers know that these features lie beyond the scope of the IEEE standard. Many programmers may not realize that even a program that uses only the numeric formats and operations prescribed by the IEEE standard can compute different results on different systems. In fact, the authors of the standard intended to allow different implementations to obtain different results. Their intent is evident in the definition of the term destination in the IEEE 754 standard: "A destination may be either explicitly designated by the user or implicitly supplied by the system (for example, intermediate results in subexpressions or arguments for procedures). Some languages place the results of intermediate calculations in destinations beyond the user's control.

David Wheeler

http://www.datasimfinancial.com

http://www.datasim.nl

https://randomascii.wordpress.com/2013/ ... sm/QuoteIs IEEE floating-point math deterministic? Will you always get the same results from the same inputs? The answer is an unequivocal "yes". Unfortunately the answer is also an unequivocal "no". I'm afraid you will need to clarify your question.Worth reading in entirety, but in particular: QuoteThe precise results of functions like sin, cos, tan, etc. are not defined by the IEEE standard. That's because the only reasonable result to standardize would be the exact result correctly rounded, and calculating that is still an area of active research due to the Table Maker's Dilemma.

Last edited by Polter on December 24th, 2015, 11:00 pm, edited 1 time in total.

- Cuchulainn
**Posts:**64669**Joined:****Location:**Drosophila melanogaster-
**Contact:**

QuoteMathematics is a game played according to certain simple rules with meaningless marks on paper.David Hilbert

David Wheeler

http://www.datasimfinancial.com

http://www.datasim.nl