Bakul Shah wrote a particularly elegant Scheme program for Chudnovskys'
algorithm for pi based on the Common Lisp program here:
https://bitbucket.org/tarballs_are_good/numericl/src/5fe8fe7089f48ab1c8a388…
Nick Craig-Wood wrote a Python program using the GMP multiprecision
library that appears to use exactly the same algorithm here:
http://www.craig-wood.com/nick/articles/pi-chudnovsky/
I modified both programs a bit and include them here.
They time the calculation of $10^n$ digits of pi for $n=1,2,3,4,5,6,7$.
The results are
heine:~/programs/gambiteer/gambit> !py
python pi_chudnovsky_bs_gmpy.py
31415926535897932384626433832795028841971693993751058209749445923078164062862089986280348253421170679
('chudnovsky_gmpy_mpz_bs: digits', 10, 'time', 1.0967254638671875e-05)
('chudnovsky_gmpy_mpz_bs: digits', 100, 'time', 3.0040740966796875e-05)
Last 5 digits 70679 OK
('chudnovsky_gmpy_mpz_bs: digits', 1000, 'time', 0.00025582313537597656)
Last 5 digits 01989 OK
('chudnovsky_gmpy_mpz_bs: digits', 10000, 'time', 0.00386810302734375)
Last 5 digits 75678 OK
('chudnovsky_gmpy_mpz_bs: digits', 100000, 'time', 0.0834801197052002)
Last 5 digits 24646 OK
('chudnovsky_gmpy_mpz_bs: digits', 1000000, 'time', 1.655979871749878)
Last 5 digits 58151 OK
('chudnovsky_gmpy_mpz_bs: digits', 10000000, 'time', 30.67442488670349)
Last 5 digits 55897 OK
heine:~/programs/gambiteer/gambit> gsi chud1.scm
Chudnovsky's algorithm using binary splitting in Gambit Scheme: digits
10, CPU time: 0..
Last 5 digits 26535.
Chudnovsky's algorithm using binary splitting in Gambit Scheme: digits
100, CPU time: 0..
Last 5 digits 70679.
Chudnovsky's algorithm using binary splitting in Gambit Scheme: digits
1000, CPU time: .004.
Last 5 digits 1989.
Chudnovsky's algorithm using binary splitting in Gambit Scheme: digits
10000, CPU time: .028.
Last 5 digits 75678.
Chudnovsky's algorithm using binary splitting in Gambit Scheme: digits
100000, CPU time: .472.
Last 5 digits 24646.
Chudnovsky's algorithm using binary splitting in Gambit Scheme: digits
1000000, CPU time: 6.448.
Last 5 digits 58151.
Chudnovsky's algorithm using binary splitting in Gambit Scheme: digits
10000000, CPU time: 98.612.
Last 5 digits 55897.
So it appears that for this algorithm applied to large integers, GMP's
bignum routines are about 3-4 times as fast as Gambit's bignum
routines. Not so bad. For smaller bignums, GMP has a bigger advantage.
The C program gmp-chudnovsky.c includes certain optimizations to this
basic algorithm:
http://gmplib.org/pi-with-gmp.htmlftp://ftp.gmplib.org/pub/misc/gmp-chudnovsky.c
On my machine, compiled with
gcc -O3 -march=native -o gmp-chudnovsky gmp-chudnovsky.c -lgmp -lm
the CPU times for 1,000,000 and 10,000,000 digits are 1.064 and 18.200
seconds, respectively.
This is with a somewhat older machine
model name : Intel(R) Core(TM)2 Quad CPU Q8200 @ 2.33GHz
running Ubuntu 13.04 with
heine:~/programs/gambiteer/gambit> gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.7/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.7.3-1ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs
--enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.7 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.7 --libdir=/usr/lib
--enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--enable-gnu-unique-object --enable-plugin --with-system-zlib
--enable-objc-gc --with-cloog --enable-cloog-backend=ppl
--disable-cloog-version-check --disable-ppl-version-check
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.7.3 (Ubuntu/Linaro 4.7.3-1ubuntu1)
heine:~/programs/gambiteer/gambit> gsi -v
v4.6.9 20130607151908 x86_64-unknown-linux-gnu "./configure
'--enable-single-host' '--enable-multiple-versions' '--enable-shared'"
and the Ubuntu-provided GMP 5.0.5. (I'm sure the GMP folks have a
better way to build GMP on my machine than the "generic" 64-bit version
provided by Ubuntu.)
Brad
Le ven. 29 janv. 2021 à 16:58, luca regini <luca.regini(a)gmail.com> a écrit :
>
> I would also be willing to contribute more to Gambit but the hard fact is that this requires a big investment of time upfront.
>
> Getting into the internals without specific documentation probably requires to invest at least 2 weeks full-time upfront.
>
> Which is not impossible if one is fully dedicated to this project ( as a student can be ) but for people with a job and a family this is impossible. I can dedicate time in bursts of 1 hours maybe 2 hours max.
>
> An idea that I could suggest is to write a commercial book describing the implementation so to sponsor some additional work on Gambit. I would be willing to buy such a book but have no idea how many other would be willing to spend money on that.
I agree I would buy a book about gambit compiler, and other internal
aspects (like how macro works).
FWIW, my plan WAS to build my own scheme that targets javascript with
Chez as host. Among other things because it is difficult, but also
because gambit is great, and I want to take part in something bigger
than myself.
I do my best to document what I am doing with gambit
(https://github.com/pre-srfi/webui/), and try to workaround some
behaviors that are not perfect or at least could be improved upon. I
can work around those.
But more important than all of the above. I agree that the compiler or
compilers must be documented. It might be the first and most important
priority to help gambit grow as a community. nanopass is overrated. It
seems to me based on a few couple hours of hacking that it is possible
to build something simpler and easier to use. Again, I am not a
compiler specialist. Maybe a nanopass is a dead end for gambit, or
maybe gambit approach is better. Who knows?
Marc, you are in the best position to describe the compiler.
[If you don't use Geiser, you can safely ignore this message]
Hi,
We have been moving support for different Scheme implementations to
separate packages (https://gitlab.com/emacs-geiser), to ease their
independent development, and we are nearly done (just waiting for the
relevant MELPA PRs to get through, they are all submitted).
So, when you next update the 'geiser' package (or git repo checkout),
you'll need to install also a separate package to support your favourite
scheme (one per implementation you need). Nothing else should change
from a user's perspective.
The new packages also remove all the autotools paraphernalia, relying on
(M)ELPA or local emacs package mechanics for installation.
I hope this won't wreak too much havoc with your workflows, but please
let me know if there's anything we can do to ease the transition if it
is disruptive in your case.
Thanks a lot for using Geiser!
Happy hacking,
jao
--
All parts should go together without forcing. You must remember that
the parts you are reassembling were disassembled by you. Therefore, if
you can’t get them together again, there must be a reason. By all
means, do not use a hammer. —IBM Manual, 1925
================================================================================
IFL 2021
33rd Symposium on Implementation and Application of Functional Languages
venue: online
1 - 3 September 2021
https://ifl21.cs.ru.nl
<https://ifl21-publicity-dot-yamm-track.appspot.com/Redirect?ukey=1NdKhGOLpm…>
================================================================================
Scope
The goal of the IFL symposia is to bring together researchers actively
engaged
in the implementation and application of functional and function-based
programming languages. IFL 2021 will be a venue for researchers to present
and
discuss new ideas and concepts, work in progress, and publication-ripe
results
related to the implementation and application of functional languages and
function-based programming.
Industrial track and topics of interest
This year's edition of IFL explicitly solicits original work concerning
*applications*
of functional programming in industry and academia. These contributions
will be reviewed by experts with an industrial background.
Topics of interest to IFL include, but are not limited to:
* language concepts
* type systems, type checking, type inferencing
* compilation techniques
* staged compilation
* run-time function specialisation
* run-time code generation
* partial evaluation
* (abstract) interpretation
* meta-programming
* generic programming
* automatic program generation
* array processing
* concurrent/parallel programming
* concurrent/parallel program execution
* embedded systems
* web applications
* (embedded) domain-specific languages
* security
* novel memory management techniques
* run-time profiling performance measurements
* debugging and tracing
* testing and proofing
* virtual/abstract machine architectures
* validation, verification of functional programs
* tools and programming techniques
* applications of functional programming in the industry, including
** functional programming techniques for large applications
** successes of the application functional programming
** challenges for functional programming encountered
** any topic related to the application of functional programming that is
interesting for the IFL community
Post-symposium peer-review
Following IFL tradition, IFL 2021 will use a post-symposium review process
to
produce the formal proceedings.
Before the symposium authors submit draft papers. These draft papers will
be
screened by the program chairs to make sure that they are within the scope
of
IFL. The draft papers will be made available to all participants at the
symposium. Each draft paper is presented by one of the authors at the
symposium.
After the symposium every presenter is invited to submit a full paper,
incorporating feedback from discussions at the symposium. Work submitted to
IFL
may not be simultaneously submitted to other venues; submissions must
adhere to ACM SIGPLAN's republication policy. The program committee will
evaluate these submissions according to their correctness, novelty,
originality,
relevance, significance, and clarity, and will thereby determine whether
the
paper is accepted or rejected for the formal proceedings. We plan to
publish
these proceedings in the International Conference Proceedings Series of the
ACM Digital Library, as in previous years. Moreover, the proceedings will
also
be made publicly available as open access.
Important dates
Submission deadline of draft papers: 17 August 2021
Notification of acceptance for presentation: 19 August 2021
Registration deadline: 30 August 2021
IFL Symposium: 1-3 September 2021
Submission of papers for proceedings: 6 December 2021
Notification of acceptance: 3 February 2022
Camera-ready version: 15 March 2022
### Submission details
All contributions must be written in English. Papers must use the ACM two
columns conference format, which can be found at:
http://www.acm.org/publications/proceedings-template
<https://ifl21-publicity-dot-yamm-track.appspot.com/Redirect?ukey=1NdKhGOLpm…>
Peter Landin Prize
The Peter Landin Prize is awarded to the best paper presented at the
symposium every year. The honoured article is selected by the program
committee
based on the submissions received for the formal review process. The prize
carries a cash award equivalent to 150 Euros.
Organisation
IFL 2021 Chairs: Pieter Koopman and Peter Achten, Radboud University, The
Netherlands
IFL Publicity chair: Pieter Koopman, Radboud University, The Netherlands
PC (under construction):
Peter Achten (co-chair) - Radboud University, Netherlands
Thomas van Binsbergen - University of Amsterdam, Netherlands
Edwin Brady - University of St. Andrews, Scotland
Laura Castro - University of A Coruña, Spain
Youyou Cong - Tokyo Institute of Technology, Japan
Olaf Chitil - University of Kent, England
Andy Gill - University of Kansas, USA
Clemens Grelck - University of Amsterdam, Netherlands
John Hughes - Chalmers University, Sweden
Pieter Koopman (co-chair) - Radboud University, Netherlands
Cynthia Kop - Radboud University, Netherlands
Jay McCarthey - University of Massachussetts Lowell, USA
Neil Mitchell - Facebook, England
Jan De Muijnck-Hughes - Glasgow University, Scotland
Keiko Nakata - SAP Innovation Center Potsdam, Germany
Jurriën Stutterheim - Standard Chartered, Singapore
Simon Thompson - University of Kent, England
Melinda Tóth - Eötvos Loránd University, Hungary
Phil Trinder - Glasgow University, Scotland
Meng Wang - University of Bristol, England
Viktória Zsók - Eötvos Loránd University, Hungary
Virtual symposium
Because of the Covid-19 pandemic, this year IFL 2021 will be an online
event,
consisting of paper presentations, discussions and virtual social
gatherings.
Registered participants can take part from anywhere in the world.
Acknowledgments
This call-for-papers is an adaptation and evolution of content from previous
instances of IFL. We are grateful to prior organisers for their work, which
is reused here.
[image: beacon]