stack lift and change sign

[Gerson W. Barbosa]

(08-29-2014 04:11 PM)walter b Wrote:  

(08-29-2014 03:56 PM)Mark Hardman Wrote:  heaven would indeed be a very, very crowded place.

Oh, isn't it? Where else do all those good people go?

BTW, with mankind growing exponentially there are as many people dead as alive.

d:-)

You good people here, don't forget to bring along your favorite RPN/RPL calculator :-)

[Thomas Klemm]

(08-29-2014 05:16 PM)Mark Hardman Wrote:  See: Heat death of the universe

Which reminds me of "The Last Question" by Isaac Asimov.

[walter b]

(08-29-2014 05:16 PM)Mark Hardman Wrote:  I don't think the future is bright for any of us.

You may be right for any of us. In the long range, we'll all be dead for sure. In the longer range, future is pretty bright with the earth swallowed by an expanding sun (don't be afraid, it will take several 10^9 years until that's going to happen). Mankind will have vanished eons before, and even ants will be extinct. And in the longest range, there will be big freeze - no more stars shining, everything what could collapse, collapsed, and the universe will be large and dark and cold. But don't bother - see above.

d:-)

[walter b]

(08-29-2014 03:56 PM)Mark Hardman Wrote:  καὶ εἶπεν• ἀμὴν λέγω ὑμῖν, ἐὰν μὴ στραφῆτε καὶ γένησθε ὡς τὰ παιδία, οὐ μὴ εἰσέλθητε εἰς τὴν βασιλείαν τῶν οὐρανῶν.

There it went, another "lingua franca" of its time.

Quote:παιδία in this verse would mean "young child" or "child below the age of puberty".

Minor nitpicky remark: τὰ παιδία in this verse means "young children", a single young child would be τὸ παιδίον.

d:-)

[Mark Hardman]

(08-29-2014 08:21 PM)walter b Wrote:  Minor nitpicky remark: τὰ παιδία in this verse means "young children", a single young child would be τὸ παιδίον.

d:-)

Erk! My Biblical Greek Professor, Dr. Griggs, would hang his head in shame.

Nominative, Neuter, Plural.

I shall do penitence by reviewing noun paradigms for all three declensions for six hours this weekend.

[walter b]

(08-29-2014 01:00 PM)ElectroDuende Wrote:  Just wanted to increase the test spectrum...

Watch it! You were running a high risk (see post #3). For sake of logical consistency there was an interference to be expected.

d:-/

BTW, if you'd use <Quote> for responding, your replies would be filed correctly. Please see here for more information.

[walter b]

(08-29-2014 04:11 PM)walter b Wrote:  

(08-29-2014 03:56 PM)Mark Hardman Wrote:  heaven would indeed be a very, very crowded place.

Oh, isn't it? Where else do all those good people go?

Ouch, I almost forgot about their doggies (see here) - so expect it even more crowded (hope for good scavengery).

d:-/

[Paul Dale]

(08-29-2014 12:55 PM)walter b Wrote:  Hmmmh, what would be the benefit over classic RPN?

Quite a bit. It is more consistent to not have stack lift.

Type in a value and press ENTER. The value goes into X, the stack lifts one position. This is the same behaviour as e.g. PI. You don't use two stack levels for entering one number, you don't risk things like 3 ENTER 4 ENTER + (which was asked about recently from memory).

Clx drops the stack one level, rather than putting zero into X and disabling lift. It needs a rename but there is no odd behaviour anymore.

Sigma+ and Sigma- play stack games too. Consistent is for them to consume two levels and to rely on an UNDO command to fix a mistake.

% is another one. Yes, leaving the value in Y is handy if followed by + or - but confusing and inconsistent.


Basically, you are getting rid of quite an oddity (stack lift) and doing everything in a consistent and sensible manner. The oddity was due to early device not having enough memory. I'm sure HP wouldn't have had stack lift if the HP 35 had had a couple of extra registers in the CPU.


How many times have we had questions for new members that came down to stack lift issues? I can remember several, I also remember getting confused after coming back to RPN from RPL by this exact issue.


- Pauli

[RMollov]

(08-31-2014 07:25 AM)Paul Dale Wrote:  How many times have we had questions for new members that came down to stack lift issues? I can remember several, I also remember getting confused after coming back to RPN from RPL by this exact issue.


- Pauli

Correct. I remember the times I was getting familliar with the HP41. Stack lift looked somewhat weird but I suspected it was for a reason - saving memory and some keystrokes. RPL proved we could live without it.

[walter b]

Hmmh, got grandchildren here thus lacking calc test time - but don't see any significant advantages in "stack lift" behavior by your descriptions yet. Will have to compare later.

d:-/

[walter b]

Read the first 30 pages of Wickes' "41-48 transitions" who basically states that the HP-48 just extends the way the HP-41 calculates, allowing also objects which aren't just plain real numbers. Still don't get why there's such a bohai about "stack lift" - to me the stack maneuvers of the 48 aren't any better, just different.

Let's look how e.g. (1+2)*(4+5) is calculated on an HP-48 as on an HP-42:

1 ENTER 2 + 3 ENTER 4 + *

Code:


HP-48:  Entry line:  1:    2:        HP-42S: X:    Y:    Z:          
1                1                           1                         
ENTER                1                       1      1                  
2                2   1                       2      1                   
+                    3                       3                          
4                4   3                       4      3                 
ENTER                4     3                 4      4      3         
5                5   4     3                 5      4      3         
+                    9     3                 9      3                  
*                   27                      27

On the 42S, ENTER always duplicates - on the 48, ENTER only duplicates if the entry line is empty. Personally, I prefer a function doing the same always (remember you've no chance to follow that weird behavior of ENTER on a single line display).

d:-/

[Paul Dale]

(08-31-2014 08:50 PM)walter b Wrote:  On the 42S, ENTER always duplicates - on the 48, ENTER only duplicates if the entry line is empty. Personally, I prefer a function doing the same always (remember you've no chance to follow that weird behavior of ENTER on a single line display).

ENTER isn't a great example of the problems, subject to stack size, both entry systems behave similarily. However, ENTER on a classic RPN putting the new value in X and Y is inconsistent. That doesn't make sense and is truly weird on a single line display (or even a two line display).

What about Clx, Sigma+, Sigma-? They all disable stack lift. They introduce an inconsistency which simply wouldn't occur without the stack lift kludge.

CHS sometimes sets lift and sometimes doesn't. This is essentially the same as ENTER duplicating or committing a command line -- so a lift less device has the same problem twice whereas a classic RPN has two different ones.


Just because we've always done it one way doesn't make that way right or even good.


Pauli

[walter b]

(08-31-2014 09:52 PM)Paul Dale Wrote:  

(08-31-2014 08:50 PM)walter b Wrote:  On the 42S, ENTER always duplicates - on the 48, ENTER only duplicates if the entry line is empty. Personally, I prefer a function doing the same always (remember you've no chance to follow that weird behavior of ENTER on a single line display).

ENTER isn't a great example of the problems, ...

Quote:ENTER on a classic RPN putting the new value in X and Y is inconsistent. That doesn't make sense and is truly weird ...

Why?

Quote:What about Clx, Sigma+, Sigma-? They all disable stack lift. They introduce an inconsistency which simply wouldn't occur without the stack lift kludge.

CHS sometimes sets lift and sometimes doesn't.

Seems there is some explanation necessary for the younger generation: Way back before scientific pocket calculators were available (unbelievable though there was such a time), scientists and engineers and students (you know which) had real calculating problems e.g. doing experiments and repeated measurements and the like. Thus, already the HP-45 featured a very (!) useful key labeled Σ+. It was the key every experimentalist was waiting for. It solved that problem once and forever and in a reasonable way - with Σ- inverting it. Nowadays, maybe it would be marketed "calling the Σ-App" but then nobody knew about apps but was happy with a working solution. And since the solution worked it was kept this way until today. So much about Σ+ and Σ- and why they work as they do IMHO. Of course, more complex solutions were and are always makeable, too, but why should one?

CLx and CHS may be covered later.

d:-)

[Paul Dale]

(09-01-2014 10:36 AM)walter b Wrote:  Thus, already the HP-45 featured a very (!) useful key labeled Σ+. It was the key every experimentalist was waiting for. It solved that problem once and forever and in a reasonable way - with Σ- inverting it.

I'm not disputing the benefits of Σ+, it was quite amazing in its time, although maintaining all the data individually is a significant step forward on the RPL devices.

I really just disagreeing with it's stack behaviour:

Code:

Y X Σ+ -> Y n
          with stack lift disabled

is kind of weird. Surely, better is:

Code:

Y X Σ+ -> ∅

which is a consistent improvement. UNDO or LAST returning the two argument to the stack for the Σ- error correction is better than playing stack games. If the display of n is important, make it a temporary on the screen but don't put it on the stack.


- Pauli

[walter b]

Now I see what bothers you - the curse of multiline displays! I'm confident we'll find a solution for that.

d:-)

[Thomas Klemm]

Quote:Interesting find! (Although I'm sure that it's been found before...)

Posted by Karl Schneider in CHS and Stack Lift.