[WP-34s] number display in program mode


I hope this hasn't been discussed before, otherwise I appologize for not searching enough.

Would it be possible to have whole numbers being displayed on just one program line even if every single digit eats up its own program step (like on the 41c for instance)? That would, at least for me, greatly increase legibility of numbers in program listings.

Thanks in advance for answering and maybe considering!


I'm afraid we will not add this feature. First of all, it's perfectly legal to branch into the middle of a digit string (maybe not a best practice approach but possible) and it would be impossible to make out the proper step number by looking at the listing. Secondly, the width of the step display is inappropriate to show a number in its entirety and we do not have a way to scroll the display horizonatally. We could special case numbers and swap the step/code display for them (step in the dot matrix, number in the 7 segment display) but I don't think we'll do.

Things will certainly change with a more powerful device (like the 43S which we might want to create once).


a) Is there anybody out there who will ever or has ever branched to a middle digit? I'd really like to see a usable example of that approach! ;-)

b) I would be perfectly happy if numbers could be displayed (in programming mode) in, say, 8-digit-portions or whatever fits in the upper display in one go. Most of the numbers I use in programs are shorter...


As Marcus told you, we won't do anything to fulfill this request with the HW given. IMO we pushed it really to its limits - there's no reason pushing it beyond. Thanks for your understanding :-)


On the HP-32SII, which has a somewhat more limited display, a constant like 123456789012 can be entered in only one programming step. After being entered it is displayed as

001 1.2346E11

Right shift SHOW will cause all significant digits to show up:


By what you say, I assume there's no more room left for this implementation. Well, we can wait for the wp43s :-)


The main problem is not display but storage and navigation. Our op-code scheme allows for 2byte and 4byte instructions. Because we have instructions to step back, we need to identify the double word instructions safely for BACK and BS to work correctly which is complicated enough and imposes restrictions on the possible arguments for the long commands. Storing numbers as a whole (preferably in internal format for performance and space reasons) would require new ideas on how to detect such an item in the program when traversing the code from bottom to top. The same is true for sequences of alpha characters.

We have the multi byte alpha strings and the # command for small integers as a (somewhat clumsy) work-around.


It would be possible to allow numbers and alpha strings as a single statement but we'd have to rework the back step in program mode completely. We'd also have to rework numeric and alpha entry completely -- if somebody is keen, feel free -- your changes would almost certainly be included.

At the moment op-codes are two bytes generally and the alpha argument commands (solve, integrate, triple alpha, ...) are four bytes with the first two byte word starting 0xF000 - 0xFF00. This scheme is entirely my fault after much pushing by Walter for better labels than 00 - 99 plus A, B, C & D. This weird encoding makes stepping backwards easy -- we need this for BST, BACK and BSRB.

Extending this to longer sequences is certainly possible but given the pain adding double word instructions caused (lots), I'd prefer to delay this to the 43S.

A side effect of this is that characters 0xF0 - 0xFF cannot be in the final position of triple-alpha commands. This isn't a significant failing IMO -- nobody has noticed and commented thus far. Comments about this from now on will be studiously ignored of course :-)

- Pauli


Just as a thought from a layman: to me it would not have to be a change of the way the number is handled internally (that could stay as it is now) but how it is displayed while keying it in or editing the program. Would that make it relatively easy to implement the change or am I thinking the wrong things here?

Additionaly I will look into #, that seems to handle some of my 'problems'... :-)


Major rewrite required....

- Pauli


Major rewrite required....

- Pauli

Would an extension of the # command range above 255 also require a major rewrite? To, say, 65,535 or 1,048,575??? ;-)


Yes :-(

We could add a double length integer command. It would have 24 bits for the argument (1 - 16M or -8M - 8M) range, but this would require quite a bit of work in the keyboard input code and the benefits seem small.

We could also put an implied decimal in there or make it a rational -- again more work in the input code and little benefit.

- Pauli


Alexander, how about putting your long constants in some registers before and just recall them in program execution? That's a nicer style IMHO anyway.


Thanks, that's the way I do it now. But one always wishes for an even 'perfecter' solution. The grass is always greener...you know! ;-)


Marcus, Walter,

thank you for considering and explaining. I had never thought that it would be hard to do like it is done on the 41c, 32s, 42s and 35s. I imagine you professional 'number crunchers' must have a better 'visual grip' to a display format like the one implemented on the WP-34s. I have a really hard time, well, to see the whole picture while working on one single digit on one single program line... ;-)
This is why I found the IR-printing-option mentioned in another thread so appealing.
But judging by the frequency the WP-43s gets insinuated lately, I take that as a subtle hint, although a not-so-subtle timeline would also be much appreciated!! ;-)

Thanks again for the WP-34s - I already like it the way it is now!


Is there anybody out there who will ever or has ever branched to a middle digit? I'd really like to see a usable example of that approach! ;-)

Hey, don't you remember the good old days of the 65/67/97 when you could do things like these?

Add 20 if Flag 1 is set:

Or, divide by 10 if x is negative:
Today on the 34s you can even multiply with or divide by 100, depending on the sign of x:
SKIP 002

Edit: Replaced a not exactly smart example by a more useful one. ;-)


Edited: 8 Apr 2012, 7:44 a.m. after one or more responses were posted




I'm thinking of a concept of user definable constants (immutable register contents stored in the program area) but I don't have an idea yet how this can be easily implemented. It would need support from the assembler, too, which would mean we have to reimplement part of the decimal library in Perl. It might look something like this:

DC 1.2345E67
DC -.89
The constants need to be first in the program and surrounded by some hidden framing to keep them separate from ordinary code. Adding the necessary keyboard code will be a nightmare, I'm afraid.


That would be a very nice feature but wouldn't solve the code legibility issue: if one reads the program step CNST 1, one still would have to skip back to the defining DC step if memory fails, the same as now with constants being stored in registers beforehand.


An alternative would be to reinstate the RCF commands to allow direct read only access to the backup registers. I always figured they were a great place to put constants.

- Pauli


The problem is not in reading the constants, it's in storing them.

Possibly Related Threads…
Thread Author Replies Views Last Post
  [WP-34S] Unfortunate key damage with update to V3 :( svisvanatha 5 3,207 12-10-2013, 11:37 PM
Last Post: Les Bell
  WP-34S (Emulator Program Load/Save) Barry Mead 1 1,809 12-09-2013, 05:29 PM
Last Post: Marcus von Cube, Germany
  Integration question and "RPN" mode comment Craig Thomas 16 5,847 12-05-2013, 02:32 AM
Last Post: Nick_S
  DIY HP 30b WP 34s serial flash/programming cable Richard Wahl 2 2,537 12-04-2013, 11:14 AM
Last Post: Barry Mead
  HP Prime: Recommendation for future RPN Program Mode BruceTTT 3 2,148 11-13-2013, 10:03 PM
Last Post: BruceTTT
  HP Prime: run a program in another program Davi Ribeiro de Oliveira 6 2,699 11-11-2013, 08:28 PM
Last Post: Davi Ribeiro de Oliveira
  WP 34S/43 ?'s Richard Berler 3 2,070 11-10-2013, 02:27 AM
Last Post: Walter B
  My FrankenCulator (wp-34s) FORTIN Pascal 4 2,171 11-09-2013, 06:18 PM
Last Post: FORTIN Pascal
  WP 34S Owner's Handbook Walter B 5 2,689 11-09-2013, 05:34 PM
Last Post: Harald
  wp 34s overlay and programming. FORTIN Pascal 6 2,914 11-08-2013, 01:28 PM
Last Post: Nick_S

Forum Jump: