Boost logo

Boost :

Subject: Re: [boost] [Numeric Conversion] Documentation Notes/Questions
From: Paul A. Bristow (pbristow_at_[hidden])
Date: 2012-11-02 09:07:06


 -----Original Message-----
> From: boost-bounces_at_[hidden] [mailto:boost-bounces_at_[hidden]] On Behalf Of Fernando
> Cacciola
> Sent: Thursday, November 01, 2012 6:34 PM
> To: boost_at_[hidden]
> Subject: Re: [boost] [Numeric Conversion] Documentation Notes/Questions
>
> That is needed to draw a distinction between the values that are represented and the effective
value of
> the representation.
> I debated myself a lot whether such a concept was really needed, given how odd it is, or if there
was a
> better way, but couldn't find it.
>
> The problem is that, when talking about the effects of a numeric conversion, I need a thing that
can be
> used to qualify and quantizie the difference between the (effectively represented) values before
and after
> the conversion.
> That is, in "(int)1.2" there are just two represented values, the floating point that closely
matches the
> decimal 1.2 and the integer 1, yet I need to refer to the .2 in there that is getting lost and a
useful element
> to do that, IMO, is "the decimal number 1.2". I call that an abstract value.

I'm not clear why you have chosen to call this an 'abstract value'.

'decimal digit string' seems more explicit -though I can see that it might also be a hex of oct (or
even bin) string.

So would 'digit string value' be more immediately obvious?

(It could be qualified as 'integer digit string'(99), 'decimal digit string' (1.2), 'fraction digit
string' (.1234), 'hex integer digit string (FF), ...)

But perhaps I'm missing something?

> Without such a concept it is much more difficult to describe and bound *in general terms* the
sides effects
> of conversions, such as loose of precision, overflow and underflow.

Definitely! This is confusing stuff.

Paul

---
Paul A. Bristow,
Prizet Farmhouse, Kendal LA8 8AB  UK
+44 1539 561830  07714330204
pbristow_at_[hidden]

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk