04-04-2014, 04:29 PM
(04-04-2014 12:37 PM)walter b Wrote: [ -> ]The yReg display will be toggled by YDOFF / YDON. Probable default will be YDOFF on both the WP 34S and the WP 31S.
That sounds great. Thanks!
04-04-2014, 04:29 PM
04-04-2014, 10:02 PM
04-05-2014, 12:43 AM
04-05-2014, 10:18 AM
04-05-2014, 11:03 AM
04-05-2014, 11:28 AM
(04-05-2014 11:03 AM)walter b Wrote: [ -> ]Ooops, we'll look into that. Thanks for reporting.
I've found the errant line in question. Line 433 of xeq.c which is the conditional test in this code snippet:
Code:
int stack_size(void) {
if (! UState.stack_depth || (! XromFlags.xIN))
return 4;
return 8;
}The equivalent test on the 34S is:
Code:
if (! UState.stack_depth || (is_xrom() && ! XromFlags.xIN))The in xrom test has been lost along the line somewhere and the code thinks we're always in xrom with a small stack size
- Pauli
04-05-2014, 05:20 PM
04-05-2014, 05:24 PM
04-05-2014, 07:15 PM
(04-04-2014 08:46 AM)walter b Wrote: [ -> ](04-04-2014 08:00 AM)Paul Dale Wrote: [ -> ]I'd prefer an unlimited stackAn unlimited stack has a significant drawback: there's no top level which can be repeated. IMHO, 8 levels are a nice practical compromise connecting the best of two worlds.
Okay, this may be a radical suggestion, but I have given it some thought and I think it would be marvelous. So here it goes.
The convenience of the top-level-replication is largely (or exclusively) due to the following fact: when levels y,z,t (or y,z,t,a,b,c,d) have the same value (probably different from x), and if any binary operation (let us say multiplication y*x) is performed on x & y, then the answer y*x is placed in x, while y stays unchanged.
In fact, some binary operations such as Delta% and %T (percentage of total) have standard RPN implementations that put the answer in x while leaving y undisturbed, because this is often more convenient.
The same behavior is very useful in other contexts, precisely when top-level-replication comes in handy.
How could these advantages be realized without top-level-replication? Well, they could easily be achieved if we could "force" a binary operation such as multiplication * to behave in the manner that Delta% or %T behave. Therefore, corresponding to, say, ordinary multiplication * there should be a different binary operation # that, applied to the stack, leaves y unchanged while placing the product y*x in x.
For instance, Horner's algorithm to evaluate pz^2 + qz + r would read
Code:
z [ENTER]
p [ENTER]
#
q
+
#
r
+This will leave the answer in x and the original value r in y.
Internally, every regular binary operation such as +, -, *, / , ^, etc, would have a counterpart that leaves y undisturbed. More esoteric functions such as nCr (combinations) may perhaps not be worth the effort of being given a counterpart.
The trick would be using the regular operation * as well as # in a sensible manner in practice. Here I offer some ideas:
A semi-long press of the * key (say, at least 0.5s but less than 1s) would call the function # instead of * (while >1s would NULL).
An alternative idea is using flags. There could be a single flag that changes the default behavior of binary operations to act as I have explained. A much better idea would be having a separate flag for each operation. A simple SF* or CF* would enable or disable the new behavior for the multiplication operation *. Perhaps even better, pressing the corresponding key * for 0.5s would have the effect of *toggling* the flag, so subsequent uses of the key would have the opposite behavior. There could also be a global flag disabling this new behavior to avoid confusing users unfamiliar with it.
For me, the motivation is to have a uniform way to deal with all binary functions that may or may not leave y undisturbed at the user's choice. Perhaps these ideas can materialize in the 43s, which I would absolutely rather have an infinite-height stack---the lack of top-level replication seems a weak argument to have a fixed-height stack.
SuperNumero
04-05-2014, 08:16 PM
04-06-2014, 06:09 AM
04-06-2014, 07:12 AM
04-06-2014, 06:05 PM
04-09-2014, 09:52 PM
04-09-2014, 11:12 PM
(04-09-2014 09:52 PM)BarryMead Wrote: [ -> ](04-06-2014 07:12 AM)Paul Dale Wrote: [ -> ]The 34S team is still open to constructive suggestions. Especially when they include code patches.I never bothered to submit my wp34s suggestion about saving both halves of the Polar/Rectangular
- Pauli
objects with setlastXY() until I read this posting, because I knew that the WP34S project was
closed to new ideas. But when I read this posting I turned it in, only to discover that I shouldn't have.
Oh Well I don't pretend to understand politics, only science!
Well, if suggestions are being taken, one of the things that I would like is to have stosum & rclsum instructions which would take a register reference and allow one to store the summation registers to a register block starting at the specified reference, or load the summation registers from a register block starting at the specified reference.
That would allow me to have a program that has more that one set of summations going at a time.
I've been meaning to look at the code to see the viability of doing something like that, but since we are taking requests
, why not ask?In all seriousness, even if the team is not interested in such an addition, I'd love to hear your thoughts on the feasibility if I were to undertake it in my own version.
04-09-2014, 11:49 PM
04-10-2014, 12:04 AM
04-10-2014, 12:22 AM
(04-09-2014 11:12 PM)Marcel Samek Wrote: [ -> ]Well, if suggestions are being taken, one of the things that I would like is to have stosum & rclsum instructions which would take a register reference and allow one to store the summation registers to a register block starting at the specified reference, or load the summation registers from a register block starting at the specified reference.I assume you are planning to add these commands to your own custom version of the WP-34S not the
That would allow me to have a program that has more that one set of summations going at a time.
I've been meaning to look at the code to see the viability of doing something like that, but since we are taking requests
In all seriousness, even if the team is not interested in such an addition, I'd love to hear your thoughts on the feasibility if I were to undertake it in my own version.
WP-31S. Johanathan, Paul, and Pascal have generously sent me detailed instructions on how to
set up my own tool chain so that I can compile custom versions of the calculator firmware, and
emulators. ( I am still in the process of getting that tool chain setup ) If you are interested in having
me forward those emails from Jonathan, Paul and Pascal to you let me know.
04-10-2014, 02:47 AM
04-10-2014, 02:49 AM