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@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@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