On Fri, Feb 14, 2025 at 8:58 AM Alexander Burger
wrote:
> The old algorithm needed for 10 digits 8369 sec (02:19 h), the new
> one (I use the coroutine version) just 726 sec. That's about 12 times as
> fast!
>
👍 👍 :)
/Lindsay
>
> How about a coroutine version?
>
> Neat! You have options over what to do with the digits with the coroutine.
And negligible difference in performance, if it matters, either. I didn't
expect that.
/Lindsay
: (bench (out "pi-digits.1.txt" (makePi 1)))
3.150 sec
-> NIL
: (bench (out "pi-dig
On Fri, Feb 14, 2025 at 05:21:46PM +0100, Alexander Burger wrote:
> Wow, that's cool! I'll measure it now :)
The old algorithm needed for 10 digits 8369 sec (02:19 h), the new
one (I use the coroutine version) just 726 sec. That's about 12 times as
fast!
☺/ A!ex
--
UNSUBSCRIBE: mailto:picol
On Fri, Feb 14, 2025 at 07:30:59AM -0800, Lindsay Lawrence wrote:
> On Thu, Feb 13, 2025 at 9:49 PM Lindsay Lawrence <
> lawrence.lindsayj...@gmail.com> wrote:
>
>
> > A bit of searching came up with the paper with the haskell version
> >
> > https://www.cs.ox.ac.uk/people/jeremy.gibbons/publicat
On Thu, Feb 13, 2025 at 9:49 PM Lindsay Lawrence <
lawrence.lindsayj...@gmail.com> wrote:
> A bit of searching came up with the paper with the haskell version
>
> https://www.cs.ox.ac.uk/people/jeremy.gibbons/publications/spigot.pdf
>
> Interestingly enough there is another version of PI in there
On Thu, Feb 13, 2025 at 9:37 AM Alexander Burger
wrote:
> On Thu, Feb 13, 2025 at 08:50:16AM -0800, Lindsay Lawrence wrote:
> > I think it is also a good a test/example of picolisp's support for
> bignums.
>
> Indeed. The numbers in the 'E' environment get quite big. After ten
> thousand digits o
On Thu, Feb 13, 2025 at 9:37 AM Alexander Burger
wrote:
> On Thu, Feb 13, 2025 at 08:50:16AM -0800, Lindsay Lawrence wrote:
> > I think it is also a good a test/example of picolisp's support for
> bignums.
>
> Indeed. The numbers in the 'E' environment get quite big. After ten
> thousand digits o
On Thu, Feb 13, 2025 at 08:50:16AM -0800, Lindsay Lawrence wrote:
> I think it is also a good a test/example of picolisp's support for bignums.
Indeed. The numbers in the 'E' environment get quite big. After ten
thousand digits of PI, 'S' and 'Q' have 145746 digits and 'R' has 145748
digits.
I ve
>
>
>
> Sorry again for the confusion!
>
> 👍
I think it is also a good a test/example of picolisp's support for bignums.
It could be a fun exercise to implement a version of this with one of the
other Pi algorithms that discards already computed digits
so it could essentially just churn out digit
On Thu, Feb 13, 2025 at 07:38:10AM +0100, Alexander Burger wrote:
> When I built the tco version yesterday, I experimended with both
> versions, and somehow the 'M' code was lost :(
OK, I will settle with this version:
# Print next digit of PI
(de digit (Env)
(job Env
(tco (Q
Oops, sorry! Yesterday evening I noticed that I messed it up, but was
too tired to dig into it.
On Wed, Feb 12, 2025 at 02:28:25PM -0800, Lindsay Lawrence wrote:
> Question: Without fully understanding the algorithm, it seems N is the next
> digit to return...
Right.
I posted the original 'whil
> Hmm, it seems that I begin to detect some advantages in tco/tc :)
>
> For example, in pil64 I had a function calculating the digits of pi ad
> infinitum:
>
># Print next digit of PI
>(de piDigit ()
> (job '((Q . 1) (R . 0) (S . 1) (K . 1) (N . 3) (L . 3))
> (while (>= (- (+
On Wed, Feb 12, 2025 at 08:14:04AM +0100, Alexander Burger wrote:
> If a problem is a linear operation, like traversing a list, a loop is
> more natural for me. For traversing a tree, recursion is better of
> course.
Hmm, it seems that I begin to detect some advantages in tco/tc :)
For example, i
On Tue, Feb 11, 2025 at 11:25 PM Alexander Burger
wrote:
>
> If a problem is a linear operation, like traversing a list, a loop is
> more natural for me. For traversing a tree, recursion is better of
> course.
>
> Thanks!
>(de fiboSwap (N)
> (let (A 0 B 1)
> (do N
>
On Tue, Feb 11, 2025 at 02:41:01PM -0800, Lindsay Lawrence wrote:
> > I usually approach such tasks with loops, with a rather
> > different mental model.
> >
> That is interesting! Can you say more about your mental model?
> I am often surprised by how often I end up with recursive solutions when
>
> I usually approach such tasks with loops, with a rather
> different mental model.
>
>
That is interesting! Can you say more about your mental model?
I am often surprised by how often I end up with recursive solutions when
hacking on a particular problem in picolisp.
Concerning swap, we could for
On Mon, Feb 10, 2025 at 10:18:41PM -0800, Lindsay Lawrence wrote:
> I realized several existing recursive functions I use were trivially
> convertible and are now able to work with much larger lists.
>
> I put a few examples here: swap, mtf (move to front), mft (move from top)
>
> https://githu
On Mon, Feb 10, 2025 at 2:49 AM Alexander Burger
wrote:
>
> I'd like to point out, however, that recursion and tail call
> optimization are not fully equivalent. We always need to keep that in
> mind!
>
> The original idea of TCO (not the 'tco' function in PicoLisp) is to
> avoid that calling the
On Mon, Feb 10, 2025 at 6:32 AM Alexander Burger
wrote:
> On Mon, Feb 10, 2025 at 02:06:52PM +0100, Alexander Burger wrote:
> > : (let N 99 (bench (tco (N) (or (=0 N) (tc (dec N))
> > 0.038 sec
> > -> 0
>
> For the records - and to show the absurdity of TCO - this is of course
> the same
On Mon, Feb 10, 2025 at 2:49 AM Alexander Burger
wrote:
> I'd like to point out, however, that recursion and tail call
> optimization are not fully equivalent. We always need to keep that in
> mind!
>
> ...
> So what PicoLisp does is first clean up everything, by first *leaving*
> all enclosing
On Mon, Feb 10, 2025 at 02:06:52PM +0100, Alexander Burger wrote:
> : (let N 99 (bench (tco (N) (or (=0 N) (tc (dec N))
> 0.038 sec
> -> 0
For the records - and to show the absurdity of TCO - this is of course
the same as
: (let N 99 (bench (until (=0 N) (dec 'N
0.032 sec
-> 0
☺/
On Sun, Feb 09, 2025 at 02:13:13PM -0800, Lindsay Lawrence wrote:
> It is interesting that I don't see much performance difference between tco
> and recur in most cases.
The difference is better visible if you avoid as much additional
processing as possible, and boil it down to the essential 'recu
On Sun, Feb 09, 2025 at 11:32:38PM -0800, Lindsay Lawrence wrote:
> In trying to compare tco vs recur for my own use I came up with
> the following:
> ...
Nice examples, thanks a lot!
I'd like to point out, however, that recursion and tail call
optimization are not fully equivalent. We always ne
On Sun, Feb 9, 2025 at 11:18 PM Alexander Burger
wrote:
> Exactly. 'tco' does not make much difference in total running time. It
> is all about stack usage.
>
>
Thanks Alex!
> Try with a limited stack size:
>
> : (stack 8 8) # Stack sizes 8 KiB
> -> 8
> : (co 'a (yield)) # Start a coroutine t
In trying to compare tco vs recur for my own use I came up with
the following:
The two functions 'bstInsertTco', 'bstInsertRecur' (see code at end) are
identical except for tco,tc and recur,recurse.
The repl examples show the degenerate case of inserting an ordered list
into a BST without rebalan
On Sun, Feb 09, 2025 at 02:13:13PM -0800, Lindsay Lawrence wrote:
> It is interesting that I don't see much performance difference between tco
> and recur in most cases.
> Perhaps the primary difference is their resource usage?
Exactly. 'tco' does not make much difference in total running time. It
>
>
> It is interesting that I don't see much performance difference between tco
> and recur in most cases.
> Perhaps the primary difference is their resource usage?
>
> For example, using (mike)'s fibo example and simply replacing tco with
> recur (see code at end)
> I initially expected (fibo
On Sun, Feb 9, 2025 at 2:36 AM Alexander Burger
wrote:
>
> You can also have use cases for both at the same time.
>
> For example, a tree can be iterated by recursing on the left branches
> and then looping on the right branches:
>
> Noted. A good thing to remember.
It is interesting that I don'
On Sat, Feb 08, 2025 at 07:23:45PM -0800, Lindsay Lawrence wrote:
> I gave 'tco' a try. I appreciate the syntax. The similarity with existing
> recur syntax
> makes it trivial to convert code where tail calls are possible.
You can also have use cases for both at the same time.
For example, a tre
Hi Mike,
> Here are my results: http://pb1n.de/?ce28f3
> ===
> $ pil t1.l +
> 1.997 sec
> 0.000 sec
Hmm, function 'f' is not correct:
(de f (N)
(tco (N A B)
(let A 0 B 1
(if (=0 N)
A
(tc (dec N) B (+ A B)) ) ) ) )
It always returns ze
Hi Lindsay,
> In my bench tests below with a bst search, tail call is on par with
> iterative and consistently slightly faster then recur.
Very nice insights! Thanks a lot!
☺/ A!ex
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
On 09-02-2025 04:23, Lindsay Lawrence wrote:
On Sat, Feb 8, 2025 at 10:16 AM Alexander Burger
wrote:
PicoLisp now has a kind of tail call optimization!
I gave 'tco' a try. I appreciate the syntax. The similarity with
existing recur syntax
makes it trivial to convert code where tail call
On Sat, Feb 8, 2025 at 10:16 AM Alexander Burger
wrote:
> PicoLisp now has a kind of tail call optimization!
>
I gave 'tco' a try. I appreciate the syntax. The similarity with existing
recur syntax
makes it trivial to convert code where tail calls are possible.
In my bench tests below with a b
On 08-02-2025 20:41, Lindsay Lawrence wrote:
On Sat, Feb 8, 2025 at 10:16 AM Alexander Burger
wrote:
PicoLisp now has a kind of tail call optimization!
https://software-lab.de/doc/refT.html#tco
Hi Alex,
I just downloaded the rolling release,
why you do not use git for distribution?
ht
On Sat, Feb 8, 2025 at 11:41 AM Lindsay Lawrence <
lawrence.lindsayj...@gmail.com> wrote:
> I just downloaded the rolling release, but it seems to be missing
> picolisp "bin/picolisp: not found"
> Other bits like httpGate etc are missing from bin/ as well.
>
>
Please disregard this previous e
On Sat, Feb 8, 2025 at 10:16 AM Alexander Burger
wrote:
>
> PicoLisp now has a kind of tail call optimization!
>
> https://software-lab.de/doc/refT.html#tco
>
>
Hi Alex,
I just downloaded the rolling release, but it seems to be missing picolisp
"bin/picolisp: not found"
Other bits like httpG
On Sat, Feb 8, 2025 at 10:16 AM Alexander Burger
wrote:
>
> PicoLisp now has a kind of tail call optimization!
>
>
👍 👍 Yes! I am looking forward to trying this
/Lindsay
37 matches
Mail list logo
