HP20b - Wolf (RPL calc) in Sheep's (RPN Calc) Clothing?

[Jeff O.]

Gene sent me a message in response to
my earlier post. He pointed out that the 20B is more of an RPL machine than an RPN machine. For example, press 2 INPUT 3 INPUT + and you get 5, not 6 as on every previous HP calculator with a 4-level RPN stack. You guys that seem to have some idea as to how to reprogram this thing need to get busy!

[Raymond Del Tondo]

Nothing against the Wolf, the HP-42S is a Wolf, too, at least internally,

since it has a full-blown, but taylored RPL kernel, with an RPN UI.

[Karl Schneider]

Hi, Raymond --

Quote:

---

...it has a full-blown, but taylored RPL kernel...

---

Ah, but that is the olde English spelling for the town clothes-cutter, whose German equivalent -- as someone formerly known as Hellstern knows -- is Schneider. The occupation and verb is "tailor" in the modern era.

Surnames based on occupations was a curious Anglo-Saxon custom. There certainly are a bunch of 'em in both languages.

-- KS

Edited: 20 July 2008, 12:24 a.m. after one or more responses were posted

[Walter B]

Quote:

---

Surnames based on occupations was certainly a curious Anglo-Saxon custom. There certainly are a bunch of 'em in both languages.

---

You find them also in Romance languages, not only in Germanic (and for sure not only in Anglo-Saxon). See e.g. the popular Portuguese surname Ferreira equalling Smith.

[bill platt]

I know a Ferreira who really is a smith!

[Paul Brogger]

From a relative in Germany (one L. Broëger or Brögger -- I don't remember exactly) I heard that my family name is somehow derived from "broco(u)r" -- a tap used in the serving of beer or wine from wooden casks. (The server who used said device came to be known as the brocour, or 'middle-man' -- and eventually, "broker".)

Edited: 21 July 2008, 2:40 p.m.

[Karl Schneider]

Hi again, Paul --

Quote:

---

From a relative in Germany (one L. Broëger or Brögger -- I don't remember exactly)

---

I am descended from a family named "Brugger" in the US.

"ë" does not exist in modern German (and perhaps also not in archaic German), so "Brögger" seems more likely. That would also be spelled as Broegger, which might be pronounced in North America as "brew-ger".

Thanks for the etymology!

-- KS

[George Bailey (Bedford Falls)]

Quote:

---

family named "Brugger"...

"ë" does not exist in modern German...

---

Brugger may come from the Belgian city of Brugge (Dutch spelling)...

"ë" does exist in modern German to distinguish between "oe" which would be pronounced like "ö" (o umlaut) and "o-e" (oë) which would be pronounced ow-eh.

Regards,
George

Edited: 22 July 2008, 10:01 a.m.

[Walter B]

Quote:

---

"ë" does exist in modern German to distinguish between "oe" which would be pronounced like "ö" (o umlaut) and "o-e" (oë) which would be pronounced ow-eh.

---

IMO you're both right: "ë" is very very rare in modern German, AFAIK it's only used in imported words, like e.g. the French car company Citroën. This is pronounced like "Sittro'ann" for US-American tongues. If the trema would be missing, people not knowing its French origin will pronounce it like "Zitrun" with a "u" like in murder.

Best regards from Germany :)

[Paul Brogger]

Thanks for all that.

This relative sent a scan of our family tree -- taken from a drawing on a page in the family bible. It went back to 1450 (the info looked a little sketchy back there), and showed a "Fritz" who had emigrated to America and had 8 children (he knew a few more details, but not much). That Fritz turned out to be my grandfather Frederick Joseph, and my father one of those eight.

I was able to fill in "Uncle Ludwig" on his U.S. relatives and he was very happy. I wish I could have met him -- his AOL account appears no longer active.

Thanks again!

[Richard J. Nelson]

Strange. When I press 3, ENTER, 2, ENTER, + on my RPN calculators you add the X and Y registers - which is 2 - I get 4. What am I missing? I can't speak for the 20b, but I have a few RPN calculators.

X < > Y,

Richard

[Richard J. Nelson]

Oops, I reversed the inputs and six is correct. The RPL "rules" are now being followed since Cyrille is an RPL person and not an RPN person. HP's machines are really messed up in this regard and it appears that the need for consistency is very low priority.

X < > Y,

Richard

[Karl Schneider]

Hi, Richard --

Quote:

---

The RPL "rules" are now being followed since Cyrille is an RPL person and not an RPN person. HP's machines are really messed up in this regard and it appears that the need for consistency is very low priority.

---

I had noticed several instances in which the RPN "way of doing things" on the HP-33s had changed to the RPL way on the HP-35s. Within a 7-page paper that I provided to Cyrille and Sam Kim at the San Diego 2007 HHC, I asked whether standardization of ROM code between the HP-35s and HP-50g was an objective.

• One of those HP-35s items of functionality was the method of entering integers in bases other than ten, which almost invariably requires the user to append a single-letter base code ("h", "d", "o", or "b") to a number in order to identify its base, regardless of the selected mode.

• The other item was the ability to enter a very long string of base-ten digits, which upon termination would then be rounded to a representable value (12 significant digits with mantissa magnitude less than 10.0 and exponent magnitude not greater than 499). RPN models including the HP-33s simply reject input of digits that would cause these limits to be violated.
  

I prefer the RPN way, especially where EXACT integer mode is not offered and where the input is almost always a number entered onto the stack -- not an 'object' entered into a buffer for subsequent processing.

-- KS

[Antonio Maschio (Italy)]

Ditto.

-- Antonio

[Walter B]

Hi Karl,

Quote:

---

I prefer the RPN way, especially where EXACT integer mode is not offered and where the input is almost always a number entered onto the stack -- not an 'object' entered into a buffer for subsequent processing.

---

So do I.

Quote:

---

Within a 7-page paper that I provided to Cyrille and Sam Kim at the San Diego 2007 HHC, I asked whether standardization of ROM code between the HP-35s and HP-50g was an objective.

---

What answer did you receive?

Regards, Walter

[Karl Schneider]

Hi, Walter --

Quote:

---

Within a 7-page paper that I provided to Cyrille and Sam Kim at the San Diego 2007 HHC, I asked whether standardization of ROM code between the HP-35s and HP-50g was an objective.

What answer did you receive?

---

I didn't request any answers or responses from HP at the time. My plan was to discuss the paper directly in a private session with legacy-model demonstrations -- it's convienient for me -- before distributing it to the community.

Unfortunately, I haven't yet followed up in 2008 to request this meeting. I should, because I do plan brief the paper at the upcoming HHC in Corvallis.

-- KS

[Gene Wright]

Jeff is correct. INPUT does not lift the stack.

I made sure to mention this in the (not yet published) 20b learning modules.

If you have your 20b already, give me an email. ;-)

Gene

[Paul Brogger]

I'm probably missing something obvious (and/or this has been discussed at length elsewhere), but why on the "true" RPN machines does ENTER lift the stack?

Seems to me that if it were just used to terminate numeric entry, and if any subsequent numeric key would lift the stack as part of the entry of a new value, the operation would be more straightforward, and much of confusion experienced by new/casual RPN users would have been avoided.

I suppose a second "lift stack" function (and another key to put it on) would have been required? (Alternatively, an ENTER keypress after any operation other than numeric entry might have effected a lift.)

I hear that H-P did exhaustive evaluation of such things, and probably everyone but me knows the answer(s) -- but I am curious.

[Karl Schneider]

Hi, Paul --

I'd say that the automatic 'DUP' function of ENTER on RPN calc's was to provide a concise two-keystroke sequence to double or square an input (also remember that x² was not provided on the HP-35).

Automatic 'DUP' saved a keystroke also when evaluating, e.g., xe^-x or sin(x)/x.

-- KS

[Gene Wright]

Just to clarify :-)

I am not collecting emails. But, I have a surprise for those who already have their HP 20b calculators.

[John B. Smitherman]

Thanks Jeff. Does the 20B display , or . to separate thousands places as you enter a number? Or, does it wait until you press Enter?

Regards,

John

[Jeff O.]

It inserts the thousands separator(s), and moves it (them) accordingly, as the number is entered.