|
Boost : |
From: Eric Ford (un5o6n902_at_[hidden])
Date: 2003-12-23 03:53:56
* 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?
2. What is gained by the assumption that UDTs have a wider range than bulitin types? I think there should be a way to overide this assumption.
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.
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.
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.
* 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.
2. requirements#req: Trunc<T> also requires that T(0) be defined
3. bounds.html#bounds: Typeo in heading
* 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.
Eric Ford
--------------------------------------
Protect yourself from spam,
use http://sneakemail.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk