[TUHS] Lorinda Cherry

[TUHS] Lorinda Cherry

[Brian Walden]

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

[Terry Jones]

[-- 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>
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: 15202 bytes --]

[TUHS] Time for a subject change

[John P. Linderman]

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

Re: [TUHS] Lorinda Cherry

[Norman Wilson]

Perhaps the best irrefutable source for Lorinda's contribution
to dc is that cited by https://en.wikipedia.org/wiki/Lorinda_Cherry?

It is, by the way, Doug's A Research UNIX Reader.  Those who
subscribe to this list and haven't read it ought to do so; it's
full of tidbits of history.

Norman Wilson
Toronto ON

Re: [TUHS] Lorinda Cherry

[Peter Jeremy via TUHS]

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

On 2022-Feb-17 22:18:25 -0500, Norman Wilson <norman@oclsc.org> wrote:
>Perhaps the best irrefutable source for Lorinda's contribution
>to dc is that cited by https://en.wikipedia.org/wiki/Lorinda_Cherry?
>
>It is, by the way, Doug's A Research UNIX Reader.  Those who
>subscribe to this list and haven't read it ought to do so; it's
>full of tidbits of history.

It was already referenced from the dc entry and I've added Lorinda
as a co-author with that as a citation.

-- 
Peter Jeremy

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

[TUHS] Lorinda Cherry

[Douglas McIlroy]

Lorinda Cherry, a long-time member of the original Unix Lab
died recently. Here is a slightly edited reminiscence that
I sent to the president of the National Center for Women and
Information Technology in 2018 when they honored her with
their Pioneer in Tech award.

As Lorinda Cherry's longtime colleague at Bell Labs, I was
very pleased to hear she has been chosen for the NCWIT Pioneer
Award. At the risk of telling you things you already know,
I offer some remarks about her career. I will mainly speak of
things I saw at first hand when our offices were two doors
apart, from the early '70s through 1994, when Lorinda left
Bell Labs in the AT&T/Lucent split. Most of the work I describe
broke new ground in computing; "pioneer" is an apt term.

Lorinda, like many women (including my own mother and my wife),
had to fight the system to be allowed to study math and science
in college. She was hired by Visual and Acoustics Research
at Bell Labs as a TA--the typical fate of women graduates,
while their male counterparts were hired as full members of
technical staff. It would take another decade for that unequal
treatment to be rectified. Even then, one year she received
a statement of benefits that explained what her wife would
receive upon her death. When Lorinda called HR to confirm that
they meant spouse, they said no, and demanded that the notice
be returned. (She declined.) It seemed that husbands would not
get equal treatment until AT&T lost a current court case. The
loss was a foregone conclusion; still AT&T preferred to pay
lawyers rather than widowers, and fought it to the bitter end.

Lorinda moved to my department in Computing Science when
the Unix operating system was in its infancy. Initially she
collaborated with Ken Knowlton on nascent graphics applications:
Beflix, a system for producing artistically pixillated films,
and an early program for rendering ball-and-stick molecular
models.

She then joined the (self-organized) Unix team, collaborating
on several applications with Bob Morris.

First came "dc", an unlimited-precision desk calculator,
which is still a Unix staple 45 years on. Building on dc,
she would later make "bc", which made unlimited precision
available in familiar programming-language notation and became
the interface of choice to dc.

Then came "form" and "fed", nominally a form-letter generator
and editor. In fact they were more of a personal memory
bank, a step towards Vannevar Bush's famous Memex concept--an
interesting try that didn't pay off at that scale. Memex had to
sleep two more decades before mutating into the Worldwide Web.

Lorinda had a hand in "typo", too, a Morris invention that
found gross spelling mistakes by statistical analysis. Sorting
the words of a document by the similarity of their trigrams
to those in the rest of the document tended to bring typos to
the front of the list. This worked remarkably well and gained
popularity as a spell-checker until a much less interesting
program backed by a big dictionary took over.

Taken together, these initial forays foretold a productive
computer science career centered around graphics, little
languages, and text processing.

By connecting a phototypesetter as an output device for Unix,
Joe Ossanna initiated a revolution in document preparation. The
new resource prompted a flurry of disparate looking documents
until Mike Lesk brought order to the chaos by creating a macro
package to produce a useful standard paper format.

Taking over from Lesk, Lorinda observed the difficulty of
typesetting the mathematics (which the printing industry counted
as "penalty copy") that occurred in many research papers,
and set out to simplify the task of rendering mathematical
formulas, Brian Kernighan soon joined her effort. The result
was "eqn", which built on the way people read formulas aloud
to make a quite intuitive language for describing display
formulas. Having pioneered a pattern that has been adopted
throughout the industry, eqn is still in use forty years later.

Lorinda also wrote an interpreter to render phototypesetter
copy on a cathode-ray terminal. This allowed one to see
typeset documents without the hassle of exposing and developing
film. Though everyone has similar technology at their fingertips
today, this was genuinely pioneering work at the time.

You are certainly aware of Writers Workbench, which gained
national publicity, including Lorinda's appearance on the Today
Show. It all began as a one-woman skunk-works project. Noticing
the very slow progress in natuaral-language processing, she
identified a useful subtask that could be carved out of the
larger problem: identifying parts of speech. Using a vocabulary
of function words (articles, pronouns, prepositions and
conjunctions) and rules of inflection, she was able to classify
parts of speech in running text with impressive accuracy.

When Rutgers professor William Vesterman proposed a
style-assessing program, with measures such as the frequencies
of adjectives, subordinate clauses, or compound sentences,
Lorinda was able to harness her "parts" program to implement
the idea in a couple of weeks. Subsequently Nina MacDonald,
with Lorinda's support, incorporated it into a larger suite
that checked and made suggestions about other stylistic issues
such as cliches, malapropisms, and redundancy.

Another aspect of text processing that Lorinda addressed was
topic identification. Terms (often word pairs) that occur with
abnormal frequency are likely to describe the topic at hand. She
used this idea to construct first drafts of indexes. One
in-house application was to the Unix manual, which up until
that time had only a table of contents, but no index. This
was a huge boon for a document so packed with detail.

In her final years at Bell Labs, Lorinda teamed up with AT&T
trouble-call centers to analyze the call transcripts that
attendants recorded on the fly--very sketchy prose, replete
with ad-hoc contractions and misspellings. The purpose was
to identify systemic problems that would not be obvious from
transcripts considered individually. When an unusual topic
appeared at the same time in multiple transcripts, those
transcripts were singled out for further study. The scheme
worked and led to early detection of system anomalies. In one
case, it led AT&T to suspend publication of a house organ that
rubbed customers the wrong way.

Lorinda was not cut from the same mold as most of her
colleagues. First she was a woman, which meant she faced
special obstacles. Then, while there were several pilots
among us, there was only one shower of dogs and only one car
racer--moreover one who became a regional exec of the Sports
Car Club of America. For years she organized and officiated
at races as well as participating.

Lorinda was always determined, but never pushy. The
determination shows in her success in text analysis, which
involves much sheer grit--there are no theoretical shortcuts
in this subject. She published little, but did a lot. I am
glad to see her honored.

Doug McIlroy

Re: [TUHS] Lorinda Cherry

[Steve Nickolas]

On Tue, 15 Feb 2022, Douglas McIlroy wrote:

> First came "dc", an unlimited-precision desk calculator,
> which is still a Unix staple 45 years on. Building on dc,
> she would later make "bc", which made unlimited precision
> available in familiar programming-language notation and became
> the interface of choice to dc.

In the form of GNU/NetBSD bc, I use bc(1) to this day as my tool of choice 
for quick calculations.

-uso.

Re: [TUHS] Lorinda Cherry

[Jim Capp]

Ditto on bc, in Linux. 

> On Feb 15, 2022, at 6:36 PM, Steve Nickolas <usotsuki@buric.co> wrote:
> 
> On Tue, 15 Feb 2022, Douglas McIlroy wrote:
> 
>> First came "dc", an unlimited-precision desk calculator,
>> which is still a Unix staple 45 years on. Building on dc,
>> she would later make "bc", which made unlimited precision
>> available in familiar programming-language notation and became
>> the interface of choice to dc.
> 
> In the form of GNU/NetBSD bc, I use bc(1) to this day as my tool of choice for quick calculations.
> 
> -uso.

Re: [TUHS] Lorinda Cherry

[Larry McVoy]

I do a ton of stuff in bc, it works well because when I get an answer
I didn't expect, I can scroll backward and see where I screwed up.

Nice writeup, Doug, I wish I had met her, she sounds like a super
substantial person.

On Tue, Feb 15, 2022 at 06:43:27PM -0500, Jim Capp wrote:
> Ditto on bc, in Linux. 
> 
> > On Feb 15, 2022, at 6:36 PM, Steve Nickolas <usotsuki@buric.co> wrote:
> > 
> > ???On Tue, 15 Feb 2022, Douglas McIlroy wrote:
> > 
> >> First came "dc", an unlimited-precision desk calculator,
> >> which is still a Unix staple 45 years on. Building on dc,
> >> she would later make "bc", which made unlimited precision
> >> available in familiar programming-language notation and became
> >> the interface of choice to dc.
> > 
> > In the form of GNU/NetBSD bc, I use bc(1) to this day as my tool of choice for quick calculations.
> > 
> > -uso.

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

Re: [TUHS] Lorinda Cherry

[Will Senn]

bc is my all time favorite calculator. I feel incomplete whenever I sit 
down at a Windows machine and have to pull up the so-called calculator 
there. And nothing beats it for simple base conversion, either. As a 
front-end for dc it's fun to have students wonder about the dual 
processes, then show them how they work together. Really good example of 
the unix way of doing things. Too bad they went and combined them in 
recent days.


On 2/15/22 5:51 PM, Larry McVoy wrote:
> I do a ton of stuff in bc, it works well because when I get an answer
> I didn't expect, I can scroll backward and see where I screwed up.
>
> Nice writeup, Doug, I wish I had met her, she sounds like a super
> substantial person.
>
> On Tue, Feb 15, 2022 at 06:43:27PM -0500, Jim Capp wrote:
>> Ditto on bc, in Linux.
>>
>>> On Feb 15, 2022, at 6:36 PM, Steve Nickolas <usotsuki@buric.co> wrote:
>>>
>>> ???On Tue, 15 Feb 2022, Douglas McIlroy wrote:
>>>
>>>> First came "dc", an unlimited-precision desk calculator,
>>>> which is still a Unix staple 45 years on. Building on dc,
>>>> she would later make "bc", which made unlimited precision
>>>> available in familiar programming-language notation and became
>>>> the interface of choice to dc.
>>> In the form of GNU/NetBSD bc, I use bc(1) to this day as my tool of choice for quick calculations.
>>>
>>> -uso.

Re: [TUHS] Lorinda Cherry

[Steve Nickolas]

On Tue, 15 Feb 2022, Will Senn wrote:

> bc is my all time favorite calculator. I feel incomplete whenever I sit down 
> at a Windows machine and have to pull up the so-called calculator there. And 
> nothing beats it for simple base conversion, either. As a front-end for dc 
> it's fun to have students wonder about the dual processes, then show them how 
> they work together. Really good example of the unix way of doing things. Too 
> bad they went and combined them in recent days.

You can use GNU's bc on Windows - that's what I do ;)

-uso.

Re: [TUHS] Lorinda Cherry

[George Michaelson]

I wrote a major part of the UQ phone directory in EQN, to post process
T/Roff output so the existing bromide-mechanical printing braces for
grouping common phoneline holders could be done in the new
phototypesetter. Eqn was the tool which got me out of a self-dug hole
over-promising delivery of "print-equivalent" outcome here.

I use BC as a daily driver like most people. I never quite got DC, and
wondered at the duality of them. Very interesting to have the
background explained.

The trigraph spelling checker sounds wonderful.

Thanks for posting this.

_G

On Wed, Feb 16, 2022 at 8:35 AM Douglas McIlroy
<douglas.mcilroy@dartmouth.edu> wrote:
>
> Lorinda Cherry, a long-time member of the original Unix Lab
> died recently. Here is a slightly edited reminiscence that
> I sent to the president of the National Center for Women and
> Information Technology in 2018 when they honored her with
> their Pioneer in Tech award.
>
> As Lorinda Cherry's longtime colleague at Bell Labs, I was
> very pleased to hear she has been chosen for the NCWIT Pioneer
> Award. At the risk of telling you things you already know,
> I offer some remarks about her career. I will mainly speak of
> things I saw at first hand when our offices were two doors
> apart, from the early '70s through 1994, when Lorinda left
> Bell Labs in the AT&T/Lucent split. Most of the work I describe
> broke new ground in computing; "pioneer" is an apt term.
>
> Lorinda, like many women (including my own mother and my wife),
> had to fight the system to be allowed to study math and science
> in college. She was hired by Visual and Acoustics Research
> at Bell Labs as a TA--the typical fate of women graduates,
> while their male counterparts were hired as full members of
> technical staff. It would take another decade for that unequal
> treatment to be rectified. Even then, one year she received
> a statement of benefits that explained what her wife would
> receive upon her death. When Lorinda called HR to confirm that
> they meant spouse, they said no, and demanded that the notice
> be returned. (She declined.) It seemed that husbands would not
> get equal treatment until AT&T lost a current court case. The
> loss was a foregone conclusion; still AT&T preferred to pay
> lawyers rather than widowers, and fought it to the bitter end.
>
> Lorinda moved to my department in Computing Science when
> the Unix operating system was in its infancy. Initially she
> collaborated with Ken Knowlton on nascent graphics applications:
> Beflix, a system for producing artistically pixillated films,
> and an early program for rendering ball-and-stick molecular
> models.
>
> She then joined the (self-organized) Unix team, collaborating
> on several applications with Bob Morris.
>
> First came "dc", an unlimited-precision desk calculator,
> which is still a Unix staple 45 years on. Building on dc,
> she would later make "bc", which made unlimited precision
> available in familiar programming-language notation and became
> the interface of choice to dc.
>
> Then came "form" and "fed", nominally a form-letter generator
> and editor. In fact they were more of a personal memory
> bank, a step towards Vannevar Bush's famous Memex concept--an
> interesting try that didn't pay off at that scale. Memex had to
> sleep two more decades before mutating into the Worldwide Web.
>
> Lorinda had a hand in "typo", too, a Morris invention that
> found gross spelling mistakes by statistical analysis. Sorting
> the words of a document by the similarity of their trigrams
> to those in the rest of the document tended to bring typos to
> the front of the list. This worked remarkably well and gained
> popularity as a spell-checker until a much less interesting
> program backed by a big dictionary took over.
>
> Taken together, these initial forays foretold a productive
> computer science career centered around graphics, little
> languages, and text processing.
>
> By connecting a phototypesetter as an output device for Unix,
> Joe Ossanna initiated a revolution in document preparation. The
> new resource prompted a flurry of disparate looking documents
> until Mike Lesk brought order to the chaos by creating a macro
> package to produce a useful standard paper format.
>
> Taking over from Lesk, Lorinda observed the difficulty of
> typesetting the mathematics (which the printing industry counted
> as "penalty copy") that occurred in many research papers,
> and set out to simplify the task of rendering mathematical
> formulas, Brian Kernighan soon joined her effort. The result
> was "eqn", which built on the way people read formulas aloud
> to make a quite intuitive language for describing display
> formulas. Having pioneered a pattern that has been adopted
> throughout the industry, eqn is still in use forty years later.
>
> Lorinda also wrote an interpreter to render phototypesetter
> copy on a cathode-ray terminal. This allowed one to see
> typeset documents without the hassle of exposing and developing
> film. Though everyone has similar technology at their fingertips
> today, this was genuinely pioneering work at the time.
>
> You are certainly aware of Writers Workbench, which gained
> national publicity, including Lorinda's appearance on the Today
> Show. It all began as a one-woman skunk-works project. Noticing
> the very slow progress in natuaral-language processing, she
> identified a useful subtask that could be carved out of the
> larger problem: identifying parts of speech. Using a vocabulary
> of function words (articles, pronouns, prepositions and
> conjunctions) and rules of inflection, she was able to classify
> parts of speech in running text with impressive accuracy.
>
> When Rutgers professor William Vesterman proposed a
> style-assessing program, with measures such as the frequencies
> of adjectives, subordinate clauses, or compound sentences,
> Lorinda was able to harness her "parts" program to implement
> the idea in a couple of weeks. Subsequently Nina MacDonald,
> with Lorinda's support, incorporated it into a larger suite
> that checked and made suggestions about other stylistic issues
> such as cliches, malapropisms, and redundancy.
>
> Another aspect of text processing that Lorinda addressed was
> topic identification. Terms (often word pairs) that occur with
> abnormal frequency are likely to describe the topic at hand. She
> used this idea to construct first drafts of indexes. One
> in-house application was to the Unix manual, which up until
> that time had only a table of contents, but no index. This
> was a huge boon for a document so packed with detail.
>
> In her final years at Bell Labs, Lorinda teamed up with AT&T
> trouble-call centers to analyze the call transcripts that
> attendants recorded on the fly--very sketchy prose, replete
> with ad-hoc contractions and misspellings. The purpose was
> to identify systemic problems that would not be obvious from
> transcripts considered individually. When an unusual topic
> appeared at the same time in multiple transcripts, those
> transcripts were singled out for further study. The scheme
> worked and led to early detection of system anomalies. In one
> case, it led AT&T to suspend publication of a house organ that
> rubbed customers the wrong way.
>
> Lorinda was not cut from the same mold as most of her
> colleagues. First she was a woman, which meant she faced
> special obstacles. Then, while there were several pilots
> among us, there was only one shower of dogs and only one car
> racer--moreover one who became a regional exec of the Sports
> Car Club of America. For years she organized and officiated
> at races as well as participating.
>
> Lorinda was always determined, but never pushy. The
> determination shows in her success in text analysis, which
> involves much sheer grit--there are no theoretical shortcuts
> in this subject. She published little, but did a lot. I am
> glad to see her honored.
>
> Doug McIlroy

Re: [TUHS] Lorinda Cherry

[Dave Horsfall]

On Wed, 16 Feb 2022, George Michaelson wrote:

> I use BC as a daily driver like most people. I never quite got DC, and 
> wondered at the duality of them. Very interesting to have the background 
> explained.

You know you're a greybeard if you can remember why the DC sequence 
"99k2vp8opq" was so popular...

-- Dave

Re: [TUHS] Lorinda Cherry

[arnold]

Dave Horsfall <dave@horsfall.org> wrote:

> On Wed, 16 Feb 2022, George Michaelson wrote:
>
> > I use BC as a daily driver like most people. I never quite got DC, and 
> > wondered at the duality of them. Very interesting to have the background 
> > explained.
>
> You know you're a greybeard if you can remember why the DC sequence 
> "99k2vp8opq" was so popular...
>
> -- Dave

I guess I'm not enough of a greybeard:

$ dc
99k2vp8opq
1.4142135623730950488016887242096980785696718753769480731766797379907\
32478462107038850387534327641572
1.3240474631771674622042627661154672512575174353366027242235650231664\
2753102603147144252257620301035270505416503

I recognize the first value as the square root of two. What is
the second value?

Thanks,

Arnold

Re: [TUHS] Lorinda Cherry

[markus schnalke]

Hoi.

[2022-02-16 00:54] arnold@skeeve.com
> Dave Horsfall <dave@horsfall.org> wrote:
> > On Wed, 16 Feb 2022, George Michaelson wrote:
> >
> > > I use BC as a daily driver like most people. I never quite got DC, and 
> > > wondered at the duality of them. Very interesting to have the background 
> > > explained.
> >
> > You know you're a greybeard if you can remember why the DC sequence 
> > "99k2vp8opq" was so popular...
> >
> > -- Dave
> 
> I guess I'm not enough of a greybeard:
> 
> $ dc
> 99k2vp8opq
> 1.4142135623730950488016887242096980785696718753769480731766797379907\
> 32478462107038850387534327641572
> 1.3240474631771674622042627661154672512575174353366027242235650231664\
> 2753102603147144252257620301035270505416503
> 
> I recognize the first value as the square root of two. What is
> the second value?

Decoding the program with the manpage:

	99k	set scaling factor to 99 (i.e. 99 digits on output)
	2v	square root of 2
	p	print it (but leave it on the stack)
	8o	switch to octal output
	p	print the same value (now in octal)
	q	quit

More interesting is the question why you need sqrt(2) in octal?


meillo

Re: [TUHS] Lorinda Cherry

[Leah Neukirchen]

markus schnalke <meillo@marmaro.de> writes:

> Hoi.
>
> [2022-02-16 00:54] arnold@skeeve.com
>> Dave Horsfall <dave@horsfall.org> wrote:
>> >
>> > You know you're a greybeard if you can remember why the DC sequence 
>> > "99k2vp8opq" was so popular...
>> >
>> > -- Dave
>> 
>> I guess I'm not enough of a greybeard:
>> 
>> $ dc
>> 99k2vp8opq
>> 1.4142135623730950488016887242096980785696718753769480731766797379907\
>> 32478462107038850387534327641572
>> 1.3240474631771674622042627661154672512575174353366027242235650231664\
>> 2753102603147144252257620301035270505416503
>> 
>> I recognize the first value as the square root of two. What is
>> the second value?
>
> Decoding the program with the manpage:
>
> 	99k	set scaling factor to 99 (i.e. 99 digits on output)
> 	2v	square root of 2
> 	p	print it (but leave it on the stack)
> 	8o	switch to octal output
> 	p	print the same value (now in octal)
> 	q	quit
>
> More interesting is the question why you need sqrt(2) in octal?

Apparently it was a popular benchmark back in the day:
https://www.tuhs.org/Archive/Documentation/AUUGN/AUUGN-V05.1.pdf

> Tim Long: Quick Benchmarks of the Machines on Display
> A simple cpu-bound benchmark was run on each of the machines on display.
> The benchmark was "echo 99k2vp8opq I /bin/time dc > /dev/null’. It uses dc
> (the desk calculator) to calculate the square root of 2 to 99 decimal places,
> and to "print" the result in decimal and then in octal. The results are in
> fact never printed, being piped to /dev/null. The user time is all that is
> compared.
> This benchmark has been applied to a large number of machines° It has
> (up until now) been useful because most manufacturers have not optimised dc,
> so the results are not likely to have been distorted by attempts to optimise
> for benchmarks.

> The results were:
> DoEo UNITY (DE-68K) 11.3 sec
> Plexus P/25 14.1 sec
> NCR Tower 21.3 sec
> Wicat 150WS 27.3 sec
> Unison 32.6 sec

> By comparison, a VAX 11/780 clocks about 5 to 6 secs, VAX750 9 sec, PDPIIs
> range from 27 secs (11/23) to 6 secs (11/70), PDP ii/34s range from 12 to 19
> secs depending upon the presence of a cache. Perkin-Elmer range from 12o5
> secs (32/10) to 7°9 secs (32/40)o

I looks like V7 dc used 100-limbs internally, so printing in decimal
was fast, but printing in octal required conversion.

-- 
Leah Neukirchen  <leah@vuxu.org>  https://leahneukirchen.org/

Re: [TUHS] Lorinda Cherry

[Dave Horsfall]

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

On Wed, 16 Feb 2022, Leah Neukirchen wrote:

> Apparently it was a popular benchmark back in the day:
> https://www.tuhs.org/Archive/Documentation/AUUGN/AUUGN-V05.1.pdf

Yep.

> > The benchmark was "echo 99k2vp8opq I /bin/time dc > /dev/null’. It 
> > uses dc (the desk calculator) to calculate the square root of 2 to 99 
> > decimal places,

Ugh; that "I" ought to be "|" (and I can see other typos), so someone 
really needs to proofread those PDF scans if they're going to be regarded 
as authoritative.  Yes, I can help...

> > This benchmark has been applied to a large number of machines° It has 
> > (up until now) been useful because most manufacturers have not 
> > optimised dc, so the results are not likely to have been distorted by 
> > attempts to optimise for benchmarks.

Indeed, when a lot of compilers recognised the Sieve of Eratosthenes being 
used and optimised for it...  Wasn't all that long ago that vehicle 
manufacturers also started doing the same thing :-)

> > Wicat 150WS 27.3 sec
> > Unison 32.6 sec

The WICAT 150 was just a terminal with several serial ports, and was 
p*ss-awful (I worked for Lionel Singer, and had to support the poxy 
thing); I'm surprised that it beat another box, though...

> I looks like V7 dc used 100-limbs internally, so printing in decimal was 
> fast, but printing in octal required conversion.

Yep; extra work for the CPU.  Not much of a benchmark these days, as CPUs 
are really fast; when I was supporting Unify I used to use its automatic 
tutorial as a benchmark, and I used to joke that I needed a calendar on 
some boxes...

Trivia: Lionel Singer also sold the then-new Sun-3, and we had one set up 
at an AUUG conference, giggling whenever someone tried that benchmark; 
what they didn't know was that the prominent window was actually an 
"rlogin" to the Gould that we also sold...  The looks on their faces were 
priceless :-)

-- Dave

Re: [TUHS] Lorinda Cherry

[Andrew Diller]

> On Feb 16, 2022, at 5:27 PM, Dave Horsfall <dave@horsfall.org> wrote:
> 
> On Wed, 16 Feb 2022, Leah Neukirchen wrote:
> 
>> Apparently it was a popular benchmark back in the day:
>> https://www.tuhs.org/Archive/Documentation/AUUGN/AUUGN-V05.1.pdf
> 
> Yep.
> 
>>> The benchmark was "echo 99k2vp8opq I /bin/time dc > /dev/null’. It 
>>> uses dc (the desk calculator) to calculate the square root of 2 to 99 
>>> decimal places,
> 

I tried that on some of the systems I have at hand. It didn't even register on my Mac....


-------------------------------------------------

33 MHZ MIPS R3010
# echo 99k2vp8opq | /bin/time dc > /dev/null

real        0.4
user        0.3
sys         0.0
# uname -a
power power 3.3.2 12031609 IP7

-------------------------------------------------

900 MHZ MIPS R160000
$ echo 99k2vp8opq | /bin/time dc > /dev/null

real 0.009
user 0.003
sys  0.002
dillera@fuel ~ $ uname -a
IRIX64 fuel 6.5 07202013 IP35 mips IP35 Irix

-------------------------------------------------

3.5GHZ Xeon E5
$ echo 99k2vp8opq | time dc > /dev/null
        0.00 real         0.00 user         0.00 sys

dillera@trashcan ~ $ uname -a
Darwin trashcan 20.6.0 Darwin Kernel Version 20.6.0: root:xnu-7195.141.6~3/RELEASE_X86_64 x86_64

-------------------------------------------------


-andy

Re: [TUHS] Lorinda Cherry

[Peter Jeremy via TUHS]

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

On 2022-Feb-16 17:40:18 -0500, Andrew Diller <dillera@gmail.com> wrote:
>> On Feb 16, 2022, at 5:27 PM, Dave Horsfall <dave@horsfall.org> wrote:
>> 
>> On Wed, 16 Feb 2022, Leah Neukirchen wrote:
>> 
>>> Apparently it was a popular benchmark back in the day:
>>> https://www.tuhs.org/Archive/Documentation/AUUGN/AUUGN-V05.1.pdf
>> 
>> Yep.
>> 
>>>> The benchmark was "echo 99k2vp8opq I /bin/time dc > /dev/null’. It 
>>>> uses dc (the desk calculator) to calculate the square root of 2 to 99 
>>>> decimal places,
>> 
>
>I tried that on some of the systems I have at hand. It didn't even register on my Mac....

Not only didn't it register on my Ryzen 3, it didn't even register on
2.11BSD running in simh on that box.

I did get a non-zero reading on an original RPi:
$ echo 99k2vp8opq | time dc > /dev/null
        0.13 real         0.10 user         0.02 sys

-- 
Peter Jeremy

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

Re: [TUHS] Lorinda Cherry

[Adam Thornton]

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

Today I learned that "time" is a shell built-in in zsh!

adam@m1-wired:~$ echo 99k2vp8opq | time dc > /dev/null
dc > /dev/null  0.00s user 0.01s system 69% cpu 0.011 total

(M1 MacBook Air, late 2020, MacOS 12.2.1)

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

Re: [TUHS] Lorinda Cherry

[Dave Horsfall]

On Thu, 17 Feb 2022, Adam Thornton wrote:

> Today I learned that "time" is a shell built-in in zsh!

It's been a built-in in a lot of shells for ages; there is also 
[/usr]/bin/time if you want The Real Thing [tm].

-- Dave

Re: [TUHS] Lorinda Cherry

[Andy Kosela]

On Wed, Feb 16, 2022 at 11:42 PM Andrew Diller <dillera@gmail.com> wrote:
>
>
>
> > On Feb 16, 2022, at 5:27 PM, Dave Horsfall <dave@horsfall.org> wrote:
> >
> > On Wed, 16 Feb 2022, Leah Neukirchen wrote:
> >
> >> Apparently it was a popular benchmark back in the day:
> >> https://www.tuhs.org/Archive/Documentation/AUUGN/AUUGN-V05.1.pdf
> >
> > Yep.
> >
> >>> The benchmark was "echo 99k2vp8opq I /bin/time dc > /dev/null’. It
> >>> uses dc (the desk calculator) to calculate the square root of 2 to 99
> >>> decimal places,
> >
>
> I tried that on some of the systems I have at hand. It didn't even register on my Mac....

This would be more appropriate on modern machines:

moon $ sysctl machdep.cpu.brand_string; echo 9999k2vp8opq | time -p dc
> /dev/null
machdep.cpu.brand_string: Intel(R) Core(TM) i5-4258U CPU @ 2.40GHz
real         1.87
user         1.87
sys          0.00

--Andy

Re: [TUHS] Lorinda Cherry

[Andrew Hume]

altho i date back to those days, i don’t recall using that benchmark.
when i’ve needed something bc-ish to take some time, i normally
use a bessel function from bc -l

> On Feb 17, 2022, at 2:24 AM, Andy Kosela <akosela@andykosela.com> wrote:
> 
> On Wed, Feb 16, 2022 at 11:42 PM Andrew Diller <dillera@gmail.com> wrote:
>> 
>> 
>> 
>>> On Feb 16, 2022, at 5:27 PM, Dave Horsfall <dave@horsfall.org> wrote:
>>> 
>>> On Wed, 16 Feb 2022, Leah Neukirchen wrote:
>>> 
>>>> Apparently it was a popular benchmark back in the day:
>>>> https://www.tuhs.org/Archive/Documentation/AUUGN/AUUGN-V05.1.pdf
>>> 
>>> Yep.
>>> 
>>>>> The benchmark was "echo 99k2vp8opq I /bin/time dc > /dev/null’. It
>>>>> uses dc (the desk calculator) to calculate the square root of 2 to 99
>>>>> decimal places,
>>> 
>> 
>> I tried that on some of the systems I have at hand. It didn't even register on my Mac....
> 
> This would be more appropriate on modern machines:
> 
> moon $ sysctl machdep.cpu.brand_string; echo 9999k2vp8opq | time -p dc
>> /dev/null
> machdep.cpu.brand_string: Intel(R) Core(TM) i5-4258U CPU @ 2.40GHz
> real         1.87
> user         1.87
> sys          0.00
> 
> --Andy

Re: [TUHS] Lorinda Cherry

[Warner Losh]

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

Damn, you guys found a bug in my venix emulation:

% echo 99k2vp8opq | ./git/venix/tools/vm86venix/venix
./git/venix/tools/vm86venix/disbt/usr/bin/dc
pid 70803 (venix): sigreturn eflags = 0x0

I'll have to see how hard it is to setup my Rainbow 100B running Venix and
if the benchmark works there or not.
Or if this is a bug in venix's dc...

Warner

On Thu, Feb 17, 2022 at 9:33 AM Andrew Hume <andrew@humeweb.com> wrote:

> altho i date back to those days, i don’t recall using that benchmark.
> when i’ve needed something bc-ish to take some time, i normally
> use a bessel function from bc -l
>
> > On Feb 17, 2022, at 2:24 AM, Andy Kosela <akosela@andykosela.com> wrote:
> >
> > On Wed, Feb 16, 2022 at 11:42 PM Andrew Diller <dillera@gmail.com>
> wrote:
> >>
> >>
> >>
> >>> On Feb 16, 2022, at 5:27 PM, Dave Horsfall <dave@horsfall.org> wrote:
> >>>
> >>> On Wed, 16 Feb 2022, Leah Neukirchen wrote:
> >>>
> >>>> Apparently it was a popular benchmark back in the day:
> >>>> https://www.tuhs.org/Archive/Documentation/AUUGN/AUUGN-V05.1.pdf
> >>>
> >>> Yep.
> >>>
> >>>>> The benchmark was "echo 99k2vp8opq I /bin/time dc > /dev/null’. It
> >>>>> uses dc (the desk calculator) to calculate the square root of 2 to 99
> >>>>> decimal places,
> >>>
> >>
> >> I tried that on some of the systems I have at hand. It didn't even
> register on my Mac....
> >
> > This would be more appropriate on modern machines:
> >
> > moon $ sysctl machdep.cpu.brand_string; echo 9999k2vp8opq | time -p dc
> >> /dev/null
> > machdep.cpu.brand_string: Intel(R) Core(TM) i5-4258U CPU @ 2.40GHz
> > real         1.87
> > user         1.87
> > sys          0.00
> >
> > --Andy
>
>

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

Re: [TUHS] Lorinda Cherry

[Larry McVoy]

On Thu, Feb 17, 2022 at 09:27:39AM +1100, Dave Horsfall wrote:
> Indeed, when a lot of compilers recognised the Sieve of Eratosthenes being 
> used and optimised for it...  Wasn't all that long ago that vehicle 
> manufacturers also started doing the same thing :-)

Indeed.  I hated when people cheated because benchmarks should teach you
the capabilities of the machine being benchmarked.  They aren't useful
if people cheat.

When I did LMbench, the rules were "cc -O2" and you could not link with
any benchmarking libraries and you could only report a result if you
reported all results.

I had a beef with this guy: https://www.cs.jhu.edu/~shap/ because he
had some toy OS that didn't have a VM system, didn't have networking,
didn't have much of anything, but boy oh boy, did it context switch
fast (because there was no context to speak of).  He reported those
numbers in blatant violation of my rules and I had to escalate to 
get him to stop.  The bummer is he is a smart guy, capable of good
work, there is no need to cheat.

Re: [TUHS] Lorinda Cherry

[Clem Cole]

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

And before that, Fortran compilers were known to recognize Whetstone.
Mashey did his wonder talk called 'Lies, Damn Lies and Benchmarks' in the
mid-80s which begat the SPEC suite.  Wasn't perfect but it did help.
 Marketing people in particular like to grab a single number for 'goodness'
just to try to show mine is better than yours (my current disgust has been
the clock rate of the processors which sadly, my employer was one of the
worst in using as a figure of merit).

On Wed, Feb 16, 2022 at 5:44 PM Larry McVoy <lm@mcvoy.com> wrote:

> On Thu, Feb 17, 2022 at 09:27:39AM +1100, Dave Horsfall wrote:
> > Indeed, when a lot of compilers recognised the Sieve of Eratosthenes
> being
> > used and optimised for it...  Wasn't all that long ago that vehicle
> > manufacturers also started doing the same thing :-)
>
> Indeed.  I hated when people cheated because benchmarks should teach you
> the capabilities of the machine being benchmarked.  They aren't useful
> if people cheat.
>
> When I did LMbench, the rules were "cc -O2" and you could not link with
> any benchmarking libraries and you could only report a result if you
> reported all results.
>
> I had a beef with this guy: https://www.cs.jhu.edu/~shap/ because he
> had some toy OS that didn't have a VM system, didn't have networking,
> didn't have much of anything, but boy oh boy, did it context switch
> fast (because there was no context to speak of).  He reported those
> numbers in blatant violation of my rules and I had to escalate to
> get him to stop.  The bummer is he is a smart guy, capable of good
> work, there is no need to cheat.
>

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

Re: [TUHS] Lorinda Cherry

[Paul Winalski]

On 2/16/22, Clem Cole <clemc@ccc.com> wrote:
>  Marketing people in particular like to grab a single number for 'goodness'
> just to try to show mine is better than yours (my current disgust has been
> the clock rate of the processors which sadly, my employer was one of the
> worst in using as a figure of merit).
>
That, and instructions/second.  The IBM S/370 model 158 was a true 1
MIPS machine.  The VAX-11/780 executed about 500 KIPS.  But the 11/780
and the model 158 were almost a dead heat when it came to the
execution speed of real world applications.  Why?  Mainly because the
VAX architecture was a lot CISC-ier than S/370, which was basically a
load/compute/store architecture.  The VAX got a lot more done with
each individeual instruction than the S/370.

-Paul W.

Re: [TUHS] Lorinda Cherry

[Stuart Remphrey]

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

Sad news. Had read her papers in BSTJ early in my career. Very interesting
to read of her career, and thanks for the links.

I'm a daily/weekly "dc" guy (RPN ftw).
Never got into bc. Occasionally used eqn et al.

-----
> Wicat 150WS 27.3 sec
> Unison 32.6 sec
Unison must have been real slow!

Dave H. -- remember LSC's ads/posters:
    "WICAT with *new* GLTC Technology"
Lionel/someone just made up the term.
For a while no-one asked, eventually it was revealed to stand for "Goes
Like The Clappers". ("A Wet Week" more like it)

Fortunately I supported the Unix stuff from LSC Brisbane/Qld. So in my
first UNIX job I got to play with Sun2-Sun4, lots'a Pyramids, one Convex.
Don't recall LSC's Gould though; before I joined?

When our sales reps sold WICAT (68000 or 68020?) it was mostly running PICK
ported by a bloke in our office (another Dave? I recall him destroying a
phone in frustration over the UART/terminal driver). Weird O/S: efficient
on-disk hashed DB; but very prone to corruption on unclean shutdown.

On Thu, 17 Feb 2022, 06:30 Dave Horsfall, <dave@horsfall.org> wrote:

> On Wed, 16 Feb 2022, Leah Neukirchen wrote:
>
> > Apparently it was a popular benchmark back in the day:
> > https://www.tuhs.org/Archive/Documentation/AUUGN/AUUGN-V05.1.pdf
>
> Yep.
>
> > > The benchmark was "echo 99k2vp8opq I /bin/time dc > /dev/null’. It
> > > uses dc (the desk calculator) to calculate the square root of 2 to 99
> > > decimal places,
>
> Ugh; that "I" ought to be "|" (and I can see other typos), so someone
> really needs to proofread those PDF scans if they're going to be regarded
> as authoritative.  Yes, I can help...
>
> > > This benchmark has been applied to a large number of machines° It has
> > > (up until now) been useful because most manufacturers have not
> > > optimised dc, so the results are not likely to have been distorted by
> > > attempts to optimise for benchmarks.
>
> Indeed, when a lot of compilers recognised the Sieve of Eratosthenes being
> used and optimised for it...  Wasn't all that long ago that vehicle
> manufacturers also started doing the same thing :-)
>
> > > Wicat 150WS 27.3 sec
> > > Unison 32.6 sec
>
> The WICAT 150 was just a terminal with several serial ports, and was
> p*ss-awful (I worked for Lionel Singer, and had to support the poxy
> thing); I'm surprised that it beat another box, though...
>
> > I looks like V7 dc used 100-limbs internally, so printing in decimal was
> > fast, but printing in octal required conversion.
>
> Yep; extra work for the CPU.  Not much of a benchmark these days, as CPUs
> are really fast; when I was supporting Unify I used to use its automatic
> tutorial as a benchmark, and I used to joke that I needed a calendar on
> some boxes...
>
> Trivia: Lionel Singer also sold the then-new Sun-3, and we had one set up
> at an AUUG conference, giggling whenever someone tried that benchmark;
> what they didn't know was that the prominent window was actually an
> "rlogin" to the Gould that we also sold...  The looks on their faces were
> priceless :-)
>
> -- Dave

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

Re: [TUHS] Lorinda Cherry

[Tom Ivar Helbekkmo via TUHS]

Leah Neukirchen <leah@vuxu.org> writes:

> Apparently it was a popular benchmark back in the day:
> https://www.tuhs.org/Archive/Documentation/AUUGN/AUUGN-V05.1.pdf
>> [...]
>> By comparison, a VAX 11/780 clocks about 5 to 6 secs, VAX750 9 sec, PDPIIs
>> range from 27 secs (11/23) to 6 secs (11/70), PDP ii/34s range from 12 to 19
>> secs depending upon the presence of a cache. Perkin-Elmer range from 12o5
>> secs (32/10) to 7°9 secs (32/40)o

Well, I just had to run it on some older hardware...

12MHz 80286 running MINIX 1.6.25 and the classic C version of dc:
real        4.00
user        3.56
sys         0.25

DEC MicroPDP-11/23 running PWB UNIX 1.0 and the assembly coded dc:
real       29.0
user       22.2
sys         0.7

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

Incidentally, the Wikipedia page only lists Robert Morris as author of
dc.  If anyone here is able to edit Wikipedia, now would be a good time
to get Lorinda Cherry's name on there, too.

-tih
-- 
Most people who graduate with CS degrees don't understand the significance
of Lisp.  Lisp is the most important idea in computer science.  --Alan Kay

Re: [TUHS] Lorinda Cherry

[Dave Horsfall]

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.

> Incidentally, the Wikipedia page only lists Robert Morris as author of 
> dc.  If anyone here is able to edit Wikipedia, now would be a good time 
> to get Lorinda Cherry's name on there, too.

Anyone can edit Wikipedia; if you're an editor then you have your name 
shown instead of your IP address (and someone ought to fix that stupid 
"cat file | cmd" construct as well), but beware of the edit-nazis who seem 
to think that they "own" something that is factually wrong and keep 
changing it back to suit their own cultural views e.g. Kokoda Track vs. 
Trail.

-- Dave

Re: [TUHS] Lorinda Cherry

[Bakul Shah]

On Feb 17, 2022, at 1:18 PM, Dave Horsfall <dave@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

Re: [TUHS] Lorinda Cherry

[Otto Moerbeek]

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

> On Feb 17, 2022, at 1:18 PM, Dave Horsfall <dave@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

[Ralph Corderoy]

Hi Otto,

> 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.

When learning dc and seeing it relied on tail calls, the first thing
I did was check it did tail-call elimination, and it did.  That was
GNU dc.

Trying just now, I see no growth in memory usage despite heavy CPU load
shown by TIME increasing.

    $ dc
    !ps u `pidof dc`
    USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
    ralph    11489  0.0  0.0   2332  1484 pts/1    S+   10:33   0:00 dc
    [lmx]smlmx
    ^C
    Interrupt!
    !ps u `pidof dc`
    USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
    ralph    11489 75.5  0.0   2332  1488 pts/1    S+   10:33   0:46 dc

The memory used remained at that level during the macro execution too,
watched from outside.

Do you have more detail on what GNU dc can't handle?  dc without
tail-call elimination is a bit crippled.

-- 
Cheers, Ralph.

Re: [TUHS] Lorinda Cherry

[Otto Moerbeek]

On Tue, Feb 22, 2022 at 10:39:48AM +0000, Ralph Corderoy wrote:

> Hi Otto,
> 
> > 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.
> 
> When learning dc and seeing it relied on tail calls, the first thing
> I did was check it did tail-call elimination, and it did.  That was
> GNU dc.
> 
> Trying just now, I see no growth in memory usage despite heavy CPU load
> shown by TIME increasing.
> 
>     $ dc
>     !ps u `pidof dc`
>     USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
>     ralph    11489  0.0  0.0   2332  1484 pts/1    S+   10:33   0:00 dc
>     [lmx]smlmx
>     ^C
>     Interrupt!
>     !ps u `pidof dc`
>     USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
>     ralph    11489 75.5  0.0   2332  1488 pts/1    S+   10:33   0:46 dc
> 
> The memory used remained at that level during the macro execution too,
> watched from outside.
> 
> Do you have more detail on what GNU dc can't handle?  dc without
> tail-call elimination is a bit crippled.
> 
> -- 
> Cheers, Ralph.

On MacOS:

$ dc --version
dc (GNU bc 1.06) 1.3
...
$ dc
[lmx]smlmx 
Segmentation fault: 11
$

On debian bullseye:
$ dc --version
dc (GNU bc 1.07.1) 1.4.1
...
$ dc
[lmx]smlmx 
...

all ok.

So the basic tail recursion case seems to be fixed in recent versions.

But note that 

	[laxp]sa
	1 lax

still segfaults on both GNU dc versions while on OpenBSD, using the
dc I wrote:

dc: recursion too deep: Cannot allocate memory

This is not a tail recursion case, but segfaulting is not nice at all.

	-Otto

Re: [TUHS] Lorinda Cherry

[Derek Fawcus]

On Thu, Feb 17, 2022 at 01:44:07PM -0800, Bakul Shah wrote:
> 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

So macOS has got worse, or the systems have:

$ sysctl machdep.cpu.brand_string
machdep.cpu.brand_string: Intel(R) Core(TM)2 Duo CPU     U9400  @ 1.40GHz
$ uname -a
Darwin Old-MBA.local 15.6.0 Darwin Kernel Version 15.6.0: Thu Jun 21 20:07:40 PDT 2018; root:xnu-3248.73.11~1/RELEASE_X86_64 x86_64
Old-MBA:~ derek$ 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
Segmentation fault: 11

real	0m14.982s
user	0m12.608s
sys	0m0.206s
$ wc xxx
    7868    7868   45782 xxx

My old machine computed more primes before the program crashed!
Given the comment about the GNU s/w running out of stack, I guess the x86 version uses smaller stack frames.

DF

Re: [TUHS] Lorinda Cherry

[David Arnold]

> On 18 Feb 2022, at 08:18, Dave Horsfall <dave@horsfall.org> wrote:

<…>

>> Incidentally, the Wikipedia page only lists Robert Morris as author of 
>> dc.  If anyone here is able to edit Wikipedia, now would be a good time 
>> to get Lorinda Cherry's name on there, too.
> 
> Anyone can edit Wikipedia; if you're an editor then you have your name 
> shown instead of your IP address (and someone ought to fix that stupid 
> "cat file | cmd" construct as well), but beware of the edit-nazis who seem 
> to think that they "own" something that is factually wrong and keep 
> changing it back to suit their own cultural views e.g. Kokoda Track vs. 
> Trail.

The best solution to that is citing an irrefutable source (I mean, at
least for non-contested things).  I can edit if you can point me at
something definitive?




d

Re: [TUHS] Lorinda Cherry

[Tom Ivar Helbekkmo via TUHS]

Dave Horsfall <dave@horsfall.org> writes:

>> 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 program shouldn't be redirected to /dev/null, but watched.
It doesn't terminate; it just keeps printing prime numbers.  :)

-tih
-- 
Most people who graduate with CS degrees don't understand the significance
of Lisp.  Lisp is the most important idea in computer science.  --Alan Kay

Re: [TUHS] Lorinda Cherry

[Diomidis Spinellis]

A description of text processing work at Bell Labs, including the use of 
trigrams for spell checking, readability analysis, and word class 
assignment was published in the BSTJ.

L. E. McMahon; L. L. Cherry; R. Morris. Statistical text processing. The 
Bell System Technical Journal, 57(6):2137-2154, July-Aug. 1978.
DOI: 10.1002/j.1538-7305.1978.tb02146.x

You can find it openly available online at:
https://archive.org/details/bstj57-6-2137/mode/2up

The article was part of an amazing special issue of BSTJ devoted to 
Unix.  A second such issue, 63(8) was published on October 1984.  In the 
late 1980s both issues were also sold as books by Prentice Hall under 
the title "UNIX System Readings and Applications".  I broke the bank 
buying them as a student, but didn't regret it.

Diomidis - https://www.spinellis.gr

On 16-Feb-22 2:09, George Michaelson wrote:
> The trigraph spelling checker sounds wonderful.

Re: [TUHS] Lorinda Cherry

[John P. Linderman]

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

Someone unearthed a 1982 video in which Lorinda explains some of her work.

https://www.youtube.com/watch?v=XvDZLjaCJuw&t=828s

You can watch the whole thing by just lopping off the '&t=828s' at the end.

On Wed, Feb 16, 2022 at 2:18 PM Diomidis Spinellis <dds@aueb.gr> wrote:

> A description of text processing work at Bell Labs, including the use of
> trigrams for spell checking, readability analysis, and word class
> assignment was published in the BSTJ.
>
> L. E. McMahon; L. L. Cherry; R. Morris. Statistical text processing. The
> Bell System Technical Journal, 57(6):2137-2154, July-Aug. 1978.
> DOI: 10.1002/j.1538-7305.1978.tb02146.x
>
> You can find it openly available online at:
> https://archive.org/details/bstj57-6-2137/mode/2up
>
> The article was part of an amazing special issue of BSTJ devoted to
> Unix.  A second such issue, 63(8) was published on October 1984.  In the
> late 1980s both issues were also sold as books by Prentice Hall under
> the title "UNIX System Readings and Applications".  I broke the bank
> buying them as a student, but didn't regret it.
>
> Diomidis - https://www.spinellis.gr
>
> On 16-Feb-22 2:09, George Michaelson wrote:
> > The trigraph spelling checker sounds wonderful.
>

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

Re: [TUHS] Lorinda Cherry

[Andrew Hume]

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

what a hoot of a program!!
so many folks: john mashey, vi vyssocki[sic], denis, thommo,
lorinda, cathi brooks (my second supervisor at the labs, system 3 days),
kernighan, al aho.

> On Feb 16, 2022, at 12:55 PM, John P. Linderman <jpl.jpl@gmail.com> wrote:
> 
> Someone unearthed a 1982 video in which Lorinda explains some of her work.
> 
> https://www.youtube.com/watch?v=XvDZLjaCJuw&t=828s <https://www.youtube.com/watch?v=XvDZLjaCJuw&t=828s>
> 


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

Re: [TUHS] Lorinda Cherry

[Marshall Conover]

Oh wow - a week or two ago I linked this video to a coworker who asked
me how to "get into" nix systems when he saw me chaining a few
commands together with pipes. Lorinda's section was one of the ones I
pointed to as 'definitely pay hard attention to this bit' - well,
maybe up until the coffee sipping with the numbers being read out. (Of
course, that's not to say the rest of the video isn't important!)

Thanks all for sharing your memories.

Cheers,

Marshall


On Wed, Feb 16, 2022 at 4:02 PM John P. Linderman <jpl.jpl@gmail.com> wrote:
>
> Someone unearthed a 1982 video in which Lorinda explains some of her work.
>
> https://www.youtube.com/watch?v=XvDZLjaCJuw&t=828s
>
> You can watch the whole thing by just lopping off the '&t=828s' at the end.
>
> On Wed, Feb 16, 2022 at 2:18 PM Diomidis Spinellis <dds@aueb.gr> wrote:
>>
>> A description of text processing work at Bell Labs, including the use of
>> trigrams for spell checking, readability analysis, and word class
>> assignment was published in the BSTJ.
>>
>> L. E. McMahon; L. L. Cherry; R. Morris. Statistical text processing. The
>> Bell System Technical Journal, 57(6):2137-2154, July-Aug. 1978.
>> DOI: 10.1002/j.1538-7305.1978.tb02146.x
>>
>> You can find it openly available online at:
>> https://archive.org/details/bstj57-6-2137/mode/2up
>>
>> The article was part of an amazing special issue of BSTJ devoted to
>> Unix.  A second such issue, 63(8) was published on October 1984.  In the
>> late 1980s both issues were also sold as books by Prentice Hall under
>> the title "UNIX System Readings and Applications".  I broke the bank
>> buying them as a student, but didn't regret it.
>>
>> Diomidis - https://www.spinellis.gr
>>
>> On 16-Feb-22 2:09, George Michaelson wrote:
>> > The trigraph spelling checker sounds wonderful.

Re: [TUHS] Lorinda Cherry

[arnold]

Diomidis Spinellis <dds@aueb.gr> wrote:

> The article was part of an amazing special issue of BSTJ devoted to 
> Unix.  A second such issue, 63(8) was published on October 1984.

I have original copies of both, bought directly from Bell Labs, back
in the day. :-)

I should dig them out and go through them again.

Arnold

Re: [TUHS] Lorinda Cherry

[Will Senn]

Diomidis,

Thanks for the reading suggestion. I've done a lot of work with n-grams. 
Nice to see a pragmatic treatment of the subject. Too bad I didn't read 
it back in school. BTW, Volume 1 UNIX System Readings and Applications 
(reprint of 1978 BSTJ 57:6 part 2 - the UNIX issue) is available at:

http://www.bitsavers.org/pdf/att/unix/UNIX_System_Readings_and_Applications_Volume_1_1987.pdf

And, volume 2 UNIX System Readings and Applications (1984 BSTJ 63:8 - 
the 2nd UNIX issue) is also available, at:

http://www.bitsavers.org/pdf/att/unix/UNIX_System_Readings_and_Applications_Volume_2_1987.pdf

Much cleaner than the other copies.

Will


On 2/16/22 1:08 PM, Diomidis Spinellis wrote:
> A description of text processing work at Bell Labs, including the use 
> of trigrams for spell checking, readability analysis, and word class 
> assignment was published in the BSTJ.
>
> L. E. McMahon; L. L. Cherry; R. Morris. Statistical text processing. 
> The Bell System Technical Journal, 57(6):2137-2154, July-Aug. 1978.
> DOI: 10.1002/j.1538-7305.1978.tb02146.x
>
> You can find it openly available online at:
> https://archive.org/details/bstj57-6-2137/mode/2up
>
> The article was part of an amazing special issue of BSTJ devoted to 
> Unix.  A second such issue, 63(8) was published on October 1984.  In 
> the late 1980s both issues were also sold as books by Prentice Hall 
> under the title "UNIX System Readings and Applications".  I broke the 
> bank buying them as a student, but didn't regret it.
>
> Diomidis - https://www.spinellis.gr
>
> On 16-Feb-22 2:09, George Michaelson wrote:
>> The trigraph spelling checker sounds wonderful.

Re: [TUHS] Lorinda Cherry

[Andrew Hume]

for many years, my office was diagonally opposite lorinda’s.
we worked together most closely on the Unix manuals
(ninth and tenth editions); lorinda spent considerable work
on the permuted indices and the papers on Volume 2.

she also shared in my my own weird story of synchronicity.
i had been doing some work on polyhedra composed of
regular polyhedra. to prove to myself that i had gotten things
correct, i constructed a folding program to form the polyhedra
by folding a flat network of faces. i did this in bc and verified that
the vertices were sufficiently close together. and indeed, as i increased
the precision, the points coincided. except one didn’t.
for one polyhedra, one vertex stubbornly never got closer
than about 1e-6 from its (supposedly) coincident alter points.
it took about 3-4 days before i found the problem; in some exceptionally
rare cases, division in bc yielded the wrong answer.
i race around to lorinda to show her the problem (it was in the underlying
dc code). to my astonishment, lorinda listened and said
“you know, not 30 minutes ago, Vic Vyssotsky (our executive director)
came in with exactly the same problem.” he had discovered it by using
an extremely long-winded cyclical calculation used to detect errors
in arithmetic units. she then discovered the bug occurred when she converted
the original assembler code into C. the weird part was that this bug
had been latent for some years, and two different people reported it
to her with 30 minutes.

Re: [TUHS] Lorinda Cherry

[Thomas Paulsen]

I didn't know that. R.I.P great programmer!

--- Ursprüngliche Nachricht ---
Von: Douglas McIlroy <douglas.mcilroy@dartmouth.edu>
Datum: 15.02.2022 23:31:03
An: TUHS main list <tuhs@minnie.tuhs.org>
Betreff: [TUHS] Lorinda Cherry

Lorinda Cherry, a long-time member of the original Unix Lab
died recently. Here is a slightly edited reminiscence that
I sent to the president of the National Center for Women and
Information Technology in 2018 when they honored her with
their Pioneer in Tech award.

As Lorinda Cherry's longtime colleague at Bell Labs, I was
very pleased to hear she has been chosen for the NCWIT Pioneer
Award. At the risk of telling you things you already know,
I offer some remarks about her career. I will mainly speak of
things I saw at first hand when our offices were two doors
apart, from the early '70s through 1994, when Lorinda left
Bell Labs in the AT&T/Lucent split. Most of the work I describe
broke new ground in computing; "pioneer" is an apt term.

Lorinda, like many women (including my own mother and my wife),
had to fight the system to be allowed to study math and science
in college. She was hired by Visual and Acoustics Research
at Bell Labs as a TA--the typical fate of women graduates,
while their male counterparts were hired as full members of
technical staff. It would take another decade for that unequal
treatment to be rectified. Even then, one year she received
a statement of benefits that explained what her wife would
receive upon her death. When Lorinda called HR to confirm that
they meant spouse, they said no, and demanded that the notice
be returned. (She declined.) It seemed that husbands would not
get equal treatment until AT&T lost a current court case. The
loss was a foregone conclusion; still AT&T preferred to pay
lawyers rather than widowers, and fought it to the bitter end.

Lorinda moved to my department in Computing Science when
the Unix operating system was in its infancy. Initially she
collaborated with Ken Knowlton on nascent graphics applications:
Beflix, a system for producing artistically pixillated films,
and an early program for rendering ball-and-stick molecular
models.

She then joined the (self-organized) Unix team, collaborating
on several applications with Bob Morris.

First came "dc", an unlimited-precision desk calculator,
which is still a Unix staple 45 years on. Building on dc,
she would later make "bc", which made unlimited precision
available in familiar programming-language notation and became
the interface of choice to dc.

Then came "form" and "fed", nominally a form-letter generator

and editor. In fact they were more of a personal memory
bank, a step towards Vannevar Bush's famous Memex concept--an
interesting try that didn't pay off at that scale. Memex had to
sleep two more decades before mutating into the Worldwide Web.

Lorinda had a hand in "typo", too, a Morris invention that
found gross spelling mistakes by statistical analysis. Sorting
the words of a document by the similarity of their trigrams
to those in the rest of the document tended to bring typos to
the front of the list. This worked remarkably well and gained
popularity as a spell-checker until a much less interesting
program backed by a big dictionary took over.

Taken together, these initial forays foretold a productive
computer science career centered around graphics, little
languages, and text processing.

By connecting a phototypesetter as an output device for Unix,
Joe Ossanna initiated a revolution in document preparation. The
new resource prompted a flurry of disparate looking documents
until Mike Lesk brought order to the chaos by creating a macro
package to produce a useful standard paper format.

Taking over from Lesk, Lorinda observed the difficulty of
typesetting the mathematics (which the printing industry counted
as "penalty copy") that occurred in many research papers,
and set out to simplify the task of rendering mathematical
formulas, Brian Kernighan soon joined her effort. The result
was "eqn", which built on the way people read formulas aloud
to make a quite intuitive language for describing display
formulas. Having pioneered a pattern that has been adopted
throughout the industry, eqn is still in use forty years later.

Lorinda also wrote an interpreter to render phototypesetter
copy on a cathode-ray terminal. This allowed one to see
typeset documents without the hassle of exposing and developing
film. Though everyone has similar technology at their fingertips
today, this was genuinely pioneering work at the time.

You are certainly aware of Writers Workbench, which gained
national publicity, including Lorinda's appearance on the Today
Show. It all began as a one-woman skunk-works project. Noticing
the very slow progress in natuaral-language processing, she
identified a useful subtask that could be carved out of the
larger problem: identifying parts of speech. Using a vocabulary
of function words (articles, pronouns, prepositions and
conjunctions) and rules of inflection, she was able to classify
parts of speech in running text with impressive accuracy.

When Rutgers professor William Vesterman proposed a
style-assessing program, with measures such as the frequencies
of adjectives, subordinate clauses, or compound sentences,
Lorinda was able to harness her "parts" program to implement
the idea in a couple of weeks. Subsequently Nina MacDonald,
with Lorinda's support, incorporated it into a larger suite
that checked and made suggestions about other stylistic issues
such as cliches, malapropisms, and redundancy.

Another aspect of text processing that Lorinda addressed was
topic identification. Terms (often word pairs) that occur with
abnormal frequency are likely to describe the topic at hand. She
used this idea to construct first drafts of indexes. One
in-house application was to the Unix manual, which up until
that time had only a table of contents, but no index. This
was a huge boon for a document so packed with detail.

In her final years at Bell Labs, Lorinda teamed up with AT&T
trouble-call centers to analyze the call transcripts that
attendants recorded on the fly--very sketchy prose, replete
with ad-hoc contractions and misspellings. The purpose was
to identify systemic problems that would not be obvious from
transcripts considered individually. When an unusual topic
appeared at the same time in multiple transcripts, those
transcripts were singled out for further study. The scheme
worked and led to early detection of system anomalies. In one
case, it led AT&T to suspend publication of a house organ that
rubbed customers the wrong way.

Lorinda was not cut from the same mold as most of her
colleagues. First she was a woman, which meant she faced
special obstacles. Then, while there were several pilots
among us, there was only one shower of dogs and only one car
racer--moreover one who became a regional exec of the Sports
Car Club of America. For years she organized and officiated
at races as well as participating.

Lorinda was always determined, but never pushy. The
determination shows in her success in text analysis, which
involves much sheer grit--there are no theoretical shortcuts
in this subject. She published little, but did a lot. I am
glad to see her honored.

Doug McIlroy

[TUHS] Lorinda Cherry

[John P. Linderman]

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

I got his from a friend today (15 February):

===========

I'm sorry to report that Lorinda passed away a few days ago.  I got a call
from her sister today.  Apparently the dog walker hadn't seen her for a few
days and called the police.  The police entered the house and found her
there.  Her sister says they are assuming either a heart attack or a stroke.

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

Re: [TUHS] Lorinda Cherry

[Dave Horsfall]

Sic transit gloria mundi...

This probably ought to go to COFF as well.

-- Dave

Re: [TUHS] Lorinda Cherry

[Jeffrey Joshua Rollin]

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

Sad news.

Jeff

Sent from my iPad

> On 15 Feb 2022, at 21:21, John P. Linderman <jpl.jpl@gmail.com> wrote:
> 
> 
> I got his from a friend today (15 February):
> 
> ===========
> 
> I'm sorry to report that Lorinda passed away a few days ago.  I got a call from her sister today.  Apparently the dog walker hadn't seen her for a few days and called the police.  The police entered the house and found her there.  Her sister says they are assuming either a heart attack or a stroke.

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