pro

pro@common-lisp.net

1 participants
346 discussions

[Last CfP] 17th European Lisp Symposium, May 6-7 2024, Vienna
by Didier Verna 18 Feb '24

18 Feb '24

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 17th European Lisp Symposium Call for Papers May 6-7 2024 Federal Computing Center, Vienna, Austria https://www.european-lisp-symposium.org/2024 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Important Dates ~~~~~~~~~~~~~~~ - Submission deadline: Feb. 25 2024 ** EXTENDED ** - Author notification: Mar. 24 2024 - Final papers due: Apr. 14 2024 - Symposium: May 6-7 2024 Scope ~~~~~ The European Lisp Symposium is a premier forum for the discussion and dissemination of all aspects of design, implementation, and application of any of the Lisp dialects, including Common Lisp, Scheme, Emacs Lisp, Clojure, Racket, ACL2, AutoLisp, ISLISP, Dylan, SKILL, Hy, Shen, Carp, Janet, uLisp, Picolisp, Gamelisp, TXR, and so on. We encourage everyone interested in Lisp to participate. The European Lisp Symposium invites high quality papers about novel research results, insights and lessons learned from practical applications, and educational perspectives. We also encourage submissions about known ideas as long as they are presented in a new setting and/or in a highly elegant way. Topics include but are not limited to: - context-, aspect-, domain-oriented and generative programming - macro-, reflective-, meta- and/or rule-based development approaches - language design and implementation - language integration, inter-operation, and deployment - development methodologies, support, and environments - educational approaches and perspectives - experience reports and case studies This year, we suggest an emphasis on best practices, approaches, and technologies for building highly recursive and self-adapting architectures, in particular for AI, ML, tool integration and instruction generation, using dynamic programming languages. Technical Program ~~~~~~~~~~~~~~~~~ We invite submissions in the following forms. * Papers: technical papers of up to 8 pages that describe original results or explain known ideas in new and elegant ways. * Experience reports: papers of up to 6 pages describing a successful use of a Lisp dialect and/or analyzing obstacles that have kept it from working in practice. * Tutorials: abstracts of up to 4 pages for in-depth presentations about topics of special interest. * Demonstrations: abstracts of up to 4 pages for demonstrations of tools, libraries, and applications. All submissions should be formatted following the ACM SIGS guidelines and include ACM Computing Classification System 2012 concepts and terms. Submissions should be uploaded to Easy Chair, at the following link http://www.easychair.org/conferences/?conf=els2024. Note: to help us with the review process please indicate the type of submission by entering either "paper", "demo", or "tutorial" in the Keywords field. Programme Chair ~~~~~~~~~~~~~~~ Giuseppe Attardi, University of Pisa, Italy Organizing Chair ~~~~~~~~~~~~~~~~ Didier Verna, EPITA, France Programme Committee ~~~~~~~~~~~~~~~~~~~ Ambrose Bonnaire-Sergeant, Untypable LLC Frederic Peschanski, UPMC/LIP6 Jay McCarthy, UMass Lowell Jim Newton, EPITA Research Lab Kai Selgrad, OTH Regensburg Mark Evenson, not.org Michael Raskin, LaBRI/CNRS UMR 5800, University of Bordeaux Robert Smith, HRL Laboratories LLC Robert P. Goldman, SIFT LLC Stefan Monnier, Université de Montréal Local Chair ~~~~~~~~~~~ Philipp Marek, BRZ, Vienna, Austria Virtualization Team ~~~~~~~~~~~~~~~~~~~ Georgiy Tugai, Configura, Sweden Michal Herda, Poland Yukari Hafner, Shirakumo.org, Switzerland -- Resistance is futile. You will be jazzimilated. Jazz site: http://www.didierverna.com Other sites: http://www.didierverna.info

1 0

Academic endian question
by Marco Antoniotti 06 Feb '24

06 Feb '24

Hello everybody, I am in a rabbit hole (don't ask!), and I need to drag some other people with me. What is the consensus about the most portable way to detect the endianness of a machine/platform? (Ok, we can assume that while running on an ARM the endianness is "fixed" by the OS) All the best MA -- Marco Antoniotti, Professor tel. +39 - 02 64 48 79 01 DISCo, Università Milano Bicocca U14 2043 http://dcb.disco.unimib.it Viale Sarca 336 I-20126 Milan (MI) ITALY

5 6

[CfP] 17th European Lisp Symposium, May 6-7 2024, Vienna, Austria
by Didier Verna 19 Jan '24

19 Jan '24

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 17th European Lisp Symposium Call for Papers May 6-7 2024 Federal Computing Center, Vienna, Austria https://www.european-lisp-symposium.org/2024 Sponsored by EPITA ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Important Dates ~~~~~~~~~~~~~~~ - Submission deadline: Feb. 18 2024 - Author notification: Mar. 24 2024 - Final papers due: Apr. 14 2024 - Symposium: May 6-7 2024 Scope ~~~~~ The European Lisp Symposium is a premier forum for the discussion and dissemination of all aspects of design, implementation, and application of any of the Lisp dialects, including Common Lisp, Scheme, Emacs Lisp, Clojure, Racket, ACL2, AutoLisp, ISLISP, Dylan, SKILL, Hy, Shen, Carp, Janet, uLisp, Picolisp, Gamelisp, TXR, and so on. We encourage everyone interested in Lisp to participate. The European Lisp Symposium invites high quality papers about novel research results, insights and lessons learned from practical applications, and educational perspectives. We also encourage submissions about known ideas as long as they are presented in a new setting and/or in a highly elegant way. Topics include but are not limited to: - context-, aspect-, domain-oriented and generative programming - macro-, reflective-, meta- and/or rule-based development approaches - language design and implementation - language integration, inter-operation, and deployment - development methodologies, support, and environments - educational approaches and perspectives - experience reports and case studies This year, we suggest an emphasis on best practices, approaches, and technologies for building highly recursive and self-adapting architectures, in particular for AI, ML, tool integration and instruction generation, using dynamic programming languages. Technical Program ~~~~~~~~~~~~~~~~~ We invite submissions in the following forms. * Papers: technical papers of up to 8 pages that describe original results or explain known ideas in new and elegant ways. * Experience reports: papers of up to 6 pages describing a successful use of a Lisp dialect and/or analyzing obstacles that have kept it from working in practice. * Tutorials: abstracts of up to 4 pages for in-depth presentations about topics of special interest. * Demonstrations: abstracts of up to 4 pages for demonstrations of tools, libraries, and applications. All submissions should be formatted following the ACM SIGS guidelines and include ACM Computing Classification System 2012 concepts and terms. Submissions should be uploaded to Easy Chair, at the following link http://www.easychair.org/conferences/?conf=els2024. Note: to help us with the review process please indicate the type of submission by entering either "paper", "demo", or "tutorial" in the Keywords field. Programme Chair ~~~~~~~~~~~~~~~ Giuseppe Attardi, University of Pisa, Italy Programme Committee ~~~~~~~~~~~~~~~~~~~ Ambrose Bonnaire-Sergeant, Untypable LLC Frederic Peschanski, UPMC/LIP6 Jay McCarthy, UMass Lowell Jim Newton, EPITA Research Lab Kai Selgrad, OTH Regensburg Mark Evenson, not.org Michael Raskin, LaBRI/CNRS UMR 5800, University of Bordeaux Robert Smith, HRL Laboratories LLC Robert P. Goldman, SIFT LLC Stefan Monnier, Université de Montréal Local Chair ~~~~~~~~~~~ Philipp Marek, BRZ, Vienna, Austria Virtualization Team ~~~~~~~~~~~~~~~~~~~ Georgiy Tugai, Configura, Sweden Michał Herda, Poland Yukari Hafner, Shirakumo.org, Switzerland -- Resistance is futile. You will be jazzimilated. Jazz site: http://www.didierverna.com Other sites: http://www.didierverna.info

1 0

Re: Help with bit bashing code: differences between C and CL
by Bob Cassels 14 Nov '23

14 Nov '23

Yes, that’s the Steele (and JonL) paper I was thinking of. > On Nov 13, 2023, at 2:16 AM, raymond.wiker(a)icloud.com wrote: > > “How to Print Floating-Point Numbers Accurately”, perhaps? > > https://lists.nongnu.org/archive/html/gcl-devel/2012-10/pdfkieTlklRzN.pdf > >> On 10 Nov 2023, at 12:37, bobcassels(a)netscape.net wrote: >> >> I did the Symbolics Lisp Machine implementation of floating point print. Mine was completely accurate, using exact rational arithmetic with bignums. But not very efficient. >> >> I have seen papers showing how to be accurate with fixed precision arithmetic. It requires great care. I believe that some C or C++ implementations use this procedure. So I would not be surprised if some implementation of floating point printing is incorrect. >> >> I have a vague recollection of some paper by Guy Steele on the subject. I recall using ideas from Bill Gosper's continued fraction work. >> >> >> On Nov 10, 2023 5:39 AM, Marco Antoniotti <marco.antoniotti(a)unimib.it> wrote: >> Thank you. >> >> I have not checked the details, but are you implying that clang printf is... buggy? Knuth has such a caveat (about buggy printf implementations) on his page. >> >> All the best >> >> Marco >> >> >> On Fri, Nov 10, 2023 at 11:35 AM <raymond.wiker(a)icloud.com <mailto:raymond.wiker@icloud.com>> wrote: >> I think that clang is simply printing more information than it is allowed (or supposed) to. For a double-precision IEEE754 float, the number of significant digits should be >> >> (floor (* 54.0d0 (/ (log 2.0d0) (log 10.0d0)))) >> >> which evaluates to 16 (53-bit mantissa + 1 hidden digit). The Lisp output has exactly 16 significant digits, while the clang output has 20. >> >> The actual correct digits seem to be >> >> (ash (expt 10 52) -52) >> >> which evaluates to >> >> 2220446049250313080847263336181640625. >> >> >> >> >> >> On 10 Nov 2023, at 09:55, Marco Antoniotti (as marco dot antoniotti at unimib dot it) <lisp-hug(a)lispworks.com <mailto:lisp-hug@lispworks.com>> wrote: >> >> Hi >> >> Thanks Pascal. >> >> For LW on Intel (Mac) the ULP seems the same. With SBCL you should actually be able to peek at the actual bits making up the double float. Can you do something similar with LM? >> >> Just curious: has anybody tried this on a M*/Arm Mac? Or, with LW, on your smartphone? :) >> >> Cheers >> >> MA >> >> >> On Fri, Nov 10, 2023 at 8:29 AM Pascal Bourguignon (as pjb at informatimago dot com) <lisp-hug(a)lispworks.com <mailto:lisp-hug@lispworks.com>> wrote: >> >> >> On 9 Nov 2023, at 21:21, Marco Antoniotti <marco.antoniotti(a)unimib.it <mailto:marco.antoniotti@unimib.it>> wrote: >> >> <problem-loop.lisp> >> >> >> From the start, it looks like the ulp is more precise in C: >> >> >> sbcl: 2.220446049250313d-16 >> clang: 2.2204460492503130808e-16 >> >> (using %.20g instead of %.20f) >> >> Or perhaps it’s only the display procedure that truncates in lisp? >> >> -- >> __Pascal J. Bourguignon__ >> >> >> >> >> >> >

1 1

Re: Help with bit bashing code: differences between C and CL
by Marco Antoniotti 13 Nov '23

13 Nov '23

Thank you Raymond. Yes I am aware of the paper and of the vagaries of printing floats FROM binary. I was, at this point, going in the reverse: printing the binary representation of a float. Having said that, I love the sentence in the paper "we did not think it was such a big deal". It looks like it still is 🙄 Also, an ode to Common Lisp (preaching to the choir): the code I wrote is, IMHO, somewhat more portable than the C versions I saw around, thanks to all the float introspection functions and the (let's say it! underdocumented) DECODE-FLOAT and INTEGER-DECODE-FLOAT functions. All the best Marco On Mon, Nov 13, 2023 at 8:17 AM <raymond.wiker(a)icloud.com> wrote: > “How to Print Floating-Point Numbers Accurately”, perhaps? > > https://lists.nongnu.org/archive/html/gcl-devel/2012-10/pdfkieTlklRzN.pdf > > On 10 Nov 2023, at 12:37, bobcassels(a)netscape.net wrote: > > I did the Symbolics Lisp Machine implementation of floating point print. > Mine was completely accurate, using exact rational arithmetic with bignums. > But not very efficient. > > I have seen papers showing how to be accurate with fixed precision > arithmetic. It requires great care. I believe that some C or C++ > implementations use this procedure. So I would not be surprised if some > implementation of floating point printing is incorrect. > > I have a vague recollection of some paper by Guy Steele on the subject. I > recall using ideas from Bill Gosper's continued fraction work. > > > On Nov 10, 2023 5:39 AM, Marco Antoniotti <marco.antoniotti(a)unimib.it> > wrote: > > Thank you. > > I have not checked the details, but are you implying that clang printf > is... buggy? Knuth has such a caveat (about buggy printf implementations) > on his page. > > All the best > > Marco > > > On Fri, Nov 10, 2023 at 11:35 AM <raymond.wiker(a)icloud.com> wrote: > > I think that clang is simply printing more information than it is allowed > (or supposed) to. For a double-precision IEEE754 float, the number of > significant digits should be > > (floor (* 54.0d0 (/ (log 2.0d0) (log 10.0d0)))) > > which evaluates to 16 (53-bit mantissa + 1 hidden digit). The Lisp output > has exactly 16 significant digits, while the clang output has 20. > > The actual correct digits seem to be > > (ash (expt 10 52) -52) > > which evaluates to > > 2220446049250313080847263336181640625. > > > > > > On 10 Nov 2023, at 09:55, Marco Antoniotti (as marco dot antoniotti at > unimib dot it) <lisp-hug(a)lispworks.com> wrote: > > Hi > > Thanks Pascal. > > For LW on Intel (Mac) the ULP seems the same. With SBCL you should > actually be able to peek at the actual bits making up the double float. > Can you do something similar with LM? > > Just curious: has anybody tried this on a M*/Arm Mac? Or, with LW, on > your smartphone? :) > > Cheers > > MA > > > On Fri, Nov 10, 2023 at 8:29 AM Pascal Bourguignon (as pjb at > informatimago dot com) <lisp-hug(a)lispworks.com> wrote: > > > > On 9 Nov 2023, at 21:21, Marco Antoniotti <marco.antoniotti(a)unimib.it> > wrote: > > <problem-loop.lisp> > > > > From the start, it looks like the ulp is more precise in C: > > > sbcl: 2.220446049250313d-16 > clang: 2.2204460492503130808e-16 > > (using %.20g instead of %.20f) > > Or perhaps it’s only the display procedure that truncates in lisp? > > -- > __Pascal J. Bourguignon__ > > > > > > > >

1 0

Help with bit bashing code: differences between C and CL
by Marco Antoniotti 12 Nov '23

12 Nov '23

Dear all, I am hitting a wall with the attached code in CL and C versions. For those interested, this is code lifted from Knuth's pages on random number generation (https://www-cs-faculty.stanford.edu/~knuth/programs.html#rng). The problem is that there is a discrepancy in the "problem" loop between the CL and the C and I cannot figure out why, although the culprit may be that CL does not have "proper" 64 bits ints. I am running on LW 8.x on an Intel Mac. I have not tried on other CL implementations/platforms. I compile the C code with clang (Apple clang version 15.0.0 (clang-1500.0.40.1) If you run the code, you will see that the discrepancy appears at 'j = 14' in the loop. What gives? Thanks Marco -- Marco Antoniotti, Professor tel. +39 - 02 64 48 79 01 DISCo, Università Milano Bicocca U14 2043 http://dcb.disco.unimib.it Viale Sarca 336 I-20126 Milan (MI) ITALY

3 4

Re: Help with bit bashing code: differences between C and CL
by Marco Antoniotti 10 Nov '23

10 Nov '23

Thank you. I have not checked the details, but are you implying that clang printf is... buggy? Knuth has such a caveat (about buggy printf implementations) on his page. All the best Marco On Fri, Nov 10, 2023 at 11:35 AM <raymond.wiker(a)icloud.com> wrote: > I think that clang is simply printing more information than it is allowed > (or supposed) to. For a double-precision IEEE754 float, the number of > significant digits should be > > (floor (* 54.0d0 (/ (log 2.0d0) (log 10.0d0)))) > > which evaluates to 16 (53-bit mantissa + 1 hidden digit). The Lisp output > has exactly 16 significant digits, while the clang output has 20. > > The actual correct digits seem to be > > (ash (expt 10 52) -52) > > which evaluates to > > 2220446049250313080847263336181640625. > > > > > > On 10 Nov 2023, at 09:55, Marco Antoniotti (as marco dot antoniotti at > unimib dot it) <lisp-hug(a)lispworks.com> wrote: > > Hi > > Thanks Pascal. > > For LW on Intel (Mac) the ULP seems the same. With SBCL you should > actually be able to peek at the actual bits making up the double float. > Can you do something similar with LM? > > Just curious: has anybody tried this on a M*/Arm Mac? Or, with LW, on > your smartphone? :) > > Cheers > > MA > > > On Fri, Nov 10, 2023 at 8:29 AM Pascal Bourguignon (as pjb at > informatimago dot com) <lisp-hug(a)lispworks.com> wrote: > >> >> >> On 9 Nov 2023, at 21:21, Marco Antoniotti <marco.antoniotti(a)unimib.it> >> wrote: >> >> <problem-loop.lisp> >> >> >> >> From the start, it looks like the ulp is more precise in C: >> >> >> sbcl: 2.220446049250313d-16 >> clang: 2.2204460492503130808e-16 >> >> (using %.20g instead of %.20f) >> >> Or perhaps it’s only the display procedure that truncates in lisp? >> >> -- >> __Pascal J. Bourguignon__ >> >> >> >> >> >

2 1

Re: Help with bit bashing code: differences between C and CL
by Marco Antoniotti 09 Nov '23

09 Nov '23

Thanks. This is weird. The C and Fortran versions seem to agree. Marco On Thu, Nov 9, 2023 at 9:49 PM Frank Gönninger | Gönninger B&T < frank.goenninger(a)goenninger.net> wrote: > Hi Marco, > > > > on AllegroCL 11.0 beta Enterprise Edition I get diverging results starting > at j = 21… > > > > Lisp: j = 21; ss = 0.00028959847986698150 > > C: j = 21; ss = 0.00028959847986698151 > > > > FWIW … > > > > Best, > > Frank > > > > *Von: *<owner-lisp-hug(a)lispworks.com> im Auftrag von "Marco Antoniotti > (as marco dot antoniotti at unimib dot it)" <lisp-hug(a)lispworks.com> > *Antworten an: *Marco Antoniotti <marco.antoniotti(a)unimib.it> > *Datum: *Donnerstag, 9. November 2023 um 21:23 > *An: *LispWorks <lisp-hug(a)lispworks.com>, Discussion list for Common Lisp > professionals <pro(a)common-lisp.net> > *Betreff: *Help with bit bashing code: differences between C and CL > > > > Dear all, > > > > I am hitting a wall with the attached code in CL and C versions. For > those interested, this is code lifted from Knuth's pages on random number > generation (https://www-cs-faculty.stanford.edu/~knuth/programs.html#rng). > > The problem is that there is a discrepancy in the "problem" loop between > the CL and the C and I cannot figure out why, although the culprit may be > that CL does not have "proper" 64 bits ints. > > I am running on LW 8.x on an Intel Mac. I have not tried on other CL > implementations/platforms. I compile the C code with clang (Apple clang > version 15.0.0 (clang-1500.0.40.1) > > > > If you run the code, you will see that the discrepancy appears at 'j = 14' > in the loop. > > > > What gives? > > Thanks > > Marco > > > > > > > -- > > Marco Antoniotti, Professor tel. +39 - 02 64 48 79 01 > DISCo, Università Milano Bicocca U14 2043 http://dcb.disco.unimib.it > Viale Sarca 336 > I-20126 Milan (MI) ITALY >

2 1

Re: Common Lisp Transformer Libraries
by Marco Antoniotti 14 Aug '23

14 Aug '23

Hi Burton no. I have not heard of anything similar, except maybe from Mark Watson (who should be on these lists - markwatson.com). I became interested in them as well. In any case, the issue is whether you are interested in a CL implementation or a binding to this or that C/C++ library (yeah! I refrain from mentioning languages susceptible to the 'irsabol attack' 😑 ). All the best Marco On Sat, Aug 12, 2023 at 2:38 AM Burton John Samograd (as burtonjohnsamograd at protonmail dot com) <lisp-hug(a)lispworks.com> wrote: > Hello, > > I was wondering if anybody on this list (or anybody you might know) has > heard or had experience with a Common Lisp "Transformer" library, as in > Transformer from Generalized Pre-trained Transformer (GPT). > > I'd like to do some experimentation and was wondering if there was any > previous work that has been done that can be used. > > -- > Burton John Samograd > burtonjohnsamograd(a)protonmail.com > http://burton.samograd.ca/ > 2023 > > Sent with Proton Mail <https://proton.me/> secure email. > > ------- Forwarded Message ------- > From: Burton John Samograd <burtonjohnsamograd(a)protonmail.com> > Date: On Friday, August 11th, 2023 at 5:33 PM > Subject: Common Lisp Transformer Libraries > To: pro(a)common-lisp.net <pro(a)common-lisp.net> > > Hello, > > I was wondering if anybody on this list (or anybody you might know) has > heard or had experience with a Common Lisp "Transformer" library, as in > Transformer from Generalized Pre-trained Transformer (GPT). > > I'd like to do some experimentation and was wondering if there was any > previous work that has been done that can be used. > > Thank you. > > -- > Burton John Samograd > burtonjohnsamograd(a)protonmail.com > 2023 > > Sent with Proton Mail <https://proton.me/> secure email. > > >

4 4

Common Lisp Transformer Libraries
by Burton John Samograd 11 Aug '23

11 Aug '23

Hello, I was wondering if anybody on this list (or anybody you might know) has heard or had experience with a Common Lisp "Transformer" library, as in Transformer from Generalized Pre-trained Transformer (GPT). I'd like to do some experimentation and was wondering if there was any previous work that has been done that can be used. Thank you. -- Burton John Samograd burtonjohnsamograd(a)protonmail.com 2023 Sent with [Proton Mail](https://proton.me/) secure email.

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

pro