Thanks

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

On Nov 2, 2018, at 21:12 , Liam Healy lhealy@common-lisp.net wrote:

Marco,

If you don't mind using a foreign library, GSL provides these things through GSLL: GSL> gsl:+nan+ #<DOUBLE-FLOAT quiet NaN>

That is the SBCL/CMU 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).

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

Liam On Fri, Nov 2, 2018 at 3:24 PM Antoniotti Marco antoniotti.marco@disco.unimib.it 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

-- 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 salis).

On Nov 3, 2018, at 24:54 , Bob Cassels bobcassels@netscape.net wrote:

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 without asking me first (cum grano salis).

On 3 Nov 2018, at 13:26, Antoniotti Marco antoniotti.marco@disco.unimib.it wrote:

...

On Nov 3, 2018, at 24:54 , Bob Cassels bobcassels@netscape.net wrote:

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.

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