wp34s emulator - prgm constant split one digit per line

[mstram]

I'm using wp 34s 3.3 build date 2015-12-22 (3844)

When trying to enter a constant 0.10001, for a subsequent ISG instruction, the
emulator is only allowing one digit / program line.

The program does work (when I trace it the number is getting "assembled" back together).

W)orking A)s D)esigned ?

Or have I turned on / off some flag or setting somewhere ?

Mike

[Dieter]

(12-27-2017 06:18 PM)mstram Wrote:  When trying to enter a constant 0.10001, for a subsequent ISG instruction, the
emulator is only allowing one digit / program line.

The program does work (when I trace it the number is getting "assembled" back together).

W)orking A)s D)esigned ?

Yes. The 34s does not combine multiple digits into one program line like the HP41 or 35s do it. In this regard it works like the classic programmables, e.g. the 67 or 34C: one digit, one line. Including the decimal point, EEX and +/–.

But there are some ways to do it differently:

1. Integers between 0 and 255 can be entered in one line by means of the CONST menu. The last entry there is "# 0 to 255". This way you can enter a number like 123 in one single program line. This even makes sense with single-digit numbers since these shortcut numbers (shown with a leading # sign) are executed faster than regular numbers.

2. Take a look at the SDL and SDR commands (in the X.FCN menu) that shift a number by a given number of decimal places to the left or right. So if you want to enter 0,0123 this can be done with #123 followed by SDR 004.

3. ISG, ISE, DSE and DSL do not need an increment/decrement in the 4th and 5th place of the control number. If none is given, these commands assume a delta of 1. So if you want to count from 0 to 100 you do not have to enter 0,10001 – a simple 0,1 will do. That's just two steps ("," "1"). And of course you can also use the SDL/SDR method and do it with #001 SDR 001.

4. Be creative. If, for instance, you want something like 3000001 you can try #003  SDL 006  INC X. Or create a 426 with #213  STO+X. Or...

5. In a similar way you can only enter one alpha character per line. But you can have lines with up to three characters by pressing [f][α] twice in program mode.

Dieter

[Paul Dale]

As Dieter points out, this is as designed. SDL/SDR are extremely fast operations as there are no floating point operations involved.

There are some interesting effects in integer mode. As the 34S stands, digits are evaluated in the current integer mode settings. Thus, for example, 10 is always the current base (if the word size is sufficient). If the number were entered as a single step, should it automatically change base when the calculator does? Should it honour the current sign mode and word length? If so, what happens when the word is shortened and then lengthened again?

Similar things happen for fractions and H.MS entry, although they aren't as convoluted being display modes.



Pauli

[mstram]

Ok, thanks for the info.

Seems a strange design.

What is the reasoning ?

[Dieter]

(12-28-2017 12:37 PM)mstram Wrote:  Seems a strange design.

The 34s follows the same paradigm as classic HP calculators: one digit, one line. In addition to this there is a handy shortcut with the # constants. What exactly do you consider strange?

(12-28-2017 12:37 PM)mstram Wrote:  What is the reasoning ?

A program line that contains a number like -1,234567890123456 E-199, let alone a 34-digit value in double precision mode, would require a substantial number of bytes which can vary with the value itself. Implementing this is not trivial. Maybe Pauli can say more about the details.

Dieter

[Paul Dale]

(12-28-2017 08:34 PM)Dieter Wrote:  A program line that contains a number like -1,234567890123456 E-199, let alone a 34-digit value in double precision mode, would require a substantial number of bytes which can vary with the value itself. Implementing this is not trivial. Maybe Pauli can say more about the details.

The opcodes were designed for the digit per step quite deliberately. Switching to a number per step would have complicated things. It would be possible to leave the encoding as a digit per step and to parse consecutive steps and display a number -- this would make back stepping tricky and we'd also have to store the mode settings used for entry somewhere. Is the number a real or an integer (the same key strokes work fine in both modes currently)? If the latter what sign mode and word size? How to deal with numbers that don't fit on the display anymore? A lot was sidestepped by the current design.

The better way would be to store the assembled value including type information as a program step. The 34S simply isn't setup for this -- it cannot distinguish between integers, reals and strings due to lack of space. The 43S design does include this information and I expect this would be the path to follow.


Pauli

[mstram]

(12-28-2017 09:59 PM)Paul Dale Wrote:  The better way would be to store the assembled value including type information as a program step. The 34S simply isn't setup for this -- it cannot distinguish between integers, reals and strings due to lack of space. The 43S design does include this information and I expect this would be the path to follow.
Pauli

Well what is it doing when you enter a number in "non-program" mode ?

Seems it's "assembling" the number there ?

[Paul Dale]

It is building the number digit at a time exactly like it does from a program. Each digit is copied into an internal buffer and when something causes the value to go onto the stack, it is parsed and pushed.

It is a lot more convoluted than this would indicate because the calculator powers down between keystrokes when not in a program. There is also an amount of error checking being done as the keys are pressed.


Pauli

[Marcus von Cube]

To add to Pauli's remarks: In the 30b hardware we just have 128KB of flash memory and 2KB of non volatile RAM. Now compare the original 30b specifications with what we did with the same hardware in the 34s firmware design. There just wasn't any space left for a more elaborate op code scheme. Especially instructions such as SKIP and BACK would be much harder to implement with program steps of variable length.