WP34S complex RCL



#2

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


#3

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.


#4

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

#5

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


#6

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


#7

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


#8

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


#9

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


Possibly Related Threads...
Thread Author Replies Views Last Post
  HP Prime: complex numbers in CAS. Alberto Candel 1 566 12-06-2013, 02:36 PM
Last Post: parisse
  [HP Prime] Plots containing complex numbers bug? Chris Pem10 7 1,090 12-05-2013, 07:40 AM
Last Post: cyrille de Brébisson
  Complex Number Entry on Prime Jeff O. 19 1,966 11-16-2013, 12:34 PM
Last Post: Jeff O.
  HP Prime complex results Javier Goizueta 0 344 10-06-2013, 12:59 PM
Last Post: Javier Goizueta
  HP Prime Solving Nonlinear System of Equations for Complex Results Helge Gabert 11 1,406 09-30-2013, 03:44 AM
Last Post: From Hong Kong
  [HP-Prime xcas] operations with complex numbers + BUGs + Request CompSystems 9 1,168 09-08-2013, 10:40 PM
Last Post: CompSystems
  Elliptic integrals of 1st and 2nd kind calculated by complex agm Gjermund Skailand 3 521 06-29-2013, 03:39 PM
Last Post: Gjermund Skailand
  HP-11C and complex numbers Antlab 5 804 06-28-2013, 08:59 AM
Last Post: Antlab
  71B Complex User Defined Functions in Calc Mode? Michael Burr 0 315 03-18-2013, 09:38 PM
Last Post: Michael Burr
  HP 34S complex # problem Richard Berler 2 381 02-17-2013, 11:01 PM
Last Post: Richard Berler

Forum Jump: