Why You Cannot (Yet) Write an “Interval Arithmetic” Library in Common Lisp . or: Hammering Some Sense into :ieee-floating-point Marco Antoniotti Dipartimento di Informatica, Sistemistica e Comunicazione Università degli Studi di Milano Bicocca [email protected] ABSTRACT 1 INTRODUCTION “Interval Arithmetic” (IA) appears to be a useful numerical An interesting exercise (academic or not) that a programmer tool to have at hand in several applications. Alas, the current (Common Lisp or not) may find intriguing is to implement an IA descriptions and proposed standards are always formulated Interval Arithmetic (IA) library1. Programmers of all stripes in terms of the IEEE-754 standard, and the status of IEEE- would learn a lot if they tried to really implement an IA 754 compliance of most Common Lisp implementations is not library. But since most probably won’t, this paper may serve up to par. as sufficient summary to get you through a cocktail party A solution would be for Common Lisp implementations to conversation on the matter. adhere to the Language Independent Arithmetic (LIA) IEC The usefulness of IA is rather established; many numerical standard, which includes IEEE 754. issues can be naturally dealt with by using an IA library, al- While the LIA standard provides a set of proposed bindings beit at a slight increase in computation times. There is a nice for Common Lisp, the format and depth of the specification body of literature and proposed standards to ensure avail- documents is not readily usable by a Common Lisp program- ability of IA in a computing environment, and many of these mer, should an implementation decide to comply with the eventually provide one or two different interval representa- provisions. Moreover, much latitude is left to each implemen- tions (endpoint and midpoint), the operations on them, and tation to provide the LIA “environmental” setup. nitpicking treatment of corner cases; e.g., intervals with infi- It would be most beneficial if more precision were agreed nite endpoints and interval division by an interval containing upon by the Common Lisp community about how to provide 0. LIA compliance in the implementations. In that case, a new As we shall see, the “nitpicking” boils down to using the set of documentation or manuals in the style of the Hyper- IEEE-754/IEC-60559 standards [11]. Eventually, in this work, Spec could be provided, for the benefit of the Common Lisp the use of the IEC Language Independent Arithmetic (LIA) programmer. standards [6–8] will be advocated. The LIA standard is a The goal of this paper is to foster a discussion within comprehensive collection of concepts and carefully thought the Common Lisp community to converge on a complete out behaviors a basic library of integer, floating point and specification for LIA compliance. The paper discusses someof complex numbers mathematical functions and ancillary en- the issues that must be resolved to reach that goal, e.g., error vironment functionalities should look like. One of the, in handling and full specification of mathematical functions the opinion of the writer, unstated goals of LIA is that a behavior. programmer should be able to relatively easily understand mathematical software writeen in any language ecosystem KEYWORDS that abided the specification. Programming Languages, Common Lisp, Library Specification, A word of caution. The present paper is neither a full Floating Point Arithmetic, Language Independent Arithmetic blown Common Lisp LIA specification, nor a description of an implementation of the functionalities depicted herein. It ACM Reference Format: rather is a leaflet that intend to present the community a Marco Antoniotti. 2020. Why You Cannot (Yet) Write an “Inter- val Arithmetic” Library in Common Lisp: . or: Hammering Some project which, in the modest opinion of the writer, should Sense into :ieee-floating-point. In Proceedings of the 13th Eu- be completed after careful debate and careful consideration ropean Lisp Symposium (ELS 2020). ACM, New York, NY, USA, of all the details. 8 pages. https://doi.org/10.5281/zenodo.3759522 1.1 An IA Library. Hitting the Wall Permission to make digital or hard copies of part or all of this work for personal or classroom use is granted without fee provided that An IA library in Common Lisp implementing what is known copies are not made or distributed for profit or commercial advantage as an endpoint representation can be easily started as follows. and that copies bear this notice and the full citation on the first page. For brevity, since it is a valid Common Lisp identifier, we use Copyrights for third-party components of this work must be honored. For all other uses, contact the owner/author(s). ELS 2020, April 27–28 2020, Zürich, Switzerland 1See, for example [4], or [5] for a rather complete summary with © 2020 Copyright held by the owner/author(s). references to the seminal works in the area. IEEE has also published a https://doi.org/10.5281/zenodo.3759522 preliminary standard for IA [10]. ELS 2020, April 27–28 2020, Zürich, Switzerland Marco Antoniotti the name [] here for what other languages might call an floating-point-invalid-operation interval. division-by-zero (defstruct ([] (:constructor [] (low high))) Alas, their use is inconsistent across implementations (apart (low 0.0 :type real) from the mostly clear cut case of division-by-zero). Two (high 0.0 :type real)) implementations may choose to signal floating-point-invalid-operation or (defun radius (i) (- ([]-high i) ([]-low i))) floating-point-inexact on the same operation. This is not the only issue vis-a-vis Common Lisp and the (defun pointp (i) (= ([]-high i) ([]-low i))) IEEE-754. A deeper issue pertains the notification machinery that is invoked when one of the aforementioned conditions is (defmethod add ((i1 []) (i2 [])) to be signaled by an operation. Should an implementation ([] (+ ([]-low i1) ([]-low i2)) actually signal a (floating point) condition using error, or (+ ([]-high i1) ([]-high i2)))) should it go the C way [3] and record somewhere an indication that a condition “happened”, for the programmer to check (defmethod sub ((i1 []) (i2 [])) directly? ([] (- ([]-low i1) ([]-high i2)) (- ([]-high i1) ([]-low i2)))) 1.2 Common Lisp Implementations and the After starting in earnest, a Common Lisp (or Java, C, :ieee-floating-point Feature R, Python) programmer is soon faced with a number of The ANSI Common Lisp Standard [1] makes provisions for a numerical issues, should she be willing to achieve the best Common Lisp implementation to “declare” that it purports possible behavior out of the IA library. to conform to the requirements of the IEEE Standard for The problem is that, as mentioned before, IA specifications Binary Floating-Point Arithmetic (no reference given). There are usually formulated in terms of the IEEE-754 standard, are a few problems with this statement3. which, at this point is readily available only to C and C++ The presence of the feature in a programmers2 In particular, the IA specifications exploit :ieee-floating-point Common Lisp implementation is a (very) partial indication rounding modes and infinities, which are unevenly available that some support for the IEEE-754 is available. Table 1 in Common Lisp implementations; another, related issue is shows a summary of the current state of compliance for a the treatment of floating point exceptions. number of implementations4 with respect to the notions just Rounding Modes. If we had available some ways of handling described. infinities and rounding modes, we could write the IA library operations as follows: Infinities and NaNs. Many implementations provide infini- ties and NaNs, but with obviously different lineages. E.g., (defmethod add ((i1 []) (i2 [])) the following syntax is used by LW and CCL, which is then ([] (rounding-down (+ ...)) declined in various interesting ways: (rounding-up (+ ...)))) where rounding-down and rounding-up are macros with an ∞ 1F++0, 1D-+0 intuitive semantics. Unfortunately, at this point in time, it is NaN 1F+-0, 1S–0 not possible to provide the rounding-down and rounding-up but ACL chooses to provide “variables” with read-time syn- macros without delving deeply in an implementation. tax. Infinities and NaNs. Another issue is the handling of spe- ACL prompt> *infinity-single* cial values: essentially infinities and NaNs (not-a-number). #.*INFINITY-SINGLE* Both items are handled unevenly in Common Lisp implementa- tions; infinities and quiet NaNs (cfr. the IEEE-754 standard) ACL prompt> (+ 42 *nan-single*) are somewhat supported; signaling NaNs not so much so. #.*NAN-SINGLE* Handling of Floating Point Exceptions. Apart from our While this may be perfectly sensible it has the drawback of doomed IA library, another issue that is not always very well not playing so nicely with *read-eval*. clarified in Common Lisp implementations (and especially The only implementations that allow a programmer to get across them) is how floating points exceptions are handled. a handle on a signaling NaN are CMUCL and SBCL. There The Common Lisp standard defines the conditions: appear to be no easy way to create such a value in the other implementations. floating-point-overflow floating-point-underflow floating-point-inexact 3A form of “left to the implementation”, which, as usual, does not bode well for the programmer. 2There are, e.g., Python bindings to IEEE-754, but they rely on the 4The table is incomplete because not all implementations were checked underlying C library implementation. and because the notion of “compliance” is rather complicated to assess Cfr., https://www.python.org/dev/peps/pep-0754/. in this case. Why You Cannot (Yet) Write an “Interval Arithmetic” Library in Common Lisp ELS 2020, April 27–28 2020, Zürich, Switzerland CMUCL/SBCL LW ACL ABCL ECL CCL Infinities Y Y Y U U Y Quiet NaNs Y Y Y U U Y Signaling NaNs Y N N U U U Rounding Y N N U U N Exceptions NACF P P P P P P Exceptions NRI Y N N U U N Table 1: Common Lisp implementations “compliance” status w.r.t.