[34S] Proposal for Entry RPN mode with dynamic stack

[Marcus von Cube]

(02-15-2015 11:38 PM)Bit Wrote:  Walter would know the reason, perhaps there's some contractual obligation with the publisher.

To my knowledge it's solely Walter's decision and it's the most disliked aspect of the whole project. My view...

[Paul Dale]

(02-16-2015 07:47 PM)Bit Wrote:  I'm just curious about what it'd really take to implement it. Perhaps I'm being overly paranoid and this particular feature is actually quite simple, but it has been my experience that a reasonable explanation that covers 99.99% of cases and is basically good enough in practice, versus getting it 100.00% right, are often two very different things.

From scratch, it would be much easier to implement and get right.

From the current base, the worst part would be exterminating all of the odd-ball cases throughout the code that support stack lifting. It is a rather ad-hoc mixture and quite pervasive.


- Pauli

[Paul Dale]

(02-16-2015 08:07 PM)Marcus von Cube Wrote:  [To my knowledge it's solely Walter's decision and it's the most disliked aspect of the whole project. My view...

Sadly, agree in my view too.


- Pauli

[John Galt]

(02-16-2015 08:07 PM)Marcus von Cube Wrote:  

(02-15-2015 11:38 PM)Bit Wrote:  Walter would know the reason, perhaps there's some contractual obligation with the publisher.

To my knowledge it's solely Walter's decision and it's the most disliked aspect of the whole project. My view...

In my opinion Walter's manual is wonderful, a work of art. It's his manual though, so I suppose he's free to do as he pleases with it.

On that subject though, if the WP 34S project is open source, any one is free to write his or her own manual and publish it in whatever form he or she pleases as well.

Am I correct?

[walter b]

I fear this might become another religious discussion, but anyway:

Classic RPN is what was started on the Classics and maintained until and including the Pioneers. WP 34S (and - in consequence - WP 31S as well) feature classic RPN. We never had the intent to write a RePeLlent dialect. Instead, we decided to stick to good ol' standards. I'd like to keep it this way. There may be other projects with other targets.

d:-)

[Massimo Gnerucci]

(02-17-2015 08:27 PM)walter b Wrote:  a RePeLlent dialect.

That's what I was waiting for.
Yeah!! :)

[matthiaspaul]

(02-16-2015 07:47 PM)Bit Wrote:  

(02-16-2015 07:26 PM)matthiaspaul Wrote:  

Matthias, if it's not too much effort, could you point me to a detailed, strictly precise description of exactly how the 'Entry RPN' mode should work including all corner cases? Something that'd pass as a formal definition?

Unfortunately, I don't have the time for that right now. But if we ignore the dynamic stack proposal for a moment (as it is independent of Entry RPN), what I am proposing is basically down to a changed behaviour of the ENTER key in "Entry RPN mode". It should continue to work exactly as before in "Classical RPN mode", in order to please those who are accostumed to it.

I had hoped (but I am obviously missing something) that such a change would be not much more than:

xeq.c:

Code:


...
static void specials(const opcode op) {
...
case OP_ENTER:
   process_cmdline();
   lift();
   clr_lift();
   break;
...

into

Code:


...
   int last_opm = OP_DUMMY;
   byte rpn_mode = RPN_CLASSICAL;
...
static void specials(const opcode op) {
...
case OP_ENTER:
   process_cmdline();
   if ((rpn_mode == RPN_CLASSICAL) || (last_opm == opm)) {
      lift();
      clr_lift();
   }
   last_opm = opm;
   break;
...

Please bear with me, if I'm completely off here - scanning over the sources for 30 minutes, I obviously still have only a very vague idea of the actual implementation in the WP 34S.

Quote:Perhaps I'm being overly paranoid and this particular feature is actually quite simple, but it has been my experience that a reasonable explanation that covers 99.99% of cases and is basically good enough in practice, versus getting it 100.00% right, are often two very different things.

I often make this experience as well. The hardest part is the remaining 10-20% in a project (whatever it is), but this is also the part making a difference between "good enough" and brilliant.

Greetings,

Matthias

[matthiaspaul]

(02-15-2015 10:28 PM)matthiaspaul Wrote:  Regarding stack manipulation commands, I think, they should continue to work as before, except for [c]R^ and [c]Rv, which either should work on the whole dynamically stack, or better new [c]ROLL^ and [c]ROLLv commands would have to be added in order to provide the facility to work on the whole stack instead of the base stack ([c]R^/v aka ROT) only.

I meanwhile have come to the conclusion that it makes sense to let the [c]Rv and [c]R^ commands continue to work on the 4- or 8-level base stack only, even if a dynamic stack exists. These stack operations are frequently used to rearrange the "local" stack environment to bring the arguments in the desired order for following operations. Many people may have memorized specific key sequences to carry out certain stack tricks. Also, the dynamic stack isn't guaranteed to exists, so it can be "dangerous" to roll recent stack contents into it. So, [c]ROLL^ and [c]ROLLv operations working on the whole stack (including the dynamic stack) are needed in addition to [c]R^ and [c]Rv.

In addition to clearing the 4- or 8-level stack registers with 0, CLSTK would deallocate the dynamic stack. The behaviour of FILL would depend on if (with the dynamic stack enabled) we'd continue to support the T duplication feature or not: With the T duplication feature disabled, FILL would attempt to grow the dynamic stack as much as possible and fill the 4- or 8-level stack as well as the dynamic stack with the specified value. (For as long as we allow the dynamic stack to be automatically truncated as soon as re-purposed registers were needed again, growing the stack for FILL would have no negative sideeffects - otherwise, FILL would just work up to the current size of the dynamic stack.) With the T duplication feature enabled, FILL could just as well deallocate the dynamic stack (like CLSTK) and fill the 4- or 8-level base stack with the specified value. DEPTH would return the current effective stacksize (base stack size + dynamic stack size).

In the current layout of the WP 34S, the ROLL^ and ROLLv operations could either overload the [Rv] / [R^] or the [v] / [^] key assignments, when used with prefix [->]. cROLL^ and cROLLv would use the double-prefix [->] [CPX] instead. If [c]ROLL^ / [c]ROLLv would be assigned to [v] / [^], we could use the [->] [CPX] [Rv] / [R^] to roll the effective stack 4 or 8 levels at a time. CLSTK could be assigned to [->] [<-] (or [CPX] [<-]).

Greetings,

Matthias

[matthiaspaul]

(02-15-2015 10:28 PM)matthiaspaul Wrote:  When the stack shrinks, the contents of the last stored value in the dynamic stack would be dropped back into the T register, the register set to 0 and deallocated from stack use by (normalizing the buffer and) adjusting the stack pointer accordingly.
I'm undecided if the traditional T register duplication should happen again as soon as the dynamic stack is fully deallocated, of if it would be better to insert 0 then. I'm tending towards leaving it as it is, so that the dynamic stack is transparent to users of "Classical RPN". Mind, that, in contrast to the unlimited stack in RPL, in this dynamic RPN stack implementation, a minimum of 4 or 8 stack levels would always remain available for compatibility.

In my previous post I described the potential behaviour of the FILL command in a dynamic stack environment. This demonstrated an advantage for keeping the T duplication feature enabled. However, I have also identified a reason, why inserting 0 instead of duplicating the previous value might be useful in the dynamic RPN stack model (although with slightly more effort the T duplication feature could be supported as well - see below):

If we assume, that an "empty" stack holds 0 on all 4 or 8 levels (because this is what CLSTK does), we could slightly improve the implementation so that the allocation of the *first* value on the dynamic stack only happens when a non-zero value would be pushed out of the base stack. Once the dynamic stack is not empty, any further values pushed out of the base stack would have to be stored in the dynamic stack as well (including zeros). This initial-zero-suppression scheme would save us 4 or 8 initial register allocations (of zeros) in the case of an originally empty stack, thereby relaxing the memory situation by the same amount. This works only for as long as we insert dummy zeros on stack pops when the dynamic stack is empty. We'd thereby reproduce the original stack contents. If the original stack was not empty orignally, we would neither save or loose anything.

If the T duplication feature would still be desirable in the dynamic stack model, an improvement of the above could utilize a repetition counter (and optionally a variable to hold the repeated value). Basically, it would be a very crude initial-zero- or initial-value-compression scheme then. Instead of actually storing the value on the dynamic stack, we'd just count up the repetition counter for as long as the same value would have to be stored on the dynamic stack. Likewise, as soon as the dynamic stack is empty, we'd insert the repeated value (or 0 without a variable to hold the original value) for as long as the counter is not back to zero. Only then, the normal T value duplication would start again.

The index-counting in the proposed R/S stack-relative addressing extension could be adapted to take this repetition counter into account as well.

Greetings,

Matthias

[Bit]

(02-17-2015 08:27 PM)walter b Wrote:  I fear this might become another religious discussion, but anyway:

It doesn't have to be a religious issue if it's an optional feature. If Matthias is right and it could make the 34S attractive to a wider audience, or if it could make some of the existing users happier, then offering both interfaces sounds like a win-win scenario to me.

(02-17-2015 08:27 PM)walter b Wrote:  Classic RPN is what was started on the Classics and maintained until and including the Pioneers. WP 34S (and - in consequence - WP 31S as well) feature classic RPN. [...] There may be other projects with other targets.

If someone decides to implement Entry RPN, does the last sentence mean that you – as in Walter, Pauli and Marcus – would prefer the resulting software to call itself something else than 'WP 34S' if it offers Entry RPN as an option? Or does it simply mean you'd rather have it as a patch or as a feature that's disabled by default? (I'm just asking, I haven't yet decided if I'd like to work on this.)

[Paul Dale]

(02-18-2015 12:47 AM)matthiaspaul Wrote:  Please bear with me, if I'm completely off here - scanning over the sources for 30 minutes, I obviously still have only a very vague idea of the actual implementation in the WP 34S.

You should also investigate the clr_lift() calls and perhaps the get_lift() ones as well. Also check where the state_lift flag is accessed.


- Pauli

[walter b]

(02-18-2015 02:09 AM)Bit Wrote:  It doesn't have to be a religious issue if it's an optional feature. If Matthias is right and it could make the 34S attractive to a wider audience, or if it could make some of the existing users happier, then offering both interfaces sounds like a win-win scenario to me.

The WP series of calcs is specified as featuring classic RPN. I'd refrain from making things more complicated than necessary (remember Albert E.: "Everything should be made as simple as possible, but no simpler."). Once one has understood RPN, there's no user advantage in so-called Entry RPN IMHO.

d:-/

[Bit]

(02-18-2015 09:50 AM)walter b Wrote:  The WP series of calcs is specified as featuring classic RPN.

Well, of course, but unlike the digits of pi, it isn't set in stone. This entire thread is about the possibility of changing the specification.

(02-18-2015 09:50 AM)walter b Wrote:  I'd refrain from making things more complicated than necessary (remember Albert E.: "Everything should be made as simple as possible, but no simpler.").

That's a valuable idea (although Einstein probably phrased it differently) but by all accounts he was talking about scientific theories, and not about machines or about options provided to people...

Absolutely nothing would be more complicated for those who prefer classic RPN: they would just skip a chapter in the manual and not activate an option they don't need.

(02-18-2015 09:50 AM)walter b Wrote:  Once one has understood RPN, there's no user advantage in so-called Entry RPN IMHO.

Maybe not for you, maybe not for me, but you simply cannot speak for all users. If someone else's mind works in such a way that 'Entry RPN' feels more natural and easier to them, then it can be a genuinely useful feature regardless of how many people have no need for it.

[Thomas Radtke]

(02-17-2015 08:27 PM)walter b Wrote:  Instead, we decided to stick to good ol' standards.

No standard in this case. See here.

[Thomas Radtke]

(02-18-2015 06:06 PM)Bit Wrote:  That's a valuable idea (although Einstein probably phrased it differently) but by all accounts he was talking about scientific theories, and not about machines or about options provided to people...

I have to agree with Walter (if I understood correctly) that a second, parallel implementation of an entry method makes things more complex and thus more prone to bugs. And as most users will likely use one method exclusively, it splits the set of potential beta testers ;-).

[BarryMead]

(02-18-2015 07:13 PM)Thomas Radtke Wrote:  

(02-18-2015 06:06 PM)Bit Wrote:  That's a valuable idea (although Einstein probably phrased it differently) but by all accounts he was talking about scientific theories, and not about machines or about options provided to people...

I have to agree with Walter (if I understood correctly) that a second, parallel implementation of an entry method makes things more complex and thus more prone to bugs. And as most users will likely use one method exclusively, it splits the set of potential beta testers ;-).

Having worked on Torsten Manz's HP-15C simulator, I can attest to the complexity and myriad of bugs that surround the deeply embedded issue of STACK LIFT (It is a nightmare). Adding additional stack lift modes would greatly increase the potential for bugs in hundreds of places in the calculator, and would at least double the difficulty of testing and maintaining library functions or collections of user programs.
This is based on my personal experience with a much simpler calculator than the WP-34S. To preserve the overall integrity of the project, I would recommend against such a change.

[walter b]

(02-18-2015 07:03 PM)Thomas Radtke Wrote:  

(02-17-2015 08:27 PM)walter b Wrote:  Instead, we decided to stick to good ol' standards.

No standard in this case. See here.

Oh, are you going to demonstrate the claimed advantage of Entry RPN now? Finally?

d;-)

[Marcus von Cube]

Not that it cannot be done, but at what cost?


I do understand the (almost) unlimited stack of the 28C and its descendants with at least some of the stack levels visible. And I do understand the fixed level stack of what is called classic RPN here. The former has a unique feature: a variable (and countable) number of values on the stack, including the empty stack. A fixed stack simply doesn't care how many values the user has ever pushed. Whether the fixed stack contains garbage or useful data is completely open to interpretation. (I'm undecided about the whole stack lift business, I'm just talking about the stack depth).

A possible mixture of these modes as is the topic of this thread will lose either of the clear concepts. You cannot determine the number of values on the stack if its less then the fixed size of the "base" stack. You cannot recall arbitrary stack levels if they are beyond register D. You will (quickly, due to the limited resources of the platform) lose data off the top of the stack without notice, or, depending on implementation, will be confronted with an error message which is annoying if you just don't care about the "garbage" you pushed earlier. And all this happens "in the blind" because of the famous display.

KISS! Keep It Short and Simple!

BTW, fell free to implement anything you want and share the results with others, it's an open platform. And don't forget to implement proper error handling which restores the stack to its state before the error occurred.

[matthiaspaul]

(02-18-2015 08:53 PM)BarryMead Wrote:  

(02-18-2015 07:13 PM)Thomas Radtke Wrote:  I have to agree with Walter (if I understood correctly) that a second, parallel implementation of an entry method makes things more complex and thus more prone to bugs. And as most users will likely use one method exclusively, it splits the set of potential beta testers ;-).

Having worked on Torsten Manz's HP-15C simulator, I can attest to the complexity and myriad of bugs that surround the deeply embedded issue of STACK LIFT (It is a nightmare). Adding additional stack lift modes would greatly increase the potential for bugs in hundreds of places in the calculator,

Can you explain where you see hundreds of places affected when we would, only in Entry RPN mode, change the conditional X into Y duplication behaviour of the ENTER key, so that it does no longer happen immediately, but only when ENTER is pressed multiple times in succession?

What I envision in regard to an Entry RPN mode should be doable by a few isolated changes to the existing state machine, not a "parallel" implementation of a second state machine or a complete rewrite (except, perhaps, for other reasons like saving space - however, that would be a major task, whereas implementing an Entry RPN mode isn't IMHO).

Apparently you see much more necessary changes in the behaviour model. Can you perhaps give some hints? I must be missing something obvious, but perhaps we are just talking about different things...

Quote:and would at least double the difficulty of testing and maintaining library functions or collections of user programs.

I think, framing routines with (the equivalent of) STOM and RCLM and enforcing the proper settings inside (or bailing out with an error) is about all that would be necessary. I don't think this is much different from other preconditions that need to be tested for by routines. It certainly needs to be taken care of, but I don't think that it must be feared.

For code entered on the calculator itself, it might be possible to even make such mode switches completely transparent for users as the calculator knows which mode was used while entering a program.
It might be possible to just use different opcodes - I will have to think about it...

Greetings,

Matthias

[BarryMead]

(02-19-2015 12:38 AM)matthiaspaul Wrote:  Can you explain where you see hundreds of places affected when we would, only in Entry RPN mode, change the conditional X into Y duplication behaviour of the ENTER key, so that it does no longer happen immediately, but only when ENTER is pressed multiple times in succession?

What I envision in regard to an Entry RPN mode should be doable by a few isolated changes to the existing state machine, not a "parallel" implementation of a second state machine or a complete rewrite (except, perhaps, for other reasons like saving space - however, that would be a major task, whereas implementing an Entry RPN mode isn't IMHO).

Apparently you see much more necessary changes in the behaviour model. Can you perhaps give some hints? I must be missing something obvious, but perhaps we are just talking about different things...

Stack operations are deceptively SIMPLE LOOKING. They APPEAR to be easy, but are always much more complex under the surface. Paul Dale mentioned that stack operations were "Pervasive" and that you would need to look at code affected by at least three stack related variables to correctly alter program behavior. I am just saying that, from my experience, more things will break than you can possibly imagine. Time will tell if I am correct. I do know that if Bit makes the changes, they will have a much better chance of being right, because he is so talented, and has a much deeper grasp of the total code base than most. Paul Dale, or Marcus von Cube also have this kind of deep grasp of the code because they wrote most of it. I wish you the best of good luck in adding this feature, I hope I am wrong about it introducing bugs.