Thread Links |
Date Links |
||||
---|---|---|---|---|---|

Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |

*To*: Michel Hack <hack@xxxxxxxxxxxxxx>*Subject*: Re: floats and intervals, constants, 0.1, 1e400 and Inf*From*: Arnold Neumaier <Arnold.Neumaier@xxxxxxxxxxxx>*Date*: Mon, 10 Nov 2008 13:02:08 +0100*Cc*: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>*Delivered-to*: mhonarc@xxxxxxxxxxxxxxxx*In-reply-to*: <200811072307.mA7N7Y3J014299@xxxxxxxxxxxxxxxxxxx>*List-help*: <http://listserv.ieee.org/cgi-bin/wa?LIST=STDS-1788>, <mailto:LISTSERV@LISTSERV.IEEE.ORG?body=INFO%20STDS-1788>*List-owner*: <mailto:STDS-1788-request@LISTSERV.IEEE.ORG>*List-subscribe*: <mailto:STDS-1788-subscribe-request@LISTSERV.IEEE.ORG>*List-unsubscribe*: <mailto:STDS-1788-unsubscribe-request@LISTSERV.IEEE.ORG>*Organization*: University of Vienna*References*: <200811072307.mA7N7Y3J014299@xxxxxxxxxxxxxxxxxxx>*Sender*: stds-1788@xxxxxxxx*User-agent*: Thunderbird 1.5.0.14ubu (X11/20080925)

Michel Hack schrieb: > Now, from the point of view of the 1788 standard, what needs to be > specified is WHAT functionality needs to be available, and what its > semantics are, not HOW this is to be supported in a programming > environment (except as non-normative examples and suggestions). > > So we need ConvertFloatToInterval as well as ConvertStringToInterval. > The former should treat its argument as exact This is exactly waht is in my proposal (v2.0) > -- ASSUMING that the > source type matches the implementation type of intervals. For > example, if the implementation type is Binary64 and the source type > is Binary80 or Binary128 (or Decimal for that matter), the conversion > could be Inexact. This is something new, not considered in my proposal - that the floats used to represent bounds are different from the floats used to represent intervals. > Indeed, a general rule for constant->interval conversion should be > round-down for lower bound, round-up for upper bound (assuming the > implementation is indeed in terms of bounds). The fact that same-type > floats will be converted exactly is then simply a consequence of the > fact that both "conversions" (being no-ops) yield the same result. Yes. > This is of course also the place where Inf and Nan source operands > have to be interpreted in the proper context -- and the most common > view here appears to be as an empty interval (with or without raising > some flags). The same thing would happen for a midpoint-radius > implementation, as the radius would simply be zero. Indeed, I suspect > conversion to midpoint-radius would probably go through an intermediate > lower-upper-bound representation. Though briefly discussed, I think nobody has shown strong emotions for satandardizing mdpoint-radius interval representations. I advocate against it. > Now, one concept that has not been discussed so far is whether there > can be several interval types, with different precisions. If so, there > would have to be conversion functions between interval types as well. This is another issue not considered in my proposal. The correct conversion would be by outward rounding the bounds. > Some interval types might not even match traditional floating-point > types exactly, as it might be useful to trade range for precision in > a dynamic manner (e.g. to get a better grip on the gap between Inf > and maxReal).

C.W. Clenshaw and F.W.J. Olver Beyond Floating Point J. ACM 31 (1984), 319-328 http://portal.acm.org/citation.cfm?id=62.322429 But it hasn't been widely used. Note that my proposal is almost independent of the underlying number representation. If there is sufficient positive interest, I can easily adapt to multiple floating-point formats. Arnold Neumaier

**Follow-Ups**:**Re: floats and intervals, constants, 0.1, 1e400 and Inf***From:*Svetoslav Markov

**Re: floats and intervals, constants, 0.1, 1e400 and Inf***From:*R. Baker Kearfott

**References**:**floats and intervals, constants, 0.1, 1e400 and Inf***From:*Michel Hack

- Prev by Date:
**Re: Alternate floating-point results under directed rounding** - Next by Date:
**Version 2.11, Proposal for interval standardization** - Previous by thread:
**floats and intervals, constants, 0.1, 1e400 and Inf** - Next by thread:
**Re: floats and intervals, constants, 0.1, 1e400 and Inf** - Index(es):