HP Forums

Full Version: WP34S complex RCL
You're currently viewing a stripped down version of our content. View the full version with proper formatting.

Hi, I don't have a real WP34S yet, so I was using the emulator and doing some complex RCL's (RCL- , RCL+ etc) while running a test program, and noticed the following:
Lets say I have stored a complex number say 2+i1 in register 16. If on the stack I have in [stack]Y, 1 and in [stack]X, 2.002.
Now I perform the following: [cpx]RCL- 16. I should get 0.002 in X and 0 in Y (ie [2.002+i1]-[2+i1]). Instead I get -.002 in X and 0 in Y (ie [2+i1]-[2.002+i1]).
This seems to contradict the manual as well.
If I have misinterpreted something, I apologise.
Revision of emulator with VERS is: 34S 2.1 1610.
Regards
John

Quote:
Hi, I don't have a real WP34S yet, so I was using the emulator and doing some complex RCL's (RCL- , RCL+ etc) while running a test program, and noticed the following:
Lets say I have stored a complex number say 2+i1 in register 16. If on the stack I have in [stack]Y, 1 and in [stack]X, 2.002.
Now I perform the following: [cpx]RCL- 16. I should get 0.002 in X and 0 in Y (ie [2.002+i1]-[2+i1]). Instead I get -.002 in X and 0 in Y (ie [2+i1]-[2.002+i1]).
This seems to contradict the manual as well.
If I have misinterpreted something, I apologise.
Revision of emulator with VERS is: 34S 2.1 1610.
Regards
John

Yes you're right, I've just tried it and unfortunately I can confirm this bug! :-(

I've also tried CPX RCL/ nn and got the same result, so the complex register arithmetic with RCL is incorrectly implemented, it does reg-/stk instead of stk-/reg (of course CPX RCL+/RCL* doesn't matter).

The other direction CPX STO- or STO/ seems to be correct at least ...

Franz

Edited: 21 Sept 2011, 10:22 a.m.

Hi fhub, yes, apologies for not reporting the other cases, but STO operation are OK.
Regards
John

I thought I checked this when I originally coded it :-(

Oh well, the fix is in. We've lost a flash segment though :-( 12 bytes over.


- Pauli

Quote:
I thought I checked this when I originally coded it :-(

Oh well, the fix is in. We've lost a flash segment though :-( 12 bytes over.


Although I don't fully know your complex implementation, but I don't understand your changes for this cpxRCL- and cpxRCL/ bug:

Why was it necessary to introduce this new 'rev' argument and the additional code for those 2 cpxRCL ?

If the argument order for these 2 functions was wrong, then why not just swap those arguments? And this could also be done for cpxRCL+ and cpxRCL*, because + and * are of course commutative.

So I don't get it why this extra code is really needed (?) - and you won't have lost a flash region ...

Franz

I'm not passing the full arguments to the complex sto/rcl operation function. I pass the two register pointers in only. The other arguments are the results returned from the function which will either go into the register pair of the stack depending on the caller. The complex sto/rcl function itself handles the two values from the stack.

For STO, it is registers op stack. For RCL it is stack op registers. Thus the order of the arguments to the operation have to be reversed. Hence the rev argument. BTW, this is the same as the rev argument for non-complex STO and RCL with arithmetic operator.

So yes, the extra code is necessary. Either I reverse things inside the operation routine (easy) or pass the extra arguments in and reverse them on the outside (larger but also easy).

I could spend some effort squeezing back the bytes elsewhere but that hardly seems worthwhile if we're about to add a couple of kb of matrix support.


- Pauli

Ahhh, now I got it:

When I saw this "if(rev)" I first thought this reversing would be for - and / only, but now after a closer look I see that the difference is between STO and RCL - that makes sense of course! :-)

BTW, what's your guess about how long until we'll have those matrix feature included? ;-)

Franz

Quote:
BTW, what's your guess about how long until we'll have those matrix feature included? ;-)

No idea sorry. Very early days at the moment.

Still shuffling between C and FOCAL code. This all takes time which is in short supply at the moment :-(


- Pauli