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:

123456789012

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

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!

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

Quote:

---

Major rewrite required....

- Pauli

---

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! ;-)

Quote:

---

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! ;-)

---

Add 20 if Flag 1 is set:

 F?1

  2

  0

  +

 x<0?

  .

  1

  x

 x>0?

 SKIP 002

  .

  0

  1

  0

  0

  x

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

Dieter

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

Nice!

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

...

CNST 0

CNST 1

+

...

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.