Re: Revisiting text to interval Re: Draft Standard Text, V02.1
> Date: Tue, 6 Apr 2010 07:14:03 -0500 (CDT)
> From: Ralph B Kearfott <rbk5287@xxxxxxxxxxxxx>
> To: P1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> Subject: Revisiting text to interval Re: Draft Standard Text, V02.1
>
> All,
>
> Revisiting the line that George started concerning inclusion of
> "text to interval" in an arithmetic standard, I see that it morphed into
> a discussion of whether or not we supply language bindings. However,
> I differ with George in viewing "text to interval" conversion as a
> language issue. In particular, "text" is well-defined in terms of
> standard representation of characters, as are numeric formats through
> 754-2008. Furthermore, the conversions have been specified in
> 754 (even in the 1985 version). It may be important that we specify these
> to clarify accuracy and "round down / round up" properties. If you
> are uncomfortable calling it "text," perhaps we should call it "decimal
> to binary" and "binary to decimal."
>
> Baker
>
Folks,
If I may clarify a bit...
It is true that 'text' conversions were defined in 754-1985.
But they were ill defined & not required to round correctly.
The intervening years have given us several efficient
algorithms for doing the job correctly & such conversions
are more carefully defined in 754-2008.
In particular, it notes that binary <--> decimal & binary <-->
string (a.k.a. external character sequences in the nomenclature
of 754-2008) conversions are separate but related issues. Both
are dealt with.
The relevant sections are 5.4.2 Conversion operations for
floating-point formats and external character sequences & 5.12
Details of conversion between floating-point formats and
external character sequences.
(You may also be interested in 5.8 Details of conversions from
floating-point to integer formats & 5.9 Details of operations
to round a floating-point datum in integral value. It could
relate to how we implements things like interval ceiling &
floor.)
It is useful to confine your mental image of the processes such
that you think of binary <--> decimal conversions as only taking
place between two floating point formats of different radix while
binary <--> string is for I/O like things. The reason is that
the former takes place at a particular fixed precision & the
latter is complicated by string length specifications & the
rather complicated issue of the shortest string that adequately
represents the datum.
We may need to make some minor changes to these specifications
to deal with interval issues. Things like special cases for
signed infinities & directed rounding should all be OK. But
some things we will need, like conversion of an [lo,hi] interval
to a string of the form midpoint +/- radius, will have real
issues that just don't come up in floating-point.
(Oddly enough, conversion from the string mid +/- rad to an
interval should be no big deal. How bout dat. :-)
Section 5.12 also specifies default string lengths for each
of the various basic floating-point datatypes. It also gives
formulae which should generalize well to the arbitrary
precision case.
Several people have mentioned the problem of loss of precision
when moving an interval datum to text & back again. We also
had this problem in 754-2008 & dealt with it by specifying a
floating-point <--> hexadecimal string conversion in 5.12.3.
This should serve to solve our problems as well.
Well, that's most of it.
You may need to reference other sections as well for some of
the details but after awhile ja just gotta read da damn ting,
ya know? :-)
Yours,
Dan