Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: Edge case conversions, exceptions to IEEE FPA



Michel et al,

I am in total agreement with this.  My stand (as a
member of the committee) is that float to
interval conversion should be to a singleton
interval.  (However, see my comments about
external string to interval conversion.)

Baker

Michel Hack wrote:
(Really: conversions from IEEE 754 floats to Intervals)

R. Baker Kearfott schrieb:
Arnold Neumaier wrote:
I don't think that the floating-point number 2 is derived
from a set of real numbers near 2.
Huh?  Certain exact (perhaps irrational numbers) are rounded to 2.
That's what I was saying, no more and no less.

These discussions (back and forth) might make sense if floats
carried a history around -- but they don't.  Programs do (or,
at any rate, can), and may know not only whether a particular
float represents an exact value (e.g. a small integer), but
also, more generally, what the error bounds are, and whether
they are absolute or relative.

We have seen application languages that permit numeric literals
to be decorated with uncertainty indications.  The same thing
should be possible with computed floats.

Now, surely there will be a generic intval(lower, upper) to
construct an interval from two floats.  Perhaps we should also
have explicit support for relative and absolute uncertainty
being passed as an argument, e.g.:

    absUncertainFloatToInterval(value, abserr)
    relUncertainFloatToInterval(value, relerr)

The advantage of having these is not just convenience:  since
the computation of interval bounds is encapsulated, it can
handle overflow and underflow appropriately (e.g. when value
is near a range edge).

The basic floatToInterval() would then always generate a point,
unless conversion was involved (in case of type mismatch).

In languages with implicit type conversion one has to be careful
about precedence.  For example, if the interval implementation
type is binary64 but the input value is binary128, the input
must not be coerced to binary64 before being passed to the
encapsulation function.  In C for example there would have to
be a separate function for each input type.  If preprocessors
are used to generate interval code (one possible implementation
when the language does not support interval types directly),
this step could be hidden behind macros.  Conceptually it must
be there however, and 1788 should require this.

Michel.

P.S.  Often the question of string vs IEEE float has come up with
      regard to '1e400' vs 1e400.  These arguments all apply even
      in the absence of strings, when multiple floating-point types
      are supported:  1e400 is a pretty small Binary128 finite number.

Sent: 2008-11-10 20:21:22 UTC




--

---------------------------------------------------------------
R. Baker Kearfott,    rbk@xxxxxxxxxxxxx   (337) 482-5346 (fax)
(337) 482-5270 (work)                     (337) 993-1827 (home)
URL: http://interval.louisiana.edu/kearfott.html
Department of Mathematics, University of Louisiana at Lafayette
(Room 217 Maxim D. Doucet Hall, 1403 Johnston Street)
Box 4-1010, Lafayette, LA 70504-1010, USA
---------------------------------------------------------------