▼
Posts: 429
Threads: 31
Joined: Jul 2011
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!
▼
Posts: 3,283
Threads: 104
Joined: Jul 2005
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).
▼
Posts: 429
Threads: 31
Joined: Jul 2011
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...
▼
Posts: 4,587
Threads: 105
Joined: Jul 2005
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 :-)
▼
Posts: 2,761
Threads: 100
Joined: Jul 2005
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 :-)
▼
Posts: 3,283
Threads: 104
Joined: Jul 2005
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.
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
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
▼
Posts: 429
Threads: 31
Joined: Jul 2011
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'... :-)
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
Major rewrite required....
- Pauli
▼
Posts: 429
Threads: 31
Joined: Jul 2011
Quote:
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??? ;-)
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
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
Posts: 4,587
Threads: 105
Joined: Jul 2005
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.
▼
Posts: 429
Threads: 31
Joined: Jul 2011
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! ;-)
Posts: 429
Threads: 31
Joined: Jul 2011
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!
Posts: 653
Threads: 26
Joined: Aug 2010
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! ;-)
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:
F?1
2
0
+
Or, divide by 10 if x is negative:
x<0?
.
1
x
Today on the 34s you can even multiply with or divide by 100, depending on the sign of 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
▼
Posts: 429
Threads: 31
Joined: Jul 2011
▼
Posts: 3,283
Threads: 104
Joined: Jul 2005
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
+
...
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.
▼
Posts: 429
Threads: 31
Joined: Jul 2011
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.
Posts: 3,229
Threads: 42
Joined: Jul 2006
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
▼
Posts: 3,283
Threads: 104
Joined: Jul 2005
The problem is not in reading the constants, it's in storing them.
|
