Post Reply 
[34S] Proposal for Entry RPN mode with dynamic stack
02-19-2015, 02:23 AM
Post: #41
RE: [34S] Proposal for Entry RPN mode with dynamic stack
(02-18-2015 09:45 PM)Marcus von Cube Wrote:  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.
This would apply to the proposed dynamic stack as well, with the exception of that we could not generally guarantee a specific stack depth, as it depends on the register utilization. However, if a user would not attempt to store data in higher-numbered registers (which is fully under the control of the user), the resulting maximum possible depth of the stack is deterministic.
Quote: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.
Correct. And in the case of the dynamic stack, the dynamic stack may be filled with garbage or useful data just as well, it only depends on how the user uses the stack. The idea of the stack silently dropping the oldest value when it can no longer grow ensures that a user can continue to type ahead without having to flush the stack in between (as it may become necessary sooner or later with the stack in RPL). Nevertheless, it may be convenient even to Classical RPN users to store interim results on the stack and just use it as kind of a short-term log-book, as RPL users frequently do. For as long as he does not store data in the higher registers (which is fully under his own control), the stack won't be truncated, so he can fully depend on it, when he wants to, but can completely forget about it, when he doesn't.

Of course, it would be possible to put aside a dedicated area for the growing stack, but given its dynamic nature and the limited resources on this calculator, I think the "dynamically shared" usage model has a potentially higher utility value to users. We are just putting resources to use which are not currently used, it may or may not benefit a particular user, but it certainly doesn't restrict him in any way. At least, that's the idea.
Quote:A possible mixture of these modes as is the topic of this thread will lose either of the clear concepts.
Actually, I see it as a possible refinement of both concepts. Of course, in an ideal world, the user should be able to choose from all three modes, but implementing a true "unlimited" stack would require a significantly different approach, whereas the dynamic stack would be just an optional enhancement "on top" of the existing semi-static memory allocation model, therefore, I think, it could be implemented within the limited space constraints we have on this calculator.
Quote:You cannot determine the number of values on the stack if its less then the fixed size of the "base" stack.
It would be easy to let DEPTH return a value lower than the base stack's size, counting down (to 0) the number of drops after the dynamic stack has been emptied. This could even be used to indicate a "stack underrun". Similar, a "stack overrun" could be signalled when values drop out at the other end of the stack. Both indicators might be useful for users accostumed to a variable sized stack, and could be just ignored by users of fixed-size stacks. Such soft indicators may even help new users learning RPN in general.
Quote:You cannot recall arbitrary stack levels if they are beyond register D.
You could. [c]RCL R/S s, [c]STO R/S s and [c]x<> R/S s would allow for stack-relative addressing, so that RCL R/S 1 returns the value of X, RCL R/S 2 the value of Y, RCL R/S 5 or 9 the last value stored on the dynamic stack, etc.

Of course, more sophisticated stack manipulation functions could be added as well (as found on RPL calculators), but this is where I too think we should keep it simple at least for as long as this has to run on this calculator hardware.
Quote: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.
That's right, but it is part of the "concept" to implement a larger stack within the existing space constraints. We could even bind this to another flag, ideally combined with other message display.

(For the applications I envision some 16 - 25 stack levels would already be enough, whereas 4 or 8 levels are not. But others may have different needs.)
Quote:And all this happens "in the blind" because of the famous display.
We're certainly limited by the hardware here, but with Bit's new Y register display code enabled at least two stack levels can be displayed. It is not as convenient as on larger calculators, but at least we'd be able to store more than just 8 levels without the hassle of having to refer to registers. In some applications this could make a difference already.

Greetings,

Matthias


--
"Programs are poems for computers."
Find all posts by this user
Quote this message in a reply
Post Reply 


Messages In This Thread
RE: [34S] Proposal for Entry RPN mode with dynamic stack - matthiaspaul - 02-19-2015 02:23 AM



User(s) browsing this thread: 1 Guest(s)