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 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 on behalf of Brian Walden < > tuhs@cuzuco.com> > *Reply to: *Brian Walden > *Date: *Tuesday, 22. February 2022 at 01:02 > *To: * > *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 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 > > >