wp34S IEEE Floating-Point Conversions



#2




#3

Excellent! Great work Jake!

#4

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

Walter

#5

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


#6

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


#7

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


#8

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


#9

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


#10

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.


#11

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


#12

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.


#13

For the record: I concur d:-)

#14

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


Possibly Related Threads…
Thread Author Replies Views Last Post
  Proceedings of the IEEE Article Katie Wasserman 24 7,064 11-29-2013, 07:56 AM
Last Post: Walter B
  Milestones:List of IEEE Milestones -> HP-35 AlbertTocarLoseggs 4 2,150 11-27-2013, 08:52 AM
Last Post: Massimo Gnerucci (Italy)
  HP PRIME: derivative at a point Alasdair McAndrew 2 1,472 11-19-2013, 06:52 AM
Last Post: parisse
  Interesting Base Conversions - Porting a 1975 HP 25 Program to the HP 35S Eddie W. Shore 1 1,367 10-13-2013, 07:49 PM
Last Post: BruceH
  [wp34s] Converting to/from IEEE 754 Binary64 (Double Precision) David Maier 1 1,159 06-15-2013, 09:21 PM
Last Post: Paul Dale
  Decimal/Binary Conversions for the HP 39gii - 3/16/2013 Eddie W. Shore 0 948 03-16-2013, 04:30 PM
Last Post: Eddie W. Shore
  Unit conversions inside programs on 50g Chris Smith 2 1,284 02-23-2013, 05:35 AM
Last Post: Chris Smith
  HP28C/S ROM entry point lists update Christoph Giesselink 0 971 01-31-2013, 02:21 PM
Last Post: Christoph Giesselink
  HP-41 ROM Polling Point at FF5 Dan Grelinger 2 1,393 01-11-2013, 06:00 PM
Last Post: Monte Dalrymple
  33s Decimal Point Matt Agajanian 4 1,856 11-06-2012, 09:20 PM
Last Post: Matt Agajanian

Forum Jump: