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 <bobcass...@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 <dherr...@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 >