Common wisdom on arithmetic (IEEE)

[Bob Cassels]

We implemented a WITH-ROUNDING-MODE macro, to allow setting the rounding mode for a block of code. But of course that then screws up all of your library functions, like the trig functions, since they assume they are being run in the default :ROUND-TO-EVEN,



> On Nov 5, 2018, at 10:19 AM, Bob Cassels <bobcassels at netscape.net> wrote:
> 
> The reader should be able to read -0.0, and the printer should print it as -0.0.
> 
> (= 0.0 -0.0)
> (not (eq 0.0 -0.0))
> (eql 0.0 -0.0))
> 
> Infinities should just be floating-point values, not symbols. You should pick a way to print them and read them. I hope you’d pick one of the ways that current implementations use, rather than invent a new one. I’d suggest using what we used at Symbolics, but I don’t remember what that was. I would assume it starts with 1e / 1d, -1e / -1d, but I don’t remember what we used after that.
> 
> 
> 
>> On Nov 2, 2018, at 4:19 PM, Daniel Herring <dherring at tentpost.com> wrote:
>> 
>> Hi Marco,
>> 
>> I would just rely on the IEEE 754 values and define constants for convenience.  Negative zero is an artifact of floating-point calculations, not a symbol in math.  Don't forget that many values are classified as NaN (common exponent, many fractions).
>> 
>> C defines fpclassify() and related predicates to return NaN, infinite, zero, subnormal, or normal.
>> 
>> Obligatory reference:  What Every Computer Scientist Should Know About Floating-Point Arithmetic by David Goldberg
>> 
>> Rounding error causes loss of life:
>> http://www-users.math.umn.edu/~arnold/disasters/patriot.html
>> 
>> 
>> - Daniel
>> 
>> 
>> On Fri, 2 Nov 2018, Antoniotti Marco wrote:
>> 
>>> Dear all
>>> I am fooling around (again!) with the spec of a math library that I want the students to work on as a project.  Language is Common Lisp.
>>> Essentially the library is an extended generic math library built on the basis of the many ones floating around.
>>> Now.  Here comes IEEE. And “infinity"
>>> Among many implementations there is more or less a consensus about how to “represent” IEEE infinities in CL.
>>> E.g.
>>> LW > math:long-float-positive-infinity
>>> +1D++0 #| +1D++0 is double-float plus-infinity |#
>>> CCL ? math:long-float-positive-infinity
>>> 1D++0
>>> and so on.
>>> NaN is not as clearly defined.
>>> LW 45 > math:nan
>>> 1D+-0 #| 1D+-0 is double-float not-a-number |#
>>> CCL ? math:nan
>>> 1D+-0 #| not-a-number |#
>>> But to get a NaN in SBCL/CMUCL requires a trick.  I use
>>> (sb-kernel:make-double-float -524288 0)) ; Courtesy of Raymond Toy.
>>> In any case…  There are two issues that I would like to brainstorm a bit.
>>> The first one pertains rounding modes.  Give the current state of affairs, it does not seem possible to access them in all the CL implementations.  CMUCL/SBCL give you the necessary hooks, but LW doesn’t.
>>> Let’s skip this.
>>> The second is just a simple question.
>>> Given that we *do* have (with some acrobatics) access to IEEE infinities, would you add symbolic constants to such library like
>>> (defconstant +posinf+ ‘+posinf+)
>>> or would you just rely on the IEEE infinities?
>>> Generic functions like
>>> (defgeneric plus (x y) …)
>>> Will obviously be affected.
>>> I just want to get a feeling about the overall wisdom of this crowd.
>>> All the best
>>> Marco
>>> --
>>> Marco Antoniotti
>