Common wisdom on arithmetic (IEEE)

[Antoniotti Marco]

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

[Liam Healy]

Marco,

If you don't mind using a foreign library, GSL provides these things
through GSLL:
GSL> gsl:+nan+
#<DOUBLE-FLOAT quiet NaN>
GSL> gsl:+positive-infinity+
#.SB-EXT:DOUBLE-FLOAT-POSITIVE-INFINITY
GSL> gsl:+negative-infinity+
#.SB-EXT:DOUBLE-FLOAT-NEGATIVE-INFINITY

This should work on any CL implementation that can load GSLL.

I'm interested in your generic math library, as I have some of that in
Antik (which GSLL uses).


Liam
On Fri, Nov 2, 2018 at 3:24 PM Antoniotti Marco

Post by Antoniotti Marco
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

[Antoniotti Marco]

Thanks

I know about GSLL. I just wanted to do something different and “mostly CL”.

Post by Liam Healy
Marco,
If you don't mind using a foreign library, GSL provides these things
GSL> gsl:+nan+
#<DOUBLE-FLOAT quiet NaN>

That is the SBCL/CMU NaN

Post by Liam Healy
GSL> gsl:+positive-infinity+
#.SB-EXT:DOUBLE-FLOAT-POSITIVE-INFINITY
GSL> gsl:+negative-infinity+
#.SB-EXT:DOUBLE-FLOAT-NEGATIVE-INFINITY
This should work on any CL implementation that can load GSLL.
I'm interested in your generic math library, as I have some of that in
Antik (which GSLL uses).

I know. I looked at Antik. This is more of a “let’s build it from scratch” student project. I will see how it pans out.

Cheers
—
Marco

Post by Liam Healy
Liam
On Fri, Nov 2, 2018 at 3:24 PM Antoniotti Marco

Post by Antoniotti Marco
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

--
Marco Antoniotti, Associate Professor tel. +39 - 02 64 48 79 01
DISCo, Università Milano Bicocca U14 2043 http://bimib.disco.unimib.it
Viale Sarca 336
I-20126 Milan (MI) ITALY

Please check: http://cdac2019.lakecomoschool.org
Please check: http://troncopackage.org
Please check: https://www.frontiersin.org/research-topics/7394/network-bioscience

Please note that I am not checking my Spam-box anymore.
Please do not forward this email without asking me first (cum g

[Daniel Herring]

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

Post by Antoniotti Marco
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

[Antoniotti Marco]

Post by Daniel Herring
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).

Thanks. That is what I was thinking...

Post by Daniel Herring
C defines fpclassify() and related predicates to return NaN, infinite, zero, subnormal, or normal.

Yes. Bu the point is that I would like to stay in CL-land as much as possible.

Post by Daniel Herring
Obligatory reference: What Every Computer Scientist Should Know About Floating-Point Arithmetic by David Goldberg
http://www-users.math.umn.edu/~arnold/disasters/patriot.html

Exactly.

Cheers
—
Marco

Post by Daniel Herring
- Daniel

Post by Antoniotti Marco
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

--
Marco Antoniotti, Associate Professor tel. +39 - 02 64 48 79 01
DISCo, Università Milano Bicocca U14 2043 http://bimib.disco.unimib.it
Viale Sarca 336
I-20126 Milan (MI) ITALY

Please check: http://cdac2019.lakecomoschool.org
Please check: http://troncopackage.org
Please check: https://www.frontiersin.org/research-topics/7394/network-bioscience

Please note that I am not checking my Spam-box anymore.
Please do not forward this email without asking me first (cum grano s

[Bob Cassels]

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.

Post by Daniel Herring
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
http://www-users.math.umn.edu/~arnold/disasters/patriot.html
- Daniel

Post by Antoniotti Marco
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

[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,

Post by Bob Cassels
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.

Post by Daniel Herring
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
http://www-users.math.umn.edu/~arnold/disasters/patriot.html
- Daniel

Post by Antoniotti Marco
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

[Bob Cassels]

[Antoniotti Marco]

Of course they are represented internally the same way other floating point values are.
Are you asking how to print those values? (Print -0.0 like that. Print + and - infinity some way they can be read by the reader. Preferably some way that's not otherwise a legal token. Probably print NaNs using the #unreadable syntax. I don't remember how that works. I don't remember what we did at Symbolics, even though I'm probably the one who did it. I can ask around, if you care.) Or something else?

Thank you.

I do not really care about printing and reading NaNs and it looks like most implementations do read and write IEEE infinities.

Th problem is that ANSI does not talk about infinities and NaNs, so the issue I have is what to do with them in a “portable” library (YMMV).

I was toying with the idea of using symbolic constants for infinities, but it looks like using IEEE infinities directly is a better - and simpler - way to follow.

Cheers
—
Marco
--
Marco Antoniotti, Associate Professor tel. +39 - 02 64 48 79 01
DISCo, Università Milano Bicocca U14 2043 http://bimib.disco.unimib.it
Viale Sarca 336
I-20126 Milan (MI) ITALY

Please check: http://cdac2019.lakecomoschool.org
Please check: http://troncopackage.org
Please check: https://www.frontiersin.org/research-topics/7394/network-bioscience

Please note that I am not checking my Spam-box anymore.
Please do not forward this email w

[Pascal Bourguignon]

Post by Antoniotti Marco

Of course they are represented internally the same way other floating point values are.
Are you asking how to print those values? (Print -0.0 like that. Print + and - infinity some way they can be read by the reader. Preferably some way that's not otherwise a legal token. Probably print NaNs using the #unreadable syntax. I don't remember how that works. I don't remember what we did at Symbolics, even though I'm probably the one who did it. I can ask around, if you care.) Or something else?

Thank you.
I do not really care about printing and reading NaNs and it looks like most implementations do read and write IEEE infinities.
Th problem is that ANSI does not talk about infinities and NaNs, so the issue I have is what to do with them in a “portable” library (YMMV).
I was toying with the idea of using symbolic constants for infinities, but it looks like using IEEE infinities directly is a better - and simpler - way to follow.

Note that there are a big number of NANs. If you want to print them readably, you definitely need a syntax able to deal with all of them, not just a couple of infinities.

[Bob Cassels]

[Bob Cassels]