```The Unix Heritage Society mailing list
help / color / mirror / Atom feed```
```* [TUHS] Lorinda Cherry
@ 2022-02-22  0:02 Brian Walden
2022-03-01 21:51 ` Terry Jones
From: Brian Walden @ 2022-02-22  0:02 UTC (permalink / raw)
To: tuhs

I enjoy this dc(1) discussion.  I am a daily dc user, and since my fisrt
calculator was an HP-45 (circa 1973) RPN felt right. However I think
dc pre-dates ALL HP calculators, since there was one in the 1st Edition
written in assembly.

I extened my version of dc (way before gnu existed)
based on common buttons I used from HP calculators:

CMD    WHAT
#      comment, to new line
~      change sign of top of stack (CHS key)
|      1/top of stack (1/x key)
e      push 99 digits of e (2.718..) on the stack
@      push 99 digits of pi on the stack (looks like a circle)
r      reverse top of stack (x<>y key)

I had been fascinated with pi stemimg from the Star Trek epsiode Wolf
in the Fold where Spock uses it to usa all computing power

"Computer, this is a Class A compulsory directive. Compute to
the last digit the value of pi."

"As we know, the value of pi is a transcendental figure without
resolution. The computer banks will work on this problem to the
exclusion of all else until we order it to stop."

As it was supposed to be "arbitrary precision" here was my tool.

So I wrote Machin formula in dc slowing increasing the scale and printing
the results. In the orginal dc, yes the whole part was arbitrary, but the
decimal part (scale) was limited to 99. Well that became a disappiontment.
(this program is lost to time)

So I decided to rewrite it but increasing pi as a whole numbers instead
of increasing scale (ex. 31415, 314159, 3141592, ... etc)

I still have that program which is simply this --

[sxln_1ll*dsllb*dszli2+dsi5li^*/+dsn4*lelzli239li^*/+dse-dlx!=Q]sQ
1[ddsb5/sn239/se1ddsisllQx4*pclb10*lPx]dsPx

if you run it you'll notice the last 1 to 2 digits are wrong due to precision.

The next problem became small memory. I still have thes saved output before
it crashed at 1024 digits. No idea what specs of the machine it was run
on anymore its really old --

3141592653589793238462643383279502884197169399375105820974944592307816\
4062862089986280348253421170679821480865132823066470938446095505822317\
2535940812848111745028410270193852110555964462294895493038196442881097\
5665933446128475648233786783165271201909145648566923460348610454326648\
2133936072602491412737245870066063155881748815209209628292540917153643\
6789259036001133053054882046652138414695194151160943305727036575959195\
3092186117381932611793105118548074462379962749567351885752724891227938\
1830119491298336733624406566430860213949463952247371907021798609437027\
7053921717629317675238467481846766940513200056812714526356082778577134\
2757789609173637178721468440901224953430146549585371050792279689258923\
5420199561121290219608640344181598136297747713099605187072113499999983\
7297804995105973173281609631859502445945534690830264252230825334468503\
5261931188171010003137838752886587533208381420617177669147303598253490\
4287554687311595628638823537875937519577818577805321712268066130019278\
76611195909216420198938095257201065485862972
out of space: salloc
all 8587356 rel 8587326 headmor 1
nbytes -28318
stk 71154 rd 125364 wt 125367 beg 125364 last 125367
83 11 0
30 IOT trap - core dumped

But I was much happier with that.

On a side note: programming dc is hard. There was no comment character.
And it's a pain to read, and it's a pain to debug.

When I discovered the Chudnovsky algorithm for pi, of course I implemented it
in dc --

[0ksslk3^16lkd12+sk*-lm*lhd1+sh3^/smlx_262537412640768000*sxll545140134+dsllm*lxlnk/ls+dls!=P]sP
7sn[6sk1ddshsxsm13591409dsllPx10005v426880*ls/K3-k1/pcln14+snlMx]dsMx

At 99 digits of scale it ran out in 7 rounds, but now with that limitation
removed and large memeories it just goes on and on.....

-Brian

PS: Thanks for the fast OpenBSD version of dc, Otto.

Otto Moerbeek wrote:
> On Thu, Feb 17, 2022 at 01:44:07PM -0800, Bakul Shah wrote:
>
> > On Feb 17, 2022, at 1:18 PM, Dave Horsfall <dave at horsfall.org> wrote:
> > >
> > > On Thu, 17 Feb 2022, Tom Ivar Helbekkmo via TUHS wrote:
> > >
> > >> Watching the prime number generator (from the Wikipedia page on dc)
> > >> running on the 11/23 is much more entertaining than doing it on the
> > >> modern workstation I'm typing this on:
> > >>
> > >> 2p3p[dl!d2+s!%0=@l!l^!<#]s#[s/0ds^]s@[p]s&[ddvs^3s!l#x0<&2+l.x]ds.x
> > >
> > > Wow...  About 10s on my old MacBook Pro, and I gave up on my ancient
> > > FreeBSD box.
> >
> > That may be because FreeBSD continues computing primes while the MacOS
> > dc gives up after a while!
> >
> > freebsd (ryzen 2700 3.2Ghz): # note: I interrupted dc after a while
> > \$ command time dc <<< '2p3p[dl!d2+s!%0=@l!l^!<#]s#[s/0ds^]s@[p]s&[ddvs^3s!l#x0<&2+l.x]ds.x' > xxx
> > ^C       11.93 real        11.79 user         0.13 sys
> > \$ wc xxx
> >    47161   47161  319109 xxx
> > \$ size `which dc`
> >     text   data     bss      dec       hex   filename
> >   238159   2784   11072   252015   0x3d86f   /usr/bin/dc
> >
> > MacOS (m1 pro, prob. 2Ghz)
> > \$ command time dc <<< '2p3p[dl!d2+s!%0=@l!l^!<#]s#[s/0ds^]s@[p]s&[ddvs^3s!l#x0<&2+l.x]ds.x' > xxx
> > time: command terminated abnormally
> >         1.00 real         0.98 user         0.01 sys
> > [2]    37135 segmentation fault  command time dc <<<  > xxx
> > \$ wc xxx
> >     7342    7342   42626 xxx
> > \$ size `which dc`
> > __TEXT      __DATA  __OBJC  others  dec     hex
> > 32768       16384   0       4295016448      4295065600      100018000
> >
>
> MacOS uses the GNU implementation which has a long standing issue with
> deep recursion. It even cannot handle the tail recursive calls used
> here and will run out of its stack.
>
>       -Otto

```* Re: [TUHS] Lorinda Cherry
2022-02-22  0:02 [TUHS] Lorinda Cherry Brian Walden
@ 2022-03-01 21:51 ` Terry Jones
2022-03-01 23:36   ` [TUHS] Time for a subject change John P. Linderman
From: Terry Jones @ 2022-03-01 21:51 UTC (permalink / raw)
To: Brian Walden, tuhs

[-- Attachment #1: Type: text/plain, Size: 6114 bytes --]

I’m also a fan of dc, and still a daily user after 40 years (not much in this group, I know, but a pretty good chunk of my life at least).

To get more functionality, I wrote a Python RPN calculator (with some key bindings identical to dc). It makes 300+ functions from standard Python libraries directly available and you can push Python objects and functions onto the stack. See https://github.com/terrycojones/rpnpy

Terry

From: TUHS <tuhs-bounces@minnie.tuhs.org> on behalf of Brian Walden <tuhs@cuzuco.com>
Date: Tuesday, 22. February 2022 at 01:02
To: <tuhs@minnie.tuhs.org>
Subject: [TUHS] Lorinda Cherry

I enjoy this dc(1) discussion. I am a daily dc user, and since my fisrt

calculator was an HP-45 (circa 1973) RPN felt right. However I think

dc pre-dates ALL HP calculators, since there was one in the 1st Edition

written in assembly.

I extened my version of dc (way before gnu existed)

based on common buttons I used from HP calculators:

CMD WHAT

# comment, to new line

~ change sign of top of stack (CHS key)

| 1/top of stack (1/x key)

e push 99 digits of e (2.718..) on the stack

@ push 99 digits of pi on the stack (looks like a circle)

r reverse top of stack (x<>y key)

I had been fascinated with pi stemimg from the Star Trek epsiode Wolf

in the Fold where Spock uses it to usa all computing power

"Computer, this is a Class A compulsory directive. Compute to

the last digit the value of pi."

"As we know, the value of pi is a transcendental figure without

resolution. The computer banks will work on this problem to the

exclusion of all else until we order it to stop."

As it was supposed to be "arbitrary precision" here was my tool.

So I wrote Machin formula in dc slowing increasing the scale and printing

the results. In the orginal dc, yes the whole part was arbitrary, but the

decimal part (scale) was limited to 99. Well that became a disappiontment.

(this program is lost to time)

So I decided to rewrite it but increasing pi as a whole numbers instead

of increasing scale (ex. 31415, 314159, 3141592, ... etc)

I still have that program which is simply this --

[sxln_1ll*dsllb*dszli2+dsi5li^*/+dsn4*lelzli239li^*/+dse-dlx!=Q]sQ

1[ddsb5/sn239/se1ddsisllQx4*pclb10*lPx]dsPx

if you run it you'll notice the last 1 to 2 digits are wrong due to precision.

The next problem became small memory. I still have thes saved output before

it crashed at 1024 digits. No idea what specs of the machine it was run

on anymore its really old --

3141592653589793238462643383279502884197169399375105820974944592307816\

4062862089986280348253421170679821480865132823066470938446095505822317\

2535940812848111745028410270193852110555964462294895493038196442881097\

5665933446128475648233786783165271201909145648566923460348610454326648\

2133936072602491412737245870066063155881748815209209628292540917153643\

6789259036001133053054882046652138414695194151160943305727036575959195\

3092186117381932611793105118548074462379962749567351885752724891227938\

1830119491298336733624406566430860213949463952247371907021798609437027\

7053921717629317675238467481846766940513200056812714526356082778577134\

2757789609173637178721468440901224953430146549585371050792279689258923\

5420199561121290219608640344181598136297747713099605187072113499999983\

7297804995105973173281609631859502445945534690830264252230825334468503\

5261931188171010003137838752886587533208381420617177669147303598253490\

4287554687311595628638823537875937519577818577805321712268066130019278\

76611195909216420198938095257201065485862972

out of space: salloc

all 8587356 rel 8587326 headmor 1

nbytes -28318

stk 71154 rd 125364 wt 125367 beg 125364 last 125367

83 11 0

30 IOT trap - core dumped

But I was much happier with that.

On a side note: programming dc is hard. There was no comment character.

And it's a pain to read, and it's a pain to debug.

When I discovered the Chudnovsky algorithm for pi, of course I implemented it

in dc --

[0ksslk3^16lkd12+sk*-lm*lhd1+sh3^/smlx_262537412640768000*sxll545140134+dsllm*lxlnk/ls+dls!=P]sP

7sn[6sk1ddshsxsm13591409dsllPx10005v426880*ls/K3-k1/pcln14+snlMx]dsMx

At 99 digits of scale it ran out in 7 rounds, but now with that limitation

removed and large memeories it just goes on and on.....

-Brian

PS: Thanks for the fast OpenBSD version of dc, Otto.

Otto Moerbeek wrote:

> On Thu, Feb 17, 2022 at 01:44:07PM -0800, Bakul Shah wrote:
>
>> On Feb 17, 2022, at 1:18 PM, Dave Horsfall <dave at horsfall.org> wrote:
>
>> >
>
>> > On Thu, 17 Feb 2022, Tom Ivar Helbekkmo via TUHS wrote:
>
>> >
>
>> >> Watching the prime number generator (from the Wikipedia page on dc)
>
>> >> running on the 11/23 is much more entertaining than doing it on the
>
>> >> modern workstation I'm typing this on:
>
>> >>
>
>> >> 2p3p[dl!d2+s!%0=@l!l^!<#]s#[s/0ds^]s@[p]s&[ddvs^3s!l#x0<&2+l.x]ds.x
>
>> >
>
>> > Wow... About 10s on my old MacBook Pro, and I gave up on my ancient
>
>> > FreeBSD box.
>
>>
>
>> That may be because FreeBSD continues computing primes while the MacOS
>
>> dc gives up after a while!
>
>>
>
>> freebsd (ryzen 2700 3.2Ghz): # note: I interrupted dc after a while
>
>> \$ command time dc <<< '2p3p[dl!d2+s!%0=@l!l^!<#]s#[s/0ds^]s@[p]s&[ddvs^3s!l#x0<&2+l.x]ds.x' > xxx
>
>> ^C 11.93 real 11.79 user 0.13 sys
>
>> \$ wc xxx
>
>> 47161 47161 319109 xxx
>
>> \$ size `which dc`
>
>> text data bss dec hex filename
>
>> 238159 2784 11072 252015 0x3d86f /usr/bin/dc
>
>>
>
>> MacOS (m1 pro, prob. 2Ghz)
>
>> \$ command time dc <<< '2p3p[dl!d2+s!%0=@l!l^!<#]s#[s/0ds^]s@[p]s&[ddvs^3s!l#x0<&2+l.x]ds.x' > xxx
>
>> time: command terminated abnormally
>
>> 1.00 real 0.98 user 0.01 sys
>
>> [2] 37135 segmentation fault command time dc <<< > xxx
>
>> \$ wc xxx
>
>> 7342 7342 42626 xxx
>
>> \$ size `which dc`
>
>> __TEXT __DATA __OBJC others dec hex
>
>> 32768 16384 0 4295016448 4295065600 100018000
>
>>
>
> MacOS uses the GNU implementation which has a long standing issue with
>
> deep recursion. It even cannot handle the tail recursive calls used
>
> here and will run out of its stack.
>
> -Otto

[-- Attachment #2: Type: text/html, Size: 15202 bytes --]

```* [TUHS] Time for a subject change
2022-03-01 21:51 ` Terry Jones
@ 2022-03-01 23:36   ` John P. Linderman
0 siblings, 0 replies; 3+ messages in thread
From: John P. Linderman @ 2022-03-01 23:36 UTC (permalink / raw)
To: Terry Jones; +Cc: The Unix Heritage Society, Brian Walden

[-- Attachment #1: Type: text/plain, Size: 7332 bytes --]

This thread has long since diverged from Lorinda and her death. I'm fine
with a discussion of some of Lorinda's work, but let's talk about bc or dc
in a separate thread that has nothing to do with Lorinda.

On Tue, Mar 1, 2022 at 5:06 PM Terry Jones <terry@jon.es> wrote:

> I’m also a fan of dc, and still a daily user after 40 years (not much in
> this group, I know, but a pretty good chunk of my life at least).
>
>
>
> To get more functionality, I wrote a Python RPN calculator (with some key
> bindings identical to dc). It makes 300+ functions from standard Python
> libraries directly available and you can push Python objects and functions
> onto the stack. See https://github.com/terrycojones/rpnpy
>
>
>
> Terry
>
>
>
> *From: *TUHS <tuhs-bounces@minnie.tuhs.org> on behalf of Brian Walden <
> tuhs@cuzuco.com>
> *Reply to: *Brian Walden <tuhs@cuzuco.com>
> *Date: *Tuesday, 22. February 2022 at 01:02
> *To: *<tuhs@minnie.tuhs.org>
> *Subject: *[TUHS] Lorinda Cherry
>
>
>
> I enjoy this dc(1) discussion.  I am a daily dc user, and since my fisrt
>
> calculator was an HP-45 (circa 1973) RPN felt right. However I think
>
> dc pre-dates ALL HP calculators, since there was one in the 1st Edition
>
> written in assembly.
>
>
>
> I extened my version of dc (way before gnu existed)
>
> based on common buttons I used from HP calculators:
>
>
>
>     CMD    WHAT
>
>     #      comment, to new line
>
>     ~      change sign of top of stack (CHS key)
>
>     |      1/top of stack (1/x key)
>
>     e      push 99 digits of e (2.718..) on the stack
>
>     @      push 99 digits of pi on the stack (looks like a circle)
>
>     r      reverse top of stack (x<>y key)
>
>
>
> I had been fascinated with pi stemimg from the Star Trek epsiode Wolf
>
> in the Fold where Spock uses it to usa all computing power
>
>
>
>    "Computer, this is a Class A compulsory directive. Compute to
>
>     the last digit the value of pi."
>
>
>
>    "As we know, the value of pi is a transcendental figure without
>
>     resolution. The computer banks will work on this problem to the
>
>     exclusion of all else until we order it to stop."
>
>
>
> As it was supposed to be "arbitrary precision" here was my tool.
>
>
>
> So I wrote Machin formula in dc slowing increasing the scale and printing
>
> the results. In the orginal dc, yes the whole part was arbitrary, but the
>
> decimal part (scale) was limited to 99. Well that became a disappiontment.
>
> (this program is lost to time)
>
>
>
> So I decided to rewrite it but increasing pi as a whole numbers instead
>
> of increasing scale (ex. 31415, 314159, 3141592, ... etc)
>
>
>
> I still have that program which is simply this --
>
>
>
> [sxln_1ll*dsllb*dszli2+dsi5li^*/+dsn4*lelzli239li^*/+dse-dlx!=Q]sQ
>
> 1[ddsb5/sn239/se1ddsisllQx4*pclb10*lPx]dsPx
>
>
>
>
>
> if you run it you'll notice the last 1 to 2 digits are wrong due to
> precision.
>
>
>
> The next problem became small memory. I still have thes saved output before
>
> it crashed at 1024 digits. No idea what specs of the machine it was run
>
> on anymore its really old --
>
>
>
> 3141592653589793238462643383279502884197169399375105820974944592307816\
>
> 4062862089986280348253421170679821480865132823066470938446095505822317\
>
> 2535940812848111745028410270193852110555964462294895493038196442881097\
>
> 5665933446128475648233786783165271201909145648566923460348610454326648\
>
> 2133936072602491412737245870066063155881748815209209628292540917153643\
>
> 6789259036001133053054882046652138414695194151160943305727036575959195\
>
> 3092186117381932611793105118548074462379962749567351885752724891227938\
>
> 1830119491298336733624406566430860213949463952247371907021798609437027\
>
> 7053921717629317675238467481846766940513200056812714526356082778577134\
>
> 2757789609173637178721468440901224953430146549585371050792279689258923\
>
> 5420199561121290219608640344181598136297747713099605187072113499999983\
>
> 7297804995105973173281609631859502445945534690830264252230825334468503\
>
> 5261931188171010003137838752886587533208381420617177669147303598253490\
>
> 4287554687311595628638823537875937519577818577805321712268066130019278\
>
> 76611195909216420198938095257201065485862972
>
> out of space: salloc
>
> all 8587356 rel 8587326 headmor 1
>
> nbytes -28318
>
> stk 71154 rd 125364 wt 125367 beg 125364 last 125367
>
> 83 11 0
>
> 30 IOT trap - core dumped
>
>
>
>
>
> But I was much happier with that.
>
>
>
> On a side note: programming dc is hard. There was no comment character.
>
> And it's a pain to read, and it's a pain to debug.
>
>
>
> When I discovered the Chudnovsky algorithm for pi, of course I implemented
> it
>
> in dc --
>
>
>
>
> [0ksslk3^16lkd12+sk*-lm*lhd1+sh3^/smlx_262537412640768000*sxll545140134+dsllm*lxlnk/ls+dls!=P]sP
>
> 7sn[6sk1ddshsxsm13591409dsllPx10005v426880*ls/K3-k1/pcln14+snlMx]dsMx
>
>
>
> At 99 digits of scale it ran out in 7 rounds, but now with that limitation
>
> removed and large memeories it just goes on and on.....
>
>
>
> -Brian
>
>
>
> PS: Thanks for the fast OpenBSD version of dc, Otto.
>
>
>
> Otto Moerbeek wrote:
>
> On Thu, Feb 17, 2022 at 01:44:07PM -0800, Bakul Shah wrote:
>
>
>
> > On Feb 17, 2022, at 1:18 PM, Dave Horsfall <dave at horsfall.org> wrote:
>
> > >
>
> > > On Thu, 17 Feb 2022, Tom Ivar Helbekkmo via TUHS wrote:
>
> > >
>
> > >> Watching the prime number generator (from the Wikipedia page on dc)
>
> > >> running on the 11/23 is much more entertaining than doing it on the
>
> > >> modern workstation I'm typing this on:
>
> > >>
>
> > >> 2p3p[dl!d2+s!%0=@l!l^!<#]s#[s/0ds^]s@[p]s&[ddvs^3s!l#x0<&2+l.x]ds.x
>
> > >
>
> > > Wow...  About 10s on my old MacBook Pro, and I gave up on my ancient
>
> > > FreeBSD box.
>
> >
>
> > That may be because FreeBSD continues computing primes while the MacOS
>
> > dc gives up after a while!
>
> >
>
> > freebsd (ryzen 2700 3.2Ghz): # note: I interrupted dc after a while
>
> > \$ command time dc <<< '2p3p[dl!d2+s!%0=@l!l^!<#]s#[s/0ds^]s@[p]s&[ddvs^3s!l#x0<&2+l.x]ds.x'
> > xxx
>
> > ^C       11.93 real        11.79 user         0.13 sys
>
> > \$ wc xxx
>
> >    47161   47161  319109 xxx
>
> > \$ size `which dc`
>
> >     text   data     bss      dec       hex   filename
>
> >   238159   2784   11072   252015   0x3d86f   /usr/bin/dc
>
> >
>
> > MacOS (m1 pro, prob. 2Ghz)
>
> > \$ command time dc <<< '2p3p[dl!d2+s!%0=@l!l^!<#]s#[s/0ds^]s@[p]s&[ddvs^3s!l#x0<&2+l.x]ds.x'
> > xxx
>
> > time: command terminated abnormally
>
> >         1.00 real         0.98 user         0.01 sys
>
> > [2]    37135 segmentation fault  command time dc <<<  > xxx
>
> > \$ wc xxx
>
> >     7342    7342   42626 xxx
>
> > \$ size `which dc`
>
> > __TEXT      __DATA  __OBJC  others  dec     hex
>
> > 32768       16384   0       4295016448      4295065600      100018000
>
> >
>
>
>
> MacOS uses the GNU implementation which has a long standing issue with
>
> deep recursion. It even cannot handle the tail recursive calls used
>
> here and will run out of its stack.
>
>
>
>        -Otto
>
>
>

[-- Attachment #2: Type: text/html, Size: 15523 bytes --]

```end of thread, other threads:[~2022-03-01 23:38 UTC | newest]
```This is a public inbox, see mirroring instructions