21 Mar
2020
21 Mar
'20
1:11 a.m.
Moving to COFF ...
On Fri, Mar 20, 2020 at 1:24 PM Grant Taylor via TUHS <tuhs(a)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
21 Mar
21 Mar
1:31 a.m.
New subject: The most surprising Unix programs
Clem Cole <clemc(a)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
1:43 a.m.
New subject: The most surprising Unix programs
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
1:47 a.m.
New subject: The most surprising Unix programs
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
2:10 a.m.
New subject: The most surprising Unix programs
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(a)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(a)minnie.tuhs.org
https://minnie.tuhs.org/cgi-bin/mailman/listinfo/coff
2:37 a.m.
New subject: The most surprising Unix programs
On Fri, Mar 20, 2020 at 3:48 PM Grant Taylor via COFF <coff(a)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
2:30 a.m.
New subject: The most surprising Unix programs
Grant Taylor via COFF <coff(a)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
2:31 a.m.
New subject: The most surprising Unix programs
On Fri, Mar 20, 2020 at 3:43 PM Grant Taylor via COFF <coff(a)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.
4:51 a.m.
New subject: The most surprising Unix programs
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
1737
days inactive
1737
days old
8 comments
5 participants
participants (5)
-
Clem Cole -
Dave Horsfall -
Grant Taylor -
Terry Jones -
Tom Ivar Helbekkmo