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