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

From: Andy Little (andy_at_[hidden])
Date: 2003-12-25 19:00:56

"Fernando Cacciola" <fernando_cacciola_at_[hidden]> wrote in message
news:bsa78i$u91$1_at_sea.gmane.org...
> Hi Eric,
>
> "Eric Ford" <un5o6n902_at_[hidden]> escribió en el mensaje
> news:22100-48135_at_sneakemail.com...

> > 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...

Yep . I dont know that  physical quantities with dimensions should be
considered as numeric types.
However that doesnt really solve the problem.In the physical_quantities type
I have two layers of problem, both the underlying value_type and at the
physical_quantity level.
I currently see a  centimeters<int> to meters<int> conversion (at the
physical_quanity level) as very roughly similar to say a float to int
conversion for numeric types
In the inbuilt case most compilers issues a warning though I dont think this
is a requirement in the standard.
In case of a float and an int both are imperfect ways of representing what
Fernando Cacciola I think calls an 'abstract number'.
In a similar way  centimeters and meters can both be used to represent the
same length.
In both cases the concept is fine... the problem comes in the reality of the
representation.
Ideally (:-) ) I would like to take the same approach as with inbuilt ie
provide a warning.
In practise I have been experimenting with using a similar technique to
concept checking.
Alternatives are to allow only explicit conversions which I dont favour for
various reasons,or to provide some form of(say) unit_cast<>() function.
Perhaps  in the long term user definable errors and warnings might be a usef
ul addition to C++. (The usefulness of concept checking provides the
precedent, and some indication of how that might be achieved)
I am very interested in the converter because (for example) the rounding
principles used in converter might provide a model for how to approach
conversions as above in a physical quantity, but it is very early days at
the moment.

regards
Andy Little