# Start of IEEE 754 support

**URL:** <https://swi-prolog.discourse.group/t/start-of-ieee-754-support/1843>\
**Category:** Announce\
**Created:** [February 7, 2020, 9:40am UTC](https://swi-prolog.discourse.group/t/start-of-ieee-754-support/1843 "2020-02-07T09:40:37Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![jan](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/jan/32/4_2.png) [@jan](https://swi-prolog.discourse.group/u/jan)\
**Post date:** [February 7, 2020, 9:40am UTC](https://swi-prolog.discourse.group/t/start-of-ieee-754-support/1843/1 "2020-02-07T09:40:38Z")

</div>

Following the discussions with @ridgeworks and Joachim Schimpf from ECLiPSe, I’ve pushed a couple of commits that provide the first steps towards IEEE-754 support following [this proposal](http://eclipseclp.org/Specs/core_update_float.html)

- (Already since 2014) Support NaN, Inf, -0.0 and copysign/2
- Added nexttoward/2
- Have 4 flags, one for each float event (underflow, overflow, zero-div, undefined) that allow generating one of the IEEE float special values or throw an exception. By default, as before, all but _underflow_ generate exceptions.
- Have control over float rounding using the flag `float_rounding`.

Not all is set in stone. One thing to be done is verify all the special value generation and subsequent handling in functions is correct. I’ll wait for a test suite 🙂

Another issues is float rounding. As is, you can set this to `to_negative`, compute, to `to_positive`, compute again and (optionally) back to `nearest` to get an interval. Unfortunately it is hard to guarantee the flag remains unchanged at the end of the process. The ECLiPSe solution is to have a type _breal_ (_bounded real_). It feels as a bit of an overkill to add another atomic type to deal with this. ECLiPSe is primarily a constraint system where this often makes sense, SWI-Prolog is not. Ideas welcome. One might be an alternative to is/2 that computes the bounds as a compound term? If we define the same compound as a function that, depending on the rounding mode returns the upper or lower bound we have something similar to what we used to have for `rdiv` that allows getting the job done fairly easily with little impact (but a little less elegantly).