From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.7 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,HTML_MESSAGE,MAILING_LIST_MULTI, TRACKER_ID,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 6176 invoked from network); 1 Mar 2022 23:38:07 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 1 Mar 2022 23:38:07 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id AEDEF9D00C; Wed, 2 Mar 2022 09:38:06 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 087179CFD0; Wed, 2 Mar 2022 09:36:56 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="Ougoe3CY"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id DE9309CFD0; Wed, 2 Mar 2022 09:36:54 +1000 (AEST) Received: from mail-yw1-f172.google.com (mail-yw1-f172.google.com [209.85.128.172]) by minnie.tuhs.org (Postfix) with ESMTPS id 1C7699CC02 for ; Wed, 2 Mar 2022 09:36:54 +1000 (AEST) Received: by mail-yw1-f172.google.com with SMTP id 00721157ae682-2dbd8777564so47315137b3.0 for ; Tue, 01 Mar 2022 15:36:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jSKQH4YM+bbSost1BM1JEIngrcqOVk8jpvupWfEE8o0=; b=Ougoe3CY7rrw0Axfli9DU8T1gmRa0I6e4+xlbKnetk0Zn3mFGhTT8hdbEGRY5GPZbE 9yB1coPC8uzl6TCoCH3lviETSiuYpfcSMjEk6MKO7OhHkwhNXF3Vit1AGoJamfy4yarh OlOsqXKLh2kgRJV1DidaKXqytLFrQNSJAxTLeO6ehNBetfORkwAmC5R3z52TMaAYdkqS TccBkE33D9Ghghu2SYiptciqsuce00dFFYkp1odTe1gG2r6I7XVvsa+TlSfThS2A2Ix6 +OsZPFEJQTmmwx/x8Y0bQ1pAk9drV+hAUwW3qPjUAAk3wraEP39kZWKiU0xB04FKBG0H Ek5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jSKQH4YM+bbSost1BM1JEIngrcqOVk8jpvupWfEE8o0=; b=hqk6ZdpOEFl8rKMxjsPtT1yX51bML+xYybotuV2DSEmR8KnhUidK/R2hpJhP/w7XXD aLgz6b20xBmEReMfRVGASpDw0HVri7Kc3EicD45DdiXJmNKCBOEnZicdCUJh7/gw0AOQ dvG+exZ03Ap9Y41bvGv89vtCFpsd34J9OeG4O1jKgxeolgp36/mwSLCMgfUdGoy6IoH6 Yu8MokbJGTT0k4j/h+3PRsnPXc3DT2RbaDJN186f+6KFADm6Pwg/BYBKdbi//a0Db5dT UHlTBZFZY2/ePfe34j06ptHsq3PWytdeckqKZJ2jUDjf4M3HgLVYdxONEOIn4Xqavadw U1kg== X-Gm-Message-State: AOAM531BDWt6a2g1DwcgI8JgoQ5EqXuKUkJKmL03qrDUNk9taFtxpWAp laPG9md3/yMGAmFzgW1di7XobSu5tRatx8/gwh9zWIL+ X-Google-Smtp-Source: ABdhPJybYaQ79p3pSmwDc1mGimk7p7XkjcFTWGj6lqrTI5X3+JGb+C7mSQYKbe24f98gXR3H+wX4CX8dSEWIuThrEiY= X-Received: by 2002:a81:190f:0:b0:2d6:2526:7925 with SMTP id 15-20020a81190f000000b002d625267925mr27993264ywz.513.1646177812866; Tue, 01 Mar 2022 15:36:52 -0800 (PST) MIME-Version: 1.0 References: <202202220002.21M02d4g023128@cuzuco.com> <9B4B0854-92D1-4DAC-A0C2-8782F1587326@jon.es> In-Reply-To: <9B4B0854-92D1-4DAC-A0C2-8782F1587326@jon.es> From: "John P. Linderman" Date: Tue, 1 Mar 2022 18:36:42 -0500 Message-ID: To: Terry Jones Content-Type: multipart/alternative; boundary="000000000000c5eae905d930a36b" Subject: [TUHS] Time for a subject change X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: The Unix Heritage Society , Brian Walden Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" --000000000000c5eae905d930a36b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=E2=80=99m 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 function= s > 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!=3DQ]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 befo= re > > 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 implemente= d > it > > in dc -- > > > > > [0ksslk3^16lkd12+sk*-lm*lhd1+sh3^/smlx_262537412640768000*sxll545140134+d= sllm*lxlnk/ls+dls!=3DP]sP > > 7sn[6sk1ddshsxsm13591409dsllPx10005v426880*ls/K3-k1/pcln14+snlMx]dsMx > > > > At 99 digits of scale it ran out in 7 rounds, but now with that limitatio= n > > 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=3D@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=3D@l!l^!<#]s#[s/0ds^]s@[p]s&[ddv= s^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=3D@l!l^!<#]s#[s/0ds^]s@[p]s&[ddv= s^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 > > > --000000000000c5eae905d930a36b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This thread has long since diverged from Lorinda and her deat= h. I'm fine with a discussion of some of Lorinda's work, but let= 9;s talk about bc or dc in a separate thread that has nothing to do with Lo= rinda.

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

I=E2=80=99m 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).

=C2=A0

To get more functionality, I wrote a Python RPN c= alculator (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

=C2=A0

Terry=

=C2=A0<= /span>

=C2=A0=C2=A0=C2=A0=C2=A0resolution. The computer = banks will work on this problem to the

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

<= div>

on anymore its really old --

=C2=A0

314159265358979323846264338327950288419716939937510582097494= 4592307816\

406286208998= 6280348253421170679821480865132823066470938446095505822317\

253594081284811174502841027019385211055= 5964462294895493038196442881097\

566593344612847564823378678316527120190914564856692346034861045432= 6648\

213393607260249141= 2737245870066063155881748815209209628292540917153643\

678925903600113305305488204665213841469519415= 1160943305727036575959195\

3092186117381932611793105118548074462379962749567351885752724891227938\<= u>

183011949129833673362440= 6566430860213949463952247371907021798609437027\

705392171762931767523846748184676694051320005681271= 4526356082778577134\

275= 7789609173637178721468440901224953430146549585371050792279689258923\=

542019956112129021960864034418= 1598136297747713099605187072113499999983\

729780499510597317328160963185950244594553469083026425223= 0825334468503\

526193118= 8171010003137838752886587533208381420617177669147303598253490\

428755468731159562863882353787593751= 9577818577805321712268066130019278\

76611195909216420198938095257201065485862972

<= /div>

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=

=C2=A0

=

=C2=A0

But I was much happier with that.

=C2=A0

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.

=C2=A0

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

in dc --

=

=C2=A0

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

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

=C2= =A0

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

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

=C2=A0

-Brian

<= p class=3D"MsoNormal">=C2=A0

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

=

=C2=A0

Otto Moerbeek wrote:

On Thu, Feb 17, 2022 at 01:44:07PM -0800,= Bakul Shah wrote:

=C2=A0

> >

> > On Thu, 17 Feb 2022, Tom Ivar Helbekkmo via TUHS wrote:=

> >

> >> Watching the prime number gene= rator (from the Wikipedia page on dc)

> >> running on the 11/23 is much more entertaining= than doing it on the

&g= t; >> modern workstation I'm typing this on:

> >>

> >> 2p3p[dl!d2+s!%0=3D@l!l^!<#]s#[s/0ds^]= s@[p]s&[ddvs^3s!l#x0<&2+l.x]ds.x

> >

> > Wow...=C2=A0=C2=A0About 10s on my old MacBook Pro, and I ga= ve up on my ancient

>= > FreeBSD box.

><= u>=C2=A0

> That may be b= ecause FreeBSD continues computing primes while the MacOS

=

> dc gives up after a while!=

>=C2=A0

> freebsd (ryzen 2700 3.2Ghz): # note: I in= terrupted dc after a while

> $ command time dc <<< '2p3p[dl!d2+s!%0=3D@l!l^!<#]s= #[s/0ds^]s@[p]s&[ddvs^3s!l#x0<&2+l.x]ds.x' > xxx

> ^C=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 11.93 real=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A011.7= 9 user=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 0.13 sys

> $ wc xxx

>=C2=A0=C2=A0=C2=A0=C2=A047161=C2=A0=C2=A0= 47161=C2=A0=C2=A0319109 xxx

> $ size `which dc`

>=C2=A0=C2=A0=C2=A0=C2=A0 text=C2=A0=C2=A0 data=C2=A0=C2=A0=C2=A0=C2= =A0 bss=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0dec=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 hex=C2=A0=C2=A0 filename

>=C2=A0=C2=A0 238159=C2=A0=C2=A0 2784=C2=A0=C2=A0 11072=C2=A0= =C2=A0 252015=C2=A0=C2=A0 0x3d86f=C2=A0=C2=A0 /usr/bin/dc

=

>=C2=A0

> MacOS (m1 pro, prob. 2Ghz)

> $ command time dc <<< '2p3p[= dl!d2+s!%0=3D@l!l^!<#]s#[s/0ds^]s@[p]s&[ddvs^3s!l#x0<&2+l.x]d= s.x' > xxx

> t= ime: command terminated abnormally

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1.00 real= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 0.98 user=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 0.01 sys

> [2]=C2=A0=C2=A0=C2=A0=C2=A037135 segmentation fault= =C2=A0=C2=A0command time dc <<<=C2=A0=C2=A0> xxx<= /p>

> $ wc xxx

<= div>

>=C2=A0=C2=A0=C2=A0=C2=A0 7342=C2=A0=C2=A0=C2= =A0=C2=A07342=C2=A0=C2=A0 42626 xxx

> $ size `which dc`

> __TEXT=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0__DATA=C2=A0=C2= =A0__OBJC=C2=A0=C2=A0others=C2=A0=C2=A0dec=C2=A0=C2=A0=C2=A0=C2=A0 hex

> 32768=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 16384=C2=A0=C2=A0 0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = 4295016448=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A04295065600=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0100018000

>=C2=A0

= =C2=A0

MacOS uses the GNU imple= mentation which has a long standing issue with

=

deep recursion. It even cannot handle the tail recur= sive calls used

here and= will run out of its stack.

=C2=A0

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 -Otto

=C2=A0

--000000000000c5eae905d930a36b--