Re: Revisiting text to interval Re: Draft Standard Text, V02.1
OK, I withdraw my reservation about I/O.
For my own piece of mind, I must think of this as specifying an environment and get it out of my head that P1788 is (only) about how silicon should behave, as several of you have pointed out.
I absolutely agree that an environment for intervals needs I/O.
Dr. George F. Corliss
Electrical and Computer Engineering
Marquette University
P.O. Box 1881
1515 W. Wisconsin Ave
Milwaukee WI 53201-1881 USA
414-288-6599; GasDay: 288-4400; Fax 288-5579
George.Corliss@xxxxxxxxxxxxx
www.eng.mu.edu/corlissg
On Apr 6, 2010, at 8:12 AM, Dan Zuras Intervals wrote:
>> 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