Subject: Re: [boost] [Math/Statistical Distributions] Rethinking of distributiontemplate parameters.
From: Marco Guazzone (marco.guazzone_at_[hidden])
Date: 2009-05-21 07:35:26
On Thu, May 21, 2009 at 11:47 AM, John Maddock <john_at_[hidden]> wrote:
>> This is a feature request for the next version of Math/Statisical
>> Distributions lib.
>> Currently, due to lack of input type information, discrete
>> distributions can only be "emulated" by using the discrete_quantile
>> However, doing so the effective quantile type is still a real type.
>> In my opinion, this have at least two disadvantages:
> I believe your disadvantages are more imagined than real.
>> 1. Operations are slow since the underlying quantile type is still
>> real. Instead, operations on really integral types are generally
> Unfortunately there is no way the quantile of discrete distributions can be
> calculated internally using all integer arithmetic (at least I can't think
> of a case other than maybe the trivial bernoulli distribution). Normally
> the result of the quantile is calculated as a real-number and then
> appropriately rounded acording to the policy in effect, in a few cases the
> result is calculated directly as an integer by summing CDF values
> (hypergeomentric for example), but the internal calculations still have to
> done using reals.
> There's also no overhead from returning a real type (since it's usually
> returned in a register just like an integer type would be), there might be a
> tiny overhead if the user then casts to an integer, but if we internalised
> that cast by returning an integer type then everyone would pay that cost no
> matter what the use case :-(
> BTW there are a few genuine use cases for returning a real-valued result
> from the quantile of a descrete distribution.
>> 2. Quantile comparison might be inaccurate since we are comparing real
> Nope, not if you've requested an integer result (which is the default
> policy), as integers are represented exactly in floating point types: unless
I've missed that, given two floating point numbers x and y and the
related floating point machine numbers fl(x) and fl(y):
if x==y then fl(y)-eps < fl(x) < fl(y)+eps;
if x==y then round(fl(x)) == round(fl(y));
where eps is the unit roundoff error.
I've only considered the first relation.
Boost list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk