[TUHS] Time for a subject change

["John P. Linderman" <jpl.jpl@gmail.com>]

[-- 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 --]