[boost] Re: Review of Fernando' Numeric Conversion Library

From: Fernando Cacciola (fernando_cacciola_at_[hidden])
Date: 2003-12-23 15:06:44

Hi Eric,

"Eric Ford" <un5o6n902_at_[hidden]> escribió en el mensaje
news:22100-48135_at_sneakemail.com...
>     * What is your evaluation of the design?
>
> The general design seems fine.  A few concerns...
>
> 1.  What about the case of converting an integral type to a floating point
when the integral type has a wider range than the floating type?
>

I didn't consider this possibility because it is explicitely ruled out by
the C++ Standard (ISO98)
However, Kevin Lynch reported that this was no longer the case with C99, so
I'll have to look at it closely.

> 2.  What is gained by the assumption that UDTs have a wider range than
bulitin types?

Simplicity :-)

Initially, I tried to figure out a way to compare the ranges of arbitrary
numeric types at compile time (using constant expressions), but that
required user-side information that was difficult to specify in a way that
properly cover most typical UDTs.
Then I tried to figure out a taxonomy that could be use to rank arbitrary
numeric types in a nonambiguous way.
Eventually I've given up and decided to drop UDT support from the library.
Then I realized that I was using the library with some UDTs and that it
worked sufficiently well even with the parial, arbitrary support for UDTs,
so I decided to leave the partial UDT support in and let user experience
produce that necessary facts to generate a proper solution.

> I think there should be a way to overide this assumption.

Yes.... in fact, I think that UDT support w.r.t to range comparison must be
revised. I'll get to work on this before the next release where the lib
would be included.

> 3.  Is it wise to assume that the lowest() = -numerical_limits<T>::max()?
Does someone know if IEEE requires this to be the case?  I wonder if special
values might cause this to be a bad assumption.
>

Very good question!
Off the top of my head I think that IEEE754 requires the sign info to be
independent of the signficand and the exponent.
And AFAICT, this requirement is enough to guarantee that the above
expression will always work.
But I'll look closer anyway.

> 4.  I would think that smallest() should return 1 and not 0 for integral
types. Otherwise, smallest() has a different meaning for integral and
floating point types.  And that's exactly what lowest() and highest() were
meant to prevent.
>
Right... my mistake.

> 5.  Has there been consideration of how to deal with the conversion of two
dimensioned quantities with different units?  In particular, what about when
the values are represented by integral types?  E.g.  Converting meters<int>
to centimeters<int> is no problem.  But in converting centimeters<int> to
meters<int> an exact conversion is not always possible, even though both
numeric values are stored using integral types.
>
Ha... I haven't even thought of this becasue I work only with dimensionless
data...
Andy Little is working with a physical quantities lib so we might get
toghether and consider this.

>     * What is your evaluation of the implementation?
>
> I only quickly browsed the implementation, but from what I saw, it seemed
to be reasonabely well done.
>
>     * What is your evaluation of the documentation?
>
> 1. definitions.html#stdtypes:  last sentance:  I disagree with the advice
to use unsigned types for quantities which are positive definite.  While I
recognize the case for both sides of this argument, I see no reason to
include this recommendation in the documentation.
>
OK, this seems to be the source of an endless discussion... but I agree that
the recommendation is outside the scope of the library, so I'll remove it.

> 2. requirements#req:  Trunc<T> also requires that T(0) be defined
>
Good catch!

>
> 3. bounds.html#bounds:  Typeo in heading
>
OK

>
>     * What is your evaluation of the potential usefulness of the library?
>
> lowest(), highest(), and smallest() will definitely get quite a bit of
use.
> The improved numeric_cast should also get a good bit of use, and is
definitely worth having in boost.
>
>     * Did you try to use the library?  With what compiler?  Did you have
any problems?
>
> Just the tests.  No
>
>     * How much effort did you put into your evaluation? A glance? A quick
reading? In-depth study?
>
> A few houurs
>
>     * Are you knowledgeable about the problem domain?
>
> I have practical experience in numerical computation, but little formal
training in CS.
>
>     * Do you think the library should be accepted as a Boost library?  Be
sure to say this explicitly so that your other comments don't obscure your
overall opinion.
>
> Yes.
>
Great!

Best,

Fernando Cacciola
SciSoft