Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > gnu.emacs.help > #60981 > unrolled thread

thanks - calculate pi fn. in elisp

Back to article view | Back to gnu.emacs.help

Contents

  thanks - calculate pi fn. in elisp Richard Smith <null@void.com> - 2024-07-09 19:48 +0100
    TCO with named-let via macros (was: thanks - calculate pi fn. in elisp) Axel Reichert <mail@axel-reichert.de> - 2024-07-09 23:15 +0200
      Re: TCO with named-let via macros Richard Smith <null@void.com> - 2024-07-10 06:28 +0100
        Re: TCO with named-let via macros steve g <sgonedes1977@gmail.com> - 2024-08-10 15:56 -0400
          Re: TCO with named-let via macros Richard Smith <null@void.com> - 2024-08-10 22:28 +0100
      Re: TCO with named-let via macros Richard Smith <null@void.com> - 2024-07-10 06:36 +0100
        Re: TCO with named-let via macros steve g <sgonedes1977@gmail.com> - 2024-08-10 16:22 -0400
          Re: TCO with named-let via macros Axel Reichert <mail@axel-reichert.de> - 2024-08-10 23:15 +0200
            Re: TCO with named-let via macros steve g <sgonedes1977@gmail.com> - 2024-08-11 14:56 -0400
            Re: TCO with named-let via macros Richard Smith <null@void.com> - 2025-04-08 10:26 +0100
      Re: TCO with named-let via macros Richard Smith <null@void.com> - 2024-07-10 06:59 +0100
      Re: TCO with named-let via macros Richard Smith <null@void.com> - 2024-07-10 09:18 +0100
        Re: TCO with named-let via macros steve g <sgonedes1977@gmail.com> - 2024-08-10 16:26 -0400
          Re: TCO with named-let via macros Richard Smith <null@void.com> - 2024-08-10 22:51 +0100

#60981 — thanks - calculate pi fn. in elisp

I know this is "help" and for emacs as a program,
but for what it's worth,
sort of as a thanks,
this is what I as a welder and bit of an engineer managed to do
readily on finding there is a formula for calculating the value of
pi...

You will know better ways, but this "scribble" was a nice bit of
learning maths.

Thanks everyone for help along the way

Rich S

--------------------------------

(setq max-lisp-eval-depth (expt 2 20))

(defun h-invnsq (this-n invnsq-sum)
  (if (zerop this-n)
      invnsq-sum
    (h-invnsq (1- this-n) (+ invnsq-sum (/ 1e0 (expt this-n 2))))))

(defun pi-calc (n-to)
  "calculates Pi - arg integer is to how 1/n^2 integer to sum"
  (sqrt (* 6 (h-invnsq n-to 0))))

(= (sqrt 6) (pi-calc 1)) ;; t
(pi-calc 10)    ;; 3.04936163598207
(pi-calc 100)   ;; 3.132076531809106
(pi-calc 1000)  ;; 3.140638056205993
(pi-calc 10000) ;; 3.1414971639472093
             pi ;; 3.141592653589793

[toc] | [next] | [standalone]

#60982 — TCO with named-let via macros (was: thanks - calculate pi fn. in elisp)

Richard Smith <null@void.com> writes:
>
> You will know better ways, but this "scribble" was a nice bit of
> learning maths.

I can imagine. Maths and Lisp are fascinating mind games.   (:

Some comments ...

> (setq max-lisp-eval-depth (expt 2 20))

This sets some limit for stack recursion to some high value. My
understanding is that this is not the number of recursive calls, but
something different, which I could not find out. Pointers appreciated.

> (defun h-invnsq (this-n invnsq-sum)
>   (if (zerop this-n)
>       invnsq-sum
>     (h-invnsq (1- this-n) (+ invnsq-sum (/ 1e0 (expt this-n 2))))))

So here h-invnsq calls itself, with a different set of arguments, and
this is the last action within this function, no matter the outcome of
the "if". So h-invnsq is in "tail position". Other Lisps will transform
a recursive call in tail position into a simple jump ("goto"). This is
required behaviour for all Scheme implementations, but some Common Lisp
implementations, e.g., SBCL, will do it as well.

Unfortunately, Emacs Lisp does not do this TCO ("Tail Call
Optimization"), with the exception of named-let. So I have taken to the
habit of writing recursive stuff not only with tail calls (where
possible, and this often mandates "helper functions", in your case
"pi-calc", kind of initializing the recursive "workhorse"), but also
with "named-let", to reap the benefits of TCO.

Your example would then look like this:

(defun pi-calc (n-to)
  "calculates Pi - arg integer is to how 1/n^2 integer to sum"
  (named-let h-invnsq ((this-n n-to)
                       (invnsq-sum 0))
    (if (zerop this-n)
        (sqrt (* 6 invnsq-sum))
      (h-invnsq (1- this-n) (+ invnsq-sum (/ 1.0 (expt this-n 2)))))))

So this-n gets bound to n-to and invnsq-sum to 0 (this is the "let"
part; as you know, let is used for local bindings). However, this also
names a function (this is the "named" part of "named-let") which can
then be called in the body of the named-let (guaranteering TCO).

(pi-calc 1000000)

will then work fine without increasing "max-lisp-eval-depth".

Now if you think this boilerplate code is annoying, then I am with
you. Fortunately, since all Lisps are extremely malleable languages
(think metal plasticity ...), automation of this is just a macro (not:
keyboard macro) away:

(defmacro defun-tco (name args body)
  "Wraps a 'named-let' around BODY to have a TCO of function NAME with ARGS."
  (declare (indent defun))
  (let ((bindings (gensym)))
    (setq bindings (mapcar #'(lambda (arg) (list arg arg)) args))
    `(defun ,name ,args
       (named-let ,name ,bindings
         ,body))))

Ignore the "declare" and the "gensym" for now. With this, you can simply
do

(defun-tco pi-calc (this-n invnsq-sum)
  (if (zerop this-n)
      (sqrt (* 6 invnsq-sum))
    (pi-calc (1- this-n) (+ invnsq-sum (/ 1.0 (expt this-n 2))))))

and then call

(pi-calc 1000000 0)

without exploding the stack. There is room for improvement (neither
support for good-practice docstrings nor local variables eliminating the
need to give two arguments to "pi-calc"), but I am sure the Emacs Lisp
gurus here could help with this. It was meant as a brief sketch. For a
discussion on optional docstrings in macros (Common Lisp, not Emacs
Lisp), see

  https://stackoverflow.com/questions/66364347/correct-way-to-incorporate-a-docstring-in-a-def-macro

Best regards

Axel

[toc] | [prev] | [next] | [standalone]

#60983 — Re: TCO with named-let via macros

Thanks Axel
Regarding the second approach;
I have read
* Paul Graham's "On Lisp"
* Siebel's "Practical Common Lisp"
so have seen things like "gensym" and why has to be so.

Reality is, with very not-advanced lisp basics I seem to do well.

In my world of melting and shaping metal, there seems to be something
good about the working environment of equations and explanations in one
document.  It seems to facilitate a person developing their thoughts.

This seems to be the biggest issue - what the environment makes readily
and enjoyably achievable.

In recent years

* every beam calculation I want to do
  (Euler-Bernoulli beam - derived 1750's; applied eg. Eiffel 1880's-ish)
  which I do use frequently in my welding and engineering work

* a 1-D computer-numerical solution for heat-flow which proves a useful
  "nutcracker" for considering what's going on where the issue is
  conductive heat transfer

* in mineral processing (considering processing metal ores - tin,
  copper, etc) I can run through calculations actually feeling very
  happy

Mineral processing was last new application, a couple of months ago.
I'm surrounded by abandoned mines here - some of the iconic images of
Cornwall.  With for me the crucial thing being that tin-mining is
restarting here.  There's also lithium here - efforts to work that.
None of these metals "self-extract" from the "run-of-mine" ore.
Hence mineral processing as an expertise.

Thing is, those happily-done calculations enabled me to see the
twists-and-turns the author, with decades of experience of mineral
processing, could throw at you to get you to think through the issue.
Layers deeper than the text alone could take you.

I had to visualise the minerals and mineral streams, then draw sketches
which were my "model", then derive the maths (concurred with the
author's equations) - then write the elisp functions and get the
answers.
No immediate jobs so having to get back to welding - but could return to
remind of the logical path which worked for me, in those files, whenever.

These were all "trivial" algebraic expressions, in computing terms.

I appreciate you showing me
where I could take my computing
if that juncture came.

Regards,
Rich Smith

[toc] | [prev] | [next] | [standalone]

#60990 — Re: TCO with named-let via macros

Richard Smith <null@void.com> writes:

> Thanks Axel
> Regarding the second approach;
> I have read
> * Paul Graham's "On Lisp"
> * Siebel's "Practical Common Lisp"
> so have seen things like "gensym" and why has to be so.
>
> Reality is, with very not-advanced lisp basics I seem to do well.

yeah me too :)

>
> In my world of melting and shaping metal, there seems to be something
> good about the working environment of equations and explanations in one
> document.  It seems to facilitate a person developing their thoughts.

I so agree! I thread and weld pipe for fire suppression systems. we use
hydraulic calculations; if you can do this you are golden...

>
> This seems to be the biggest issue - what the environment makes readily
> and enjoyably achievable.
>
> In recent years
>
> * every beam calculation I want to do
>   (Euler-Bernoulli beam - derived 1750's; applied eg. Eiffel 1880's-ish)
>   which I do use frequently in my welding and engineering work
>


> * a 1-D computer-numerical solution for heat-flow which proves a useful
>   "nutcracker" for considering what's going on where the issue is
>   conductive heat transfer


Oh yeah! another heat transfer variable :)
>
> * in mineral processing (considering processing metal ores - tin,
>   copper, etc) I can run through calculations actually feeling very
>   happy
>
> Mineral processing was last new application, a couple of months ago.
> I'm surrounded by abandoned mines here - some of the iconic images of
> Cornwall.  With for me the crucial thing being that tin-mining is
> restarting here.  There's also lithium here - efforts to work that.
> None of these metals "self-extract" from the "run-of-mine" ore.
> Hence mineral processing as an expertise.
>
> Thing is, those happily-done calculations enabled me to see the
> twists-and-turns the author, with decades of experience of mineral
> processing, could throw at you to get you to think through the issue.
> Layers deeper than the text alone could take you.



> I had to visualise the minerals and mineral streams, then draw sketches
> which were my "model",


my boss still uses graphing paper and HGC3 (hydrolic calculator v3).

> then derive the maths (concurred with the
> author's equations) - then write the elisp functions and get the
> answers.

> No immediate jobs so having to get back to welding - but could return to
> remind of the logical path which worked for me, in those files, whenever.
>
> These were all "trivial" algebraic expressions, in computing terms.
>
> I appreciate you showing me
> where I could take my computing
> if that juncture came.
>
> Regards,
> Rich Smith



Thank you!

[toc] | [prev] | [next] | [standalone]

#60994 — Re: TCO with named-let via macros

steve g <sgonedes1977@gmail.com> writes:

> Richard Smith <null@void.com> writes:
>
>> Thanks Axel
>> Regarding the second approach;
>> I have read
>> * Paul Graham's "On Lisp"
>> * Siebel's "Practical Common Lisp"
>> so have seen things like "gensym" and why has to be so.
>>
>> Reality is, with very not-advanced lisp basics I seem to do well.
>
> yeah me too :)
>
>>
>> In my world of melting and shaping metal, there seems to be something
>> good about the working environment of equations and explanations in one
>> document.  It seems to facilitate a person developing their thoughts.
>
> I so agree! I thread and weld pipe for fire suppression systems. we use
> hydraulic calculations; if you can do this you are golden...
>
>>
>> This seems to be the biggest issue - what the environment makes readily
>> and enjoyably achievable.
>>
>> In recent years
>>
>> * every beam calculation I want to do
>>   (Euler-Bernoulli beam - derived 1750's; applied eg. Eiffel 1880's-ish)
>>   which I do use frequently in my welding and engineering work
>>
>
>
>> * a 1-D computer-numerical solution for heat-flow which proves a useful
>>   "nutcracker" for considering what's going on where the issue is
>>   conductive heat transfer
>
>
> Oh yeah! another heat transfer variable :)
>>
>> * in mineral processing (considering processing metal ores - tin,
>>   copper, etc) I can run through calculations actually feeling very
>>   happy
>>
>> Mineral processing was last new application, a couple of months ago.
>> I'm surrounded by abandoned mines here - some of the iconic images of
>> Cornwall.  With for me the crucial thing being that tin-mining is
>> restarting here.  There's also lithium here - efforts to work that.
>> None of these metals "self-extract" from the "run-of-mine" ore.
>> Hence mineral processing as an expertise.
>>
>> Thing is, those happily-done calculations enabled me to see the
>> twists-and-turns the author, with decades of experience of mineral
>> processing, could throw at you to get you to think through the issue.
>> Layers deeper than the text alone could take you.
>
>
>
>> I had to visualise the minerals and mineral streams, then draw sketches
>> which were my "model",
>
>
> my boss still uses graphing paper and HGC3 (hydrolic calculator v3).
>
>> then derive the maths (concurred with the
>> author's equations) - then write the elisp functions and get the
>> answers.
>
>> No immediate jobs so having to get back to welding - but could return to
>> remind of the logical path which worked for me, in those files, whenever.
>>
>> These were all "trivial" algebraic expressions, in computing terms.
>>
>> I appreciate you showing me
>> where I could take my computing
>> if that juncture came.
>>
>> Regards,
>> Rich Smith
>
>
>
> Thank you!

Hi there!
I can hardly believe it that there is someone else out there who does
metal-bashing and uses emacs as a working environment.

"I so agree! I thread and weld pipe for fire suppression systems. we use
 hydraulic calculations; if you can do this you are golden..."

I have a website
weldsmith.co.uk
Lots of technical things.

If you want to get in contact there is a contact form.

Since I wrote that post I have been volunteering at a mine museum making
a replica of the "cage" of the haulage shaft - which for me is getting
my hand back in in welding.

Regards

[toc] | [prev] | [next] | [standalone]

#60984 — Re: TCO with named-let via macros

Axel - I know that elisp doesn't optimise if an expressed recursive
function is tail-recursive.
A practical work-around is an alterative approach using the looping
built-in's like "dotimes" (?) - where a recursive approach would have
minimalistic beauty.
Regards, Rich S

[toc] | [prev] | [next] | [standalone]

#60991 — Re: TCO with named-let via macros

Richard Smith <null@void.com> writes:

> Axel - I know that elisp doesn't optimise if an expressed recursive
> function is tail-recursive.

actually the byte-compiler does do tail recursive optimizations.

> A practical work-around is an alterative approach using the looping
> built-in's like "dotimes" (?) - where a recursive approach would have
> minimalistic beauty.
> Regards, Rich S


check the elisp manual. it shows how to implement true tail recursion in
emacs.


(defun elisp-sum (args)
  (elisp-sum-aux args 0))

(defun elisp-sum-aux (args res)
  (if (null args)
      res
      (elisp-sum-aux (cdr args) (+ (car args) res))))


you can byte compile it. very simple.

[toc] | [prev] | [next] | [standalone]

#60993 — Re: TCO with named-let via macros

steve g <sgonedes1977@gmail.com> writes:

> check the elisp manual. it shows how to implement true tail recursion
> in emacs.
>
> (defun elisp-sum (args)
>   (elisp-sum-aux args 0))
>
> (defun elisp-sum-aux (args res)
>   (if (null args)
>       res
>       (elisp-sum-aux (cdr args) (+ (car args) res))))
>
> you can byte compile it. very simple.

... and then easily find out that it will enter the debugger for large
ARGS, say

  (defun elisp-sum (number-sequence 1 10000000))

But with

(defmacro defun-tco (name args body)
  "Wraps a 'named-let' around BODY to have a TCO of function NAME with ARGS."
  (declare (indent defun))
  (let ((bindings (gensym)))
    (setq bindings (mapcar #'(lambda (arg) (list arg arg)) args))
    `(defun ,name ,args
       (named-let ,name ,bindings
         ,body))))

and

(defun-tco elisp-sum-aux (args res)
  (if (null args)
      res
    (elisp-sum-aux (cdr args) (+ (car args) res))))

a

  (defun elisp-sum (number-sequence 1 10000000))

will do.

Best regards

Axel

[toc] | [prev] | [next] | [standalone]

#60996 — Re: TCO with named-let via macros

Axel Reichert <mail@axel-reichert.de> writes:

> steve g <sgonedes1977@gmail.com> writes:
>
< > check the elisp manual. it shows how to implement true tail recursion
< > in emacs.
< >
< > (defun elisp-sum (args)
< >   (elisp-sum-aux args 0))
< >
< > (defun elisp-sum-aux (args res)
< >   (if (null args)
< >       res
< >       (elisp-sum-aux (cdr args) (+ (car args) res))))
< >
< > you can byte compile it. very simple.
>

> ... and then easily find out that it will enter the debugger for large
> ARGS, say
>
>   (defun elisp-sum (number-sequence 1 10000000))


I was thinking more of the concept; no more than that.

(elisp-sum (number-sequence 1 107)).. there is a limit to list length; that is
usually time.


> But with
>
> (defmacro defun-tco (name args body)
>   "Wraps a 'named-let' around BODY to have a TCO of function NAME with ARGS."
>   (declare (indent defun))
>   (let ((bindings (gensym)))
>     (setq bindings (mapcar #'(lambda (arg) (list arg arg)) args))
>     `(defun ,name ,args
>        (named-let ,name ,bindings
>          ,body))))
>


yes, yes; lambda bindings will certainly work better. even in common
lisp there is a limit to the length of &rest arguments and can take some
time to process large lists; sometimes crashing the stack.

If you are interested in non-deterministic software then screamer is
fairly cool.

> and
>
> (defun-tco elisp-sum-aux (args res)
>   (if (null args)
>       res
>     (elisp-sum-aux (cdr args) (+ (car args) res))))
>
> a



>   (defun elisp-sum (number-sequence 1 10000000))
>
> will do.

this is probably the best option - just mentioning that recursion does
work fairly well in emacs lisp...


>
> Best regards

same


> Axel

[toc] | [prev] | [next] | [standalone]

#61018 — Re: TCO with named-let via macros

Axel Reichert <mail@axel-reichert.de> writes:

> steve g <sgonedes1977@gmail.com> writes:
>
>> check the elisp manual. it shows how to implement true tail recursion
>> in emacs.
>>
>> (defun elisp-sum (args)
>>   (elisp-sum-aux args 0))
>>
>> (defun elisp-sum-aux (args res)
>>   (if (null args)
>>       res
>>       (elisp-sum-aux (cdr args) (+ (car args) res))))
>>
>> you can byte compile it. very simple.
>
> ... and then easily find out that it will enter the debugger for large
> ARGS, say
>
>   (defun elisp-sum (number-sequence 1 10000000))
>
> But with
>
> (defmacro defun-tco (name args body)
>   "Wraps a 'named-let' around BODY to have a TCO of function NAME with ARGS."
>   (declare (indent defun))
>   (let ((bindings (gensym)))
>     (setq bindings (mapcar #'(lambda (arg) (list arg arg)) args))
>     `(defun ,name ,args
>        (named-let ,name ,bindings
>          ,body))))
>
> and
>
> (defun-tco elisp-sum-aux (args res)
>   (if (null args)
>       res
>     (elisp-sum-aux (cdr args) (+ (car args) res))))
>
> a
>
>   (defun elisp-sum (number-sequence 1 10000000))
>
> will do.
>
> Best regards
>
> Axel

Hi there - several months later...
Axel, Steve in particular with your responses.
I got a job as a welder - my first local job on moving here - and had a
"winter campaign".  Was exhausting getting back into it.
Strengthening-up my torso to do weld-runs quickly And accurately And
able to overcome perturbations like the "hose" from machine to MIG
gun/torch snagging and dragging while continuing welding at constant
rate.
Then mental tiredness of getting to grips with the various products and
what they needed.
Just had a chance to look through those posts again.
Thanks so much.
Best wishes, Rich S

[toc] | [prev] | [next] | [standalone]

#60985 — Re: TCO with named-let via macros

Axel, all - for what it's worth...
It's often much quicker to get a solution than to explain that solution.
It can take minutes or something like an hour and a half to know
something vitally important.
The feeling is it's very rewarding.
But how you explain that to the rest of the world living in a world
structured around word-processors, spreadsheets, etc...
That is the hard-work.

With structures you can test-load while it is centimetres above the
ground - well-known acceptable method.  IF you'd got it wrong and the
structure failed that would have no consequence as it would simply sag
those centimetres to the ground.  That test done at some
margin-of-safety overload, you can use it at any height, etc.

So you can happily sketch your solutions - and you know there is a
long-stop which will catch any errors.
The efficiency is knowing exactly what that test-load is which will have
the structure accepted on the basis of empirical test.

Hopefully I am giving insight into why what you specialise in is
appreciated in my world.

[toc] | [prev] | [next] | [standalone]

#60986 — Re: TCO with named-let via macros

Hi again Axel
I have made structures out of offcuts of metal and tested them to
destruction.
For both (Euler-Bernoulli) beam calculations and Finite Element Analysis
modelling the prediction exactly matches what is observed.
Even for Finite Element Analysis modelling you often have calculations
to do working out or preparing the overall design.
Again - it's about this working environment in emacs.  Including
functions

Example, for what it's worth

standard Rectangular Hollow Section beam 200x100x8mm, 3m long

(beam-rhs-simple-fmax-y-bb-pp 200e-3 100e-3 8e-3 3 355e6 210e9)
"H=0.2 W=0.1 wthk=0.008 len=3 sigma=3.550000e+08 E=2.100000e+11 :
I=2.306014e-05 Z_el=2.306014e-04 M_max=81863.49226666673
F=109151.3230222223 Defln=0.012678571428571428"
That's pretty-printed so you can see all is well.
Mathematically useless though.

(beam-fmax-rhs-simple-cload-bb 200e-3 100e-3 8e-3 3 355e6) ;; 109151.3230222223
Correct, but that's in Newtons - hard to visualise in a practical sense

(/
  (beam-fmax-rhs-simple-cload-bb 200e-3 100e-3 8e-3 3 355e6)
  9.81 ;; Newtons per kg in Earth's gravity
  1e3 ;; 1000kg per Tonne
 ) ;; 11.126536495639378
Tonnes

It'll take 11 Tonnes load in gravity before bending.


The point - the path to the answer is part of the record, as well as the
answer itself.

And this is what makes the emacs environment so useful to me for what I
do.

I've preceded C-x C-e by C-u to put the answer into the buffer
C-u C-x C-e
Familiar day-to-day usage.

Thanks for showing me the more advanced programming posibilities.

[toc] | [prev] | [next] | [standalone]

#60992 — Re: TCO with named-let via macros

Richard Smith <null@void.com> writes:

>
> It'll take 11 Tonnes load in gravity before bending.
>

what guage steel you using at what incline? :)

> The point - the path to the answer is part of the record, as well as the
> answer itself.
>
> And this is what makes the emacs environment so useful to me for what I
> do.
>
> I've preceded C-x C-e by C-u to put the answer into the buffer
> C-u C-x C-e
> Familiar day-to-day usage.
>
> Thanks for showing me the more advanced programming posibilities.

[toc] | [prev] | [next] | [standalone]

#60995 — Re: TCO with named-let via macros

steve g <sgonedes1977@gmail.com> writes:

> Richard Smith <null@void.com> writes:
>
>>
>> It'll take 11 Tonnes load in gravity before bending.
>>
>
> what guage steel you using at what incline? :)
>
>> The point - the path to the answer is part of the record, as well as the
>> answer itself.
>>
>> And this is what makes the emacs environment so useful to me for what I
>> do.
>>
>> I've preceded C-x C-e by C-u to put the answer into the buffer
>> C-u C-x C-e
>> Familiar day-to-day usage.
>>
>> Thanks for showing me the more advanced programming posibilities.

I put the dimensions in the familiar way we express it
"Rectangular Hollow Section beam 200x100x8mm, 3m long"
So that's 200mm tall, 100mm wide and 8mm wall thickness.
3metres long, obviously

You could check my values against beam tables - eg. in "The Blue Book"
https://www.steelforlifebluebook.co.uk/hfrhs/ec3-ukna/section-properties-dimensions-properties
"200x100x8" is a commercial section.

I see what you are asking about "incline".
The implicit assumption for a "simple beam" - it sits on an immovable
support at each end, otherwise span free space and is loaded in the
middle - is that the beam is horizontal and the load is vertical, as
would be the case for a mass in gravity bearing upon the beam

[toc] | [prev] | [standalone]

Back to top | Article view | gnu.emacs.help

csiph-web