Excellent! Great work Jake!

... and thanks a lot for checking all the integer operations!

Walter

Jake,

Very nice effort and thanks for the large amount of testing you've undertaken.

Leaving out the somwhat weird mode change behaviour of the 16c doesn't seem to have hurt which is good :-) It saved us a deal of code space.

Was the conversion otherwise straightforward? The extra capability of our integer operations might have made porting 16c code more difficult -- at least there aren't many 16c programs in the wild so we were willing to live with this.

A few quick things I noticed:

• We have a register I if you are not using complex operations so you didn't need to grab register 99 instead.

• The 1 + and 1 - sequences are INC X and DEC X.

• R^ R^ is of course [CPX] R^ (or CPX Rv or CPX x<>y with a four level stack).
  

- Pauli

Quote:

---

R^ R^ is of course [CPX] R^ (or CPX Rv or CPX x<>y with a four level stack).

---

Usually when I do complex operations I don't need only 1 or 2 but even a bunch of them. As it is now I have to precede EVERY function or operation with this [CPX] key.

In my opinion it would be more convenient (and logical) to make this 'complex' a separate mode (as for the integer mode), which can be switched on/off in the modes menu (real, complex, integer, ...).

So you won't have to use this CPX prefix anymore for every calculation, and furthermore this would make the CPX key free for any other useful purpose.

Franz

We followed the implementation path of the 32sii for complex numbers. We knew we weren't going to be able to do what the 42s does due to memory and display constraints. I guess we could have gone the path of the 15c but that decision is long past and the move to an eight value stack was late in the piece.

Of course, the complete source code is freely available so you are welcome to add a complex mode and submit a patch :-)

- Pauli

Quote:

---

Of course, the complete source code is freely available so you are welcome to add a complex mode and submit a patch :-)

---

All I would like to be different for complex operations is, that pressing this [CPX] key (or better changing to a 'complex mode' in the settings menu) should set the calculator into a complex mode, where every new function or operation is done as if you had pressed again this [CPX] key, i.e. for every operation (for which it makes sense) there should be used the 'complex' counterpart - until you switch this complex mode off again.

This would definitely NOT require any BIG changes in the WP34S program structure.

Franz

I understood, I just was clear enough in my response. It is getting late here and I'm getting tired and we've been very busy trying to get final bits and pieces sorted out for the beta.

You asked why we went the way we did and I answered that. This might have been a poor decision in hindsight but at the time it was probably the correct one.

Then I suggested you could add the complex mode and submit a patch. I had assumed but didn't make explicit that this was a not pressing the prefix lots of times :-) I suspect it isn't completely straightforward but I agree it won't require major deep surgery into the code base.

- Pauli

We might add a user settable mode which makes the CPX prefix sticky. Press it once to turn it on and once to turn it off. The user decides what he wants by setting the stickiness mode in his preferences.

Hi Pauli,

Quote:

---

We have a register I if you are not using complex operations so you didn't need to grab register 99 instead.

---

I totally forgot about register I (109) ...that would have been much better. As you can see, I'm still learning :-) And using INC X and DEC X would be better as well.

The conversion was otherwise straightforward, and the merging of keystrokes in the 34S for functions which required the x-register value as their argument in the 16C (like SB, RL, MASKR, etc) was a step saver. I had to remember though, that in these cases, the 34S argument was always in decimal (such as MASKL 24) versus in the 16C, when the argument was loaded into X in the current base as program steps, so in the 16C assuming HEX, the steps were "1" and "8". Otherwise, it was not too bad at all. Having virtually all the 16C functionality available is a really great thing.

Jake

This path is fraught with problems. That's why I didn't think it was just a "set a bit and all will be happy" patch.

The keyboard state machine separates real and complex early on and most keys will cease functioning with the complex bit set (digits e.g.). Okay fix this but don't use any more flash space doing so.

Now, what about operations that don't take a complex prefix? What to do here? Exit complex mode? Ignore the command? Do the command anyway? Raise an error? It will change depending on the function naturally.

Entering new numbers and looking at the complex portion of numbers on the stack is also problematic now, x<>y and ENTER take a complex prefix so they won't do what you want all the time.

So all in all, it cannot be a set a bit and life will be happy task. It will require significant effort defining how operations work in the two modes and then making lots of small changes to bring everything into line.

And then a lot of code shrinking due to the bloat just introduced.

- Pauli

Personally, my 2 cents would be to stay with the CPX prefix being required. I have done a good bit of complex number math with the 34s so far and it isn't *that* cumbersome. Sure, a sticky mode would be nice, but I would be afraid that a) things might break if it were changed :-) and b) the code squeezing required might also break something.

For the record: I concur d:-)