[COFF] [TUHS] The most surprising Unix programs

[COFF] [TUHS] The most surprising Unix programs

[clemc]

Moving to COFF ....

On Tue, Mar 17, 2020 at 10:58 AM Larry McVoy <lm at mcvoy.com> wrote:

> As much as I don't care for Forth, man do I wish it had become the standard
> for boot proms, it might not be my cup of tea but I could make it do what
> I needed it to do.

Amen bro...  Sun did a nice job on that.   Although the Alpha Boot ROMs
were pretty good too. At least they were UNIX like and were extensible like
the Sun boot ROMs.   HP's were better than a PC BIOS, but they were pretty
awful.




> Can't say the same for UEFI, I disable that crap.
>
Well, it beats the crap out of IBM's BIOS, but that bar is very low.    UEFI
was sort of a 'camel' (a horse designed by committee) and too many people
peed on it.  Intel created EFI to try to fix BIOS and then people went
nuts.   Apple's version is the best of them, but as you say, they all suck
if you have seen anything better.  A big problem IMO is that EFI tried to
be somewhat compatible.  In the end, they were not, so you got the worst of
both (new interfaces and legacy functionality).

Server systems that support IPMT have Minux under the covers in
coprocessor, which using a coprocessor is also how Apple runs UEFI.  With
IMPT, it is sort of sad more of it is not really exposed, but you need the
added cost of the coprocessor.    Plus it adds a new security domain, which
many people complain about.   I try to know as little about it as possible
to get my work done, but exposing more of that interface might help.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/coff/attachments/20200317/5eba0a4e/attachment.html>

[COFF] [TUHS] The most surprising Unix programs

[dave]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 894 bytes --]

On Tue, 17 Mar 2020, Clem Cole wrote:

> > Can't say the same for UEFI, I disable that crap.
> 
> Well, it beats the crap out of IBM's BIOS, but that bar is very low.  
>   UEFI was sort of a 'camel' (a horse designed by committee) and too 
> many people peed on it.  Intel created EFI to try to fix BIOS and then 
> people went nuts.   Apple's version is the best of them, but as you say, 
> they all suck if you have seen anything better.  A big problem IMO is 
> that EFI tried to be somewhat compatible.  In the end, they were not, so 
> you got the worst of both (new interfaces and legacy functionality).

The first time I blundered into UEFI was when I tried to boot FreeBSD on a 
newish PC, and of course it was not an authorised CD, was it?  Or 
something like that; anyway, I'm a great believer in allowing idiots to 
shoot themselves in the foot if they so desire.

-- Dave

[COFF] [TUHS] The most surprising Unix programs

[dave]

On Thu, 19 Mar 2020, Mike Markowski wrote:

>> I've been using my trusty HP-42S for so long that I can hardly remember 
>> how to use a "normal" calculator :-)
>
> When my classmate's calculator died during an engineering exam, he asked 
> if he could borrow my spare.  I handed him my HP 32s and after a minute 
> he whispered, "Where's the equals key?"  He gave my calculator back. 
> :-)

I did that to a financial controller in a previous life; she was not 
amused...  Hey, it was the only calculator that I had!  I could see her 
helplessly looking for the "=" key, then I took pity on her.

-- Dave

[COFF] [TUHS] The most surprising Unix programs

[cym224]

On 03/19/20 17:31, Dave Horsfall wrote:
> On Thu, 19 Mar 2020, Mike Markowski wrote:
>>> I've been using my trusty HP-42S for so long that I can hardly 
>>> remember how to use a "normal" calculator :-)
>> When my classmate's calculator died during an engineering exam, he 
>> asked if he could borrow my spare.  I handed him my HP 32s and after 
>> a minute he whispered, "Where's the equals key?"  He gave my 
>> calculator back. :-)
> I did that to a financial controller in a previous life; she was not 
> amused...  Hey, it was the only calculator that I had!  I could see 
> her helplessly looking for the "=" key, then I took pity on her.

Hhmm, back in my early days, the 12C was highly coveted by financial 
types.  Our mileage differed.

By the way, HP will sell you an Android app'n that looks just like their 
venerable (and much missed) calculators.

N.
>
> -- Dave
> _______________________________________________
> COFF mailing list
> COFF at minnie.tuhs.org
> https://minnie.tuhs.org/cgi-bin/mailman/listinfo/coff

[COFF] [TUHS] The most surprising Unix programs

[stewart]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1324 bytes --]



> On Mar 19, 2020, at 5:39 PM, Nemo Nusquam <cym224 at gmail.com> wrote:
> 
> On 03/19/20 17:31, Dave Horsfall wrote:
>> On Thu, 19 Mar 2020, Mike Markowski wrote:
>>>> I've been using my trusty HP-42S for so long that I can hardly remember how to use a "normal" calculator :-)
>>> When my classmate's calculator died during an engineering exam, he asked if he could borrow my spare.  I handed him my HP 32s and after a minute he whispered, "Where's the equals key?"  He gave my calculator back. :-)
>> I did that to a financial controller in a previous life; she was not amused...  Hey, it was the only calculator that I had!  I could see her helplessly looking for the "=" key, then I took pity on her.
> 
> Hhmm, back in my early days, the 12C was highly coveted by financial types.  Our mileage differed.
> 
> By the way, HP will sell you an Android app'n that looks just like their venerable (and much missed) calculators.
> 
> N.
>> 
>> -- Dave
>> _______________________________________________
>> COFF mailing list
>> COFF at minnie.tuhs.org
>> https://minnie.tuhs.org/cgi-bin/mailman/listinfo/coff
> 
> _______________________________________________
> COFF mailing list
> COFF at minnie.tuhs.org
> https://minnie.tuhs.org/cgi-bin/mailman/listinfo/coff

The HP calculator apps run the original microcode...

[COFF] [TUHS] The most surprising Unix programs

[dave]

On Thu, 19 Mar 2020, Nemo Nusquam wrote:

> Hhmm, back in my early days, the 12C was highly coveted by financial 
> types. Our mileage differed.

I've never seen one (but I've heard of them).  Hmmm...  The blue "g" key 
rings a bell from somewhere.

> By the way, HP will sell you an Android app'n that looks just like their 
> venerable (and much missed) calculators.

Sell?  I downloaded "Free42" for the Mac for free :-)

-- Dave

[COFF] [TUHS] The most surprising Unix programs

[lm]

On Sat, Mar 21, 2020 at 01:49:27PM +1100, Dave Horsfall wrote:
> On Thu, 19 Mar 2020, Nemo Nusquam wrote:
> 
> >Hhmm, back in my early days, the 12C was highly coveted by financial
> >types. Our mileage differed.
> 
> I've never seen one (but I've heard of them).  Hmmm...  The blue "g" key
> rings a bell from somewhere.
> 
> >By the way, HP will sell you an Android app'n that looks just like their
> >venerable (and much missed) calculators.
> 
> Sell?  I downloaded "Free42" for the Mac for free :-)

An app will never give you that feelng of touching quality when you
pushed the keys.  Those were really well made tools.  I'm a tool guy,
I've got a full on wood working shop (with a ton of old and new hand
planes, the new guys are making some good stuff), pretty decent metal
working, Logan lathe, stick, mig, plasma, and a full on mechanic shop,
up to 3/4" impacts, I do tractors and big trucks.

I love tools and an app is not a replacement for putting your fingers
on an old HP calc.

[COFF] HP calculator emulators (was: The most surprising Unix programs)

[grog]

On Saturday, 21 March 2020 at 13:49:27 +1100, Dave Horsfall wrote:
> On Thu, 19 Mar 2020, Nemo Nusquam wrote:
>> By the way, HP will sell you an Android app'n that looks just like their
>> venerable (and much missed) calculators.
>
> Sell?  I downloaded "Free42" for the Mac for free :-)

In fact, there are a surprising number.  I've downloaded free42, 48sx
hp67 calculator.  All would do what I need, but I found that 48sx has
the prettiest interface.  It almost looks better than the original.

Greg
--
Sent from my desktop computer.
Finger grog at lemis.com for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/coff/attachments/20200321/c3bfd3d4/attachment.sig>

[COFF] The most surprising Unix programs

[tih]

Dave Horsfall <dave at horsfall.org> writes:

> Sell?  I downloaded "Free42" for the Mac for free :-)

Free42 works great on lots of platforms, including Android - and it also
powers the HP-42S clone from these guys: https://www.swissmicros.com/

-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

[COFF] The most surprising Unix programs

[mparson]

On Sat, 21 Mar 2020, Tom Ivar Helbekkmo via COFF wrote:
> Dave Horsfall <dave at horsfall.org> writes:
>
>> Sell?  I downloaded "Free42" for the Mac for free :-)
>
> Free42 works great on lots of platforms, including Android - and it also
> powers the HP-42S clone from these guys: https://www.swissmicros.com/

I have 'go48g' on my android, mostly for nostalgia, I've forgotten how
to use most of the features of it. The 48gx was my first HP calc long
ago, still have it, though it is currently in pieces as I am (slowly)
attempting to perform some repairs on it.

My go-to calculator on my (android) phone is simply called 'RPN
Calculator' and I use 'dc' when logged into *nix.

I made fun of friends that used HP calculators for a long time, until
I started using it.  Once I wrapped my head around RPN, it just felt
"better."  But, like text editors, keyboard layouts, etc... to each
his/her own, use what you know and can get work done with.

-- 
Michael Parson
Pflugerville, TX
KF5LGQ

[COFF] [TUHS] The most surprising Unix programs

[gtaylor]

Aside:  I'm sending this reply to TUHS where the message that I'm 
replying to came from.  But i suspect that it should migrate to COFF, 
which I'm CCing.

On 3/20/20 5:48 AM, paul at guertin.net wrote:
> I teach math in college, and I use an RPN calculator as well (it's 
> just easier).

Would you please elaborate on "it's just easier"?

I'm asking from a point of genuine curiosity.  I've heard many say that 
RPN is easier, or that it takes fewer keys, or otherwise superior to 
infix notation.  But many of the conversations end up somewhat devolving 
into religious like comments about preferences, despite starting with 
honest open-minded intentions.  (I hope this one doesn't similarly devolve.)

I've heard that there are fewer keys to press for RPN, but the example 
equations presented have been effectively he same.

I've heard that RPN is mentally easier.  But I apparently don't know 
enough RPN to be able to think in RPN natively to evaluate myself.

I dabble with RPN, including keeping my main calculator app on my smart 
phone in RPN mode.

So I am genuinely interested in understanding why you say that RPN is 
just easier.

> Sometimes, during an exam, a student who forgot to bring their 
> calculator will ask if they can borrow mine. I always say "sure, but 
> you'll regret it" and hand them the calculator. After wasting one or 
> two minutes, they give it back.

~chuckle~

> (Note that I always make sure no calculator is needed for my exams, 
> but it's department policy to authorise non programmable calculators, 
> and it seems to reassure students to have the calculator on the desk, 
> so I don't mind.) >

ACK



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4013 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/coff/attachments/20200320/732f1cdc/attachment.bin>

[COFF] [TUHS] The most surprising Unix programs

[clemc]

Moving to COFF ...

On Fri, Mar 20, 2020 at 1:24 PM Grant Taylor via TUHS <tuhs at minnie.tuhs.org>
wrote:

> Would you humor me with an example of what you mean by "thinking on the
> fly"?  Either I'm not understanding you or we think differently.
>

I'll take a stab at it in a minute.

But first, I never cared either way.  In college, I had an SR50 and my GF
had an HP45.   I would say, between my EE friends we were probably split
50/50 between TI and HP.  Generally, it was the RPN centric crew were
fiercely loyal as in the editor wars but would grab whichever was near me
when we all were working a problem set; but I knew a couple of folks that
hated RPN too.

It's possible, because of my undiagnosed dyslexia at the time, but I would
grab the closest calculator, pause to see which is was and then start
entering things as needed.  But like Jon -- if I had the TI in my hands, I
found myself copying the equation.   I was trying to pay attention to what
button I was pressing to check for any keystroke entry errors.   Both types
had all of the same math functions so there was little difference in the
number of strokes, other than not needing parentheses on HP and how you
entered the calculation.   With the HP, I was more aware of that equation I
was calculating because I was having to make sure I entered it in the
proper order so I could get the right answer.   In my case, I was probably
a tad more careful because I was being forced to thinking in terms of
precedence - but I was thinking about the equation.  Whereas with the TI I
was just hitting the button per the equation on the paper.   I typed a tad
faster on the TI than the HP because I was not thinking as much but ... I
probably made more typing errors there because I thought less about what I
was doing.

Clem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/coff/attachments/20200320/b8cbbba6/attachment-0001.html>

[COFF] The most surprising Unix programs

[tih]

Clem Cole <clemc at ccc.com> writes:

> In my case, I was probably a tad more careful because I was being
> forced to thinking in terms of precedence - but I was thinking about
> the equation.  Whereas with the TI I was just hitting the button per
> the equation on the paper.  I typed a tad faster on the TI than the HP
> because I was not thinking as much but ... I probably made more typing
> errors there because I thought less about what I was doing.

That sounds like a good summary.  I started out on TI programmable
calculators (my first was a TI-57 that I still have, and that still
works), but moved on to RPN with an HP41CV.  Today, I find entering
calculations into an RPN calculator simpler, because I naturally think
in terms of the stack.  With a traditional calculator, I have to look at
the (possibly just mentally imaged) formula that I need to evaluate, and
type it in character by character, whereas the RPN calculator lets me
think about the calculation to be performed, and just enter that.

-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

[COFF] The most surprising Unix programs

[gtaylor]

On 3/20/20 1:31 PM, Tom Ivar Helbekkmo via COFF wrote:
> That sounds like a good summary.  I started out on TI programmable 
> calculators (my first was a TI-57 that I still have, and that still 
> works), but moved on to RPN with an HP41CV.  Today, I find entering 
> calculations into an RPN calculator simpler, because I naturally
> think in terms of the stack.  With a traditional calculator, I have
> to look at the (possibly just mentally imaged) formula that I need to
> evaluate, and type it in character by character, whereas the RPN
> calculator lets me think about the calculation to be performed, and
> just enter that.

Thank you for the comments gentlemen.

What I think I'm hearing you say is that with RPN you were shouldering 
part of the computational load based on how you were entering things so 
that they aligned as necessary with the stack.  Conversely, you were 
simply "plug and chug" (as I've heard elsewhere).  Meaning you entered 
the equation / formula and were largely hands off from the calculation.

Is that accurate?



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4013 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/coff/attachments/20200320/16b42f14/attachment.bin>

[COFF] The most surprising Unix programs

[gtaylor]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1170 bytes --]

On 3/20/20 1:43 PM, Grant Taylor via COFF wrote:
> What I think I'm hearing you say is that with RPN you were shouldering 
> part of the computational load based on how you were entering things so 
> that they aligned as necessary with the stack.  Conversely, you were 
> simply "plug and chug" (as I've heard elsewhere).  Meaning you entered 
> the equation / formula and were largely hands off from the calculation.

I can see how this could be translated to RPN could cause someone to 
feel like they have a better understanding of what's being calculated. 
Conversely, infix notation leaving someone feeling separated from the 
calculation and having much less of an understanding of what's being 
calculated.

This separation making it more likely that people will have problems 
estimating and having any idea if what they're doing makes any sense or not.



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4013 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/coff/attachments/20200320/13026aab/attachment.bin>

[COFF] The most surprising Unix programs

[terry]

I also love RPN, dc, & the HP calculators. I wrote an RPN calculator in
Python recently (I call it via a shell alias called pc). It imports much of
the math, operator, and builtins modules, so you can use it just like dc,
but with much more stuff available:

$ pc 200 pi \* log10 sqrt
1.6727760963016285

You can push arbitrary Python objects and functions onto the stack. Install
with pip install rpnpy  Source at https://github.com/terrycojones/rpnpy

Terry


On Fri, Mar 20, 2020 at 8:48 PM Grant Taylor via COFF <coff at minnie.tuhs.org>
wrote:

> On 3/20/20 1:43 PM, Grant Taylor via COFF wrote:
> > What I think I'm hearing you say is that with RPN you were shouldering
> > part of the computational load based on how you were entering things so
> > that they aligned as necessary with the stack.  Conversely, you were
> > simply "plug and chug" (as I've heard elsewhere).  Meaning you entered
> > the equation / formula and were largely hands off from the calculation.
>
> I can see how this could be translated to RPN could cause someone to
> feel like they have a better understanding of what's being calculated.
> Conversely, infix notation leaving someone feeling separated from the
> calculation and having much less of an understanding of what's being
> calculated.
>
> This separation making it more likely that people will have problems
> estimating and having any idea if what they're doing makes any sense or
> not.
>
>
>
> --
> Grant. . . .
> unix || die
>
> _______________________________________________
> COFF mailing list
> COFF at minnie.tuhs.org
> https://minnie.tuhs.org/cgi-bin/mailman/listinfo/coff
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/coff/attachments/20200320/a86c78ee/attachment-0001.html>

[COFF] The most surprising Unix programs

[clemc]

On Fri, Mar 20, 2020 at 3:48 PM Grant Taylor via COFF <coff at minnie.tuhs.org>
wrote:

> I can see how this could be translated to RPN could cause someone to
> feel like they have a better understanding of what's being calculated.
> Conversely, infix notation leaving someone feeling separated from the
> calculation and having much less of an understanding of what's being
> calculated.
>
Maybe.  I never really saw it that way, but I can see how someone might
think that.   If you ever watched a skilled account with an adding machine
such as in the old days in an H&R Block tax office -- you will notice they
move off their eyes from the paper.  Their hands are just typing away,
entering digits and hitting the add/subtract/equal keys and they never look
at the machine until the end.  It can almost be mesmerizing.   I could be
similar that on a TI calculator, but I never could on an HP.



> This separation making it more likely that people will have problems
> estimating and having any idea if what they're doing makes any sense or
> not.
>
For some people, that probably is true.  But I'm not sure it generalizes.

Clem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/coff/attachments/20200320/83230fa4/attachment.html>

[COFF] The most surprising Unix programs

[tih]

Grant Taylor via COFF <coff at minnie.tuhs.org> writes:

> Is that accurate?

Yeah, your summary sounds about right.

-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

[COFF] The most surprising Unix programs

[clemc]

On Fri, Mar 20, 2020 at 3:43 PM Grant Taylor via COFF <coff at minnie.tuhs.org>
wrote:

> Thank you for the comments gentlemen.
>
Most welcome.

>
> What I think I'm hearing you say is that with RPN you were shouldering
> part of the computational load based on how you were entering things so
> that they aligned as necessary with the stack.  Conversely, you were
> simply "plug and chug" (as I've heard elsewhere).  Meaning you entered
> the equation / formula and were largely hands off from the calculation.
>
> Is that accurate?
>
Fair enough.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/coff/attachments/20200320/498a82ab/attachment.html>

[COFF] The most surprising Unix programs

[dave]

On Fri, 20 Mar 2020, Grant Taylor via COFF wrote:

> What I think I'm hearing you say is that with RPN you were shouldering 
> part of the computational load based on how you were entering things so 
> that they aligned as necessary with the stack.  Conversely, you were 
> simply "plug and chug" (as I've heard elsewhere).  Meaning you entered 
> the equation / formula and were largely hands off from the calculation.
>
> Is that accurate?

You may need parentheses, which not all algebraic calculators have (and 
the ones that do have limited nesting).

Ironic really; either you have to do what RPN users do i.e. work "inside 
out" if you have a small stack or the calculator has to implement one :-)

-- Dave

[COFF] [TUHS] The most surprising Unix programs

[gtaylor]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3929 bytes --]

+COFF

On 3/20/20 8:03 AM, Noel Chiappa wrote:
> Maybe I'm being clueless/over-asking, but to me it's appalling that 
> any college student (at least all who have _any_ math requirement at 
> all; not sure how many that is) doesn't know how an RPN calculator 
> works.

I'm sure that there are some people, maybe not the corpus you mention, 
that have zero clue how an RPN calculator works.  But I would expect 
anybody with a little gumption to be able to poke a few buttons and 
probably figure out the basic operation, or, ask if they are genuinely 
confused.

> It's not exactly rocket science, and any reasonably intelligent 
> high-schooler should get it extremely quickly; just tell them it's 
> just a representational thing, number number operator instead of 
> number operator number.

I agree that RPN is not rocket science.  And for basic single operation 
equations, I think that it's largely interchangeable with infix notation.

However, my experience is, as the number of operations goes up, RPN can 
become more difficult to use.  This is likely a mental shortcoming on my 
part.  But it is something that does take tractable mental effort for me 
to do.

For example, let's start with Pythagorean Theorem

    a² + b² = c²

This is relatively easy to enter in infix notation on a typical 
scientific calculator.

However, I have to stop and think about how to enter this on an RPN 
calculator.  I'll take a swing at this, but I might get it wrong, and I 
don't have anything handy to test at the moment.

[a] [enter]
[a] [enter]
[multiply]
[b] [enter]
[b] [enter]
[multiply]
[add]
[square root]   # to solve for c

(12 keys)

Conversely infix notation for comparison.

[a]
[square]
[plus]
[b]
[square]
[square root]

(6 keys)

As I type this, I realize that I'm using higher order operations 
(square) in infix than I am in RPN.  But that probably speaks to my 
ignorance of RPN.

I also realize that this equation does a poor job at demonstrating what 
I'm trying to convey.  —  Or perhaps what I'm trying to convey is 
incorrect.  —  I had to arrange sub-different parts of the equation so 
that their results ended up together on the stack for them to be the 
targets of the operation.  I believe this (re)arrangement of the 
equation is where most of my mental load / objection comes from with 
RPN.  I feel like I have to process the equation before I can tell the 
calculator to compute the result for me.  I don't feel like I have this 
burden with infix notation.

Aside:  I firmly believe that computers are supposed to do our bidding, 
not the other way around.    s/computers/calculators/

> I know it's not a key intellectual skill, but it does seem to me to 
> be part of comon intellectual heritage that everyone should know, 
> like musical scales or poetry rhyming. Have you ever considered 
> taking two minutes (literally!) to cover it briefly, just 'someone 
> tried to borrow my RPN calculator, here's the basic idea of how they 
> work'?

I'm confident that 80% of people, more of the corpus you describe, could 
use an RPN calculator to do simple equations.  But I would not be 
surprised if many found that the re-arrangement of equations to being 
RPN friendly would simply forego the RPN calculator for simpler 
arithmetic operations.

I think some of it is a mental question:  Which has more mental load, 
doing the annoying arithmetic or re-arranging to use RPN.

I believe that for the simpler of the arithmetic operations, RPN is 
going to be more difficult.

All of this being said, I'd love to have someone lay out points and / or 
counterpoints to my understanding.



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4013 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/coff/attachments/20200320/6c9c556f/attachment.bin>

[COFF] [TUHS] The most surprising Unix programs

[mike.ab3ap]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1247 bytes --]

Hi Grant,

On 3/20/20 12:07 PM, Grant Taylor via COFF wrote:
> [a] [enter]
> [a] [enter]
> [multiply]
> [b] [enter]
> [b] [enter]
> [multiply]
> [add]
> [square root]   # to solve for c
> 
> (12 keys)

On an HP calc, it'd actually be:

   [a] [square] [b] [square] [add] [sqrt]

but no win over infix.  A noticeable win is that RPN uses no 
parentheses.  Consider (1+2)*3 / ((4-5)/6)) + log(7/8).

RPN: 1 2 + 3 * 4 5 - 6 / / 7 8 / log : 15 keystrokes

Alg: counting chars above is 25 keystrokes, 26 with a final '='.

I'm not so sure that minimized keystrokes are the real win, in any case. 
  Using RPN trains me to quickly see the equation in its decomposed 
parts.  In the end, it's really about what fits best in your head.  The 
world seems to have spoken that infix is preferred - even if RPN users 
think they know better!  :-)

I worked with a now-retired engineer who believed everyone should learn 
first on a slide rule and that there is no better tool for learning sig 
figs and ballparking answers.  He would lecture about it whenever 
someone put the decimal point in the wrong place and didn't realize it. 
As a result, next to my old calculators...yup, a few slide rules!

Mike Markowski - correct order for Polish operator :-)

[COFF] [TUHS] The most surprising Unix programs

[dave]

On Fri, 20 Mar 2020, Grant Taylor via COFF wrote:

> However, I have to stop and think about how to enter this on an RPN 
> calculator.  I'll take a swing at this, but I might get it wrong, and I 
> don't have anything handy to test at the moment.
>
> [a] [enter]
> [a] [enter]
> [multiply]
> [b] [enter]
> [b] [enter]
> [multiply]
> [add]
> [square root]   # to solve for c

[a] [square] [enter] [b] [square] [+] [sqrt] (You don't need those extra 
"enter" keys, as the display is implicitly the top of the stack.)

> (12 keys)

7.  Well, "square" also needs the orange "shift" key, so that's really 9, 
but the number of keystrokes ain't exactly the point; it's not a race, but 
a method of thinking.

> Conversely infix notation for comparison.
>
> [a]
> [square]
> [plus]
> [b]
> [square]
> [square root]
>
> (6 keys)

[...]

Well, it really comes down to the calculation that you are trying to 
perform.  Trivial example:

1 + 1 = -> 4 keys.
1 enter 1 add -> 4 keys.

I don't have an algebraic calculator right to hand, but I'd imagine that 
solving a second-order polynomial (without a built-in program!) would 
involve fewer keys when using RPN because of the stack for intermediate 
results; a quick estimate is around 30 keys (with single-digit numbers) to 
get one of the roots, and you could probably save the result of most of it 
on the stack for re-use to get the other root (and the 42S groks complex 
numbers as a bonus[*], but that's hardly as a result of RPN).  The 42S 
also has a handy "swap x/y" if the operands are the wrong way around, 
another one to rotate the stack, etc.

You don't do Computer Science without being exposed to RPN, and I had to 
wait for a salary-in-lieu payout (long story) before I could afford the 
42S that I'd been drooling over (and forget the overpriced IR printer[#]).

[*]
1 +/- SQRT => "0.00 i1.00" (I have the display precision set to 2 because 
I use it for monetary stuff a lot; the internal precision is 15 digits).

[#]
A dream of mine is to reverse-engineer the printer protocol, then grab it 
using a laptop camera.

Here endeth today's HP-42S lesson...

-- Dave

[COFF] [TUHS] The most surprising Unix programs

[paul]

Dixit Dave Horsfall (2020-03-20 11:53 p.m.):
> A dream of mine is to reverse-engineer the printer protocol, then grab it
> using a laptop camera.

You might find this interesting:

http://www.mh-aerotools.de/hp/red-eye/HP-IR%20Receiver%20with%20Arduino.pdf

Paul Guertin