▼
Posts: 349
Threads: 66
Joined: Apr 2007
▼
Posts: 1,545
Threads: 168
Joined: Jul 2005
Excellent! Great work Jake!
Posts: 4,587
Threads: 105
Joined: Jul 2005
... and thanks a lot for checking all the integer operations!
Walter
Posts: 3,229
Threads: 42
Joined: Jul 2006
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
▼
Posts: 1,216
Threads: 75
Joined: Jun 2011
Quote:
R^ R^ is of course [CPX] R^ (or CPX Rv or CPX x<>y with a four level stack).
Talking about complex operations, I'm really wondering why you have implemented it the way you did?
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
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
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
▼
Posts: 1,216
Threads: 75
Joined: Jun 2011
Quote:
Of course, the complete source code is freely available so you are welcome to add a complex mode and submit a patch :-)
Well, I see you completely misunderstood me. :-(
I didn't suggest to change anything in entering/displaying or the internal representation of complex numbers (although it could be made much better, but because of the limitations of this small calc certainly not possible).
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
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
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
▼
Posts: 3,283
Threads: 104
Joined: Jul 2005
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.
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
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
▼
Posts: 1,545
Threads: 168
Joined: Jul 2005
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.
▼
Posts: 4,587
Threads: 105
Joined: Jul 2005
For the record: I concur d:-)
Posts: 349
Threads: 66
Joined: Apr 2007
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
|