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

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

*To*: "Siegfried M. Rump" <rump@xxxxxxxxxxxxx>*Subject*: Re: Alternate floating-point results under directed rounding*From*: Arnold Neumaier <Arnold.Neumaier@xxxxxxxxxxxx>*Date*: Fri, 07 Nov 2008 17:50:08 +0100*Cc*: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>*Delivered-to*: mhonarc@xxxxxxxxxxxxxxxx*In-reply-to*: <op.uj9a1za7v059od@xxxxxxxxxxxx>*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*: <200810311555.m9VFtNru005903@xxxxxxxxxxxxxxxxxxx> <op.ujxpwjm5v059od@xxxxxxxxxxxx> <490EC8FA.3080302@xxxxxxxxxxxx> <op.uj5ac6agv059od@xxxxxxxxxxxx> <49119AE0.5070001@xxxxxxxxxxxx> <4471533ED9154CF892A590B5538A1563@proton> <491404B2.9020108@xxxxxxxxxxxx> <op.uj8yncn5v059od@xxxxxxxxxxxx> <491431F7.509@xxxxxxxxxxxx> <op.uj9a1za7v059od@xxxxxxxxxxxx>*Sender*: stds-1788@xxxxxxxx*User-agent*: Thunderbird 1.5.0.14ubu (X11/20080925)

Siegfried M. Rump schrieb:

On Fri, 07 Nov 2008 11:17:59 -0100, Arnold Neumaier<Arnold.Neumaier@xxxxxxxxxxxx> wrote:I don't understand. To have 0*[1,inf] = [0,0], no interpretation of inf as floating-point is needed, since this automatically holds with the specification of [l,u] = set of reals between l and u. No conversion of inf to an interval is involved here.Consider (in Matlab notation) X = intval(NaN); Y = 0*X The result is the empty set, in either way. We expect this. Consider X = intval(0.1); Y = 0*X The result is [0], in either way. We expect this. Consider X = intval(1e40); Y = 0*X The result is still [0], either way. We expect this. Consider X = intval(1e400); Y = 0*X Your result is the empty set. Strange? I think yes.

People need to be taught anyway to avoid writing any of these to get validated results. Why then should we cater for them to get off luckily in a few rare cases? In my opinion, the value of the result does not matter, since in each of the three cases, a semantic error has been made that already invalidated the enclosure properties of interval arithmetic and hence makes the result meaningless from a rigorous point of view. You also forgot to consider cases like U=1e400; V=1e-800*U X = intval(V); Y = 0*X The result is the empty set. Strange? You should think yes.

As you say, we can define everything as we wish.

Yes.

I prefer a definition so that Y is still [0].

This is why I had proposed to convert +inf into the interval [realmax,realmax], -inf into the interval [-realmax,-realmax], NaN into the interval [0,0]

and to raise the nonstandardNumber flag as in Section 2.1 of my proposal (Version 2.0). This would remove the above strangeness. Somehow, my suggestion seems to have missed your attention. Please comment on this proposal to modify the interpretation of +-inf and NaN. With this interpretation, fixed operations could be handled

With nonreal floating-point numbers interpreted as empty, we'd have to convert a=+-inf to NaN before execution of formulas such as a+[l,u] = [a+l,a+u], etc.,

explicit case distinctions. Then mixed arithmetic operations with floats and intervals will never result in the empty set. Arnold Neumaier

**Follow-Ups**:**Edge case conversions, exceptions to IEEE FPA***From:*Van Snyder

**Re: Alternate floating-point results under directed rounding***From:*Jürgen Wolff v Gudenberg

**References**:**Re: Alternate floating-point results under directed rounding***From:*Siegfried M. Rump

- Prev by Date:
**Re: Alternate floating-point results under directed rounding** - Next by Date:
**Re: signed zeros** - Previous by thread:
**Re: Alternate floating-point results under directed rounding** - Next by thread:
**Re: Alternate floating-point results under directed rounding** - Index(es):