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

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

*To*: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>*Subject*: Alternate floating-point results under directed rounding*From*: Michel Hack <hack@xxxxxxxxxxxxxx>*Date*: Monday 10 Nov 2008 at 9:26 a.m. EST (2008-11-10 14:26 GMT)*Delivered-to*: mhonarc@xxxxxxxxxxxxxxxx*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>*Sender*: stds-1788@xxxxxxxx

Arnold Neumaier wrote: > Nobody so far suggested seriously to convert by epsilon-inflation. As Arnold already noted a bit later, Van Snyder did, but ALSO supported conversion to point intervals, if I understood his (Fri, 07 Nov 2008 17:28:11 -0800) proposal correctly: > intval(inf) -> (HUGE:+inf) > intval(-inf) -> (-inf:-HUGE) > intval(1.0e40) = intval(sinf) -> (HUGE(1.0e0):sinf) > intval(1.0e400) = intval(sinf) -> (HUGE(1.0e0):sinf) > intval(1.0d400) = intval(dinf) -> (HUGE(1.0d0):dinf) > intval(1.0d40) -> (NEAREST(1.0d40,-1.0d0):NEAREST(1.0d40,+1.0d0)) > intval(0.1) -> (NEAREST(0.1,-1.0):NEAREST(0.1,+1.0)) > intval('0.1') should become something sharper than intval(0.1). > intval(NaN) -> (NaN:NaN) = the empty set > intval(x,y) -> (x:y) provided x <= y and either x or y is finite. > If either one is NaN the result represents the empty set. > intval(-inf,-inf) -> (-inf:-HUGE) > intval(+inf,+inf) -> (+HUGE:+inf) In other words, intval() may take one or two arguments; the former implies epsilon-expansion, and the latter permits actual bounds to be specified, so that intval(x,x) is a point conversion. The standard should specify the availability of both types of conversion, without tying down the syntax. The standard may require that there be a single-argument epsilon-expanding conversion, in order to facilitate language or environment definitions that define this to be the means of automatic type conversion. If modes are appropriate, there could be a mode (static or dynamic attribute, in the 754-2008 sense, hence possibly under program control) to select whether point-conversion or expansion should be used. In either case, if ACTUAL conversion is involved (e.g. because of type narrowing or base change), two-way rounding should be used to derive the interval. Michel. Sent: 2008-11-10 15:40:49 UTC

- Prev by Date:
**Re: Edge case conversions, exceptions to IEEE FPA** - Next by Date:
**Alternate floating-point results under directed rounding** - Previous by thread:
**Alternate floating-point results under directed rounding** - Next by thread:
**Alternate floating-point results under directed rounding** - Index(es):