A bit puzzled with the choice of using two registers to handle complex numbers. Why did you choose this design? The 15C has two stacks and you use Re<->Im to alternate. Providing that the 34S even has a capability to define the stack size, why didn't you guys use a dual Real/Imaginary stack? Or may be I missed something?
(03-18-2014 10:52 PM)Tugdual Wrote: [ -> ]A bit puzzled with the choice of using two registers to handle complex numbers. Why did you choose this design? The 15C has two stacks and you use Re<->Im to alternate. Providing that the 34S even has a capability to define the stack size, why didn't you guys use a dual Real/Imaginary stack? Or may be I missed something?
See
Complex Calculations under
Addressing objects and
Appendix F on WP 34S OWNER’S MANUAL.
(03-18-2014 11:22 PM)Massimo Gnerucci Wrote: [ -> ] (03-18-2014 10:52 PM)Tugdual Wrote: [ -> ]A bit puzzled with the choice of using two registers to handle complex numbers. Why did you choose this design? The 15C has two stacks and you use Re<->Im to alternate. Providing that the 34S even has a capability to define the stack size, why didn't you guys use a dual Real/Imaginary stack? Or may be I missed something?
See Complex Calculations under Addressing objects and Appendix F on WP 34S OWNER’S MANUAL.
Thanks for pointing this Massimo. I indeed read "The hardware of the HP-30b does not provide space for different data types. Thus, complex numbers have to be put in two registers each on your WP 34S as described on p. 29.".
Still I don't understand. If I'm not mistaken the 30b is essentially a microcontroller which at best brings BCD hardware support. I would imagine that the stack is essentially a matter of coding a table and a pointer and there must be enough space since we do have the possibility to double the stack size (which I don't use because above 4 registers is beyond my brain limits). Also regarding types, we do have the flexibility to calculate with 34 digits so why not twice 16 digits for complex numbers.
I'm certain there are good reasons for this limitation but I don't understand how the hardware impacts this.
The touchstone for the 34S was the HP-42S, not the 15C. :)
(03-19-2014 08:40 AM)Massimo Gnerucci Wrote: [ -> ]The touchstone for the 34S was the HP-42S, not the 15C. 
It was more the 32S and 32Sii actually
We extended the feature set to include many of the 42S functions and many more -- creeping featurism at its best.
There wasn't enough RAM to include a type along with each register. Hence, the indistinguishability of integers and reals when switching modes. Thus, we couldn't do a 42S style typed stack.
Okay, I admit the very first emails between Walter and myself did mention the possibility of a 15C style complex mode but that went away over time.
- Pauli
(03-19-2014 08:57 AM)Paul Dale Wrote: [ -> ]Okay, I admit the very first emails between Walter and myself did mention the possibility of a 15C style complex mode but that went away over time.
Hi Paul, what governed the decision?
I just can't use complex numbers, the 2 registers thing is too... hmm "complex" for me... With the 15C approach, you still have 1 stack level by complex number, same logic as for real.
(03-19-2014 10:55 AM)Tugdual Wrote: [ -> ]With the 15C approach, you still have 1 stack level by complex number, same logic as for real.
Easy enough to run into the stack lift trap with the 15C, i.e. have real and imaginary part on different levels ;-).
(03-19-2014 10:55 AM)Tugdual Wrote: [ -> ]Hi Paul, what governed the decision?
My implementation mostly
Dynamic memory allocation was not desirable which kind of prevented a dual stack.
With an eight level stack, complex numbers aren't a big problem even using two levels per number.
- Pauli
(03-19-2014 10:55 AM)Tugdual Wrote: [ -> ]I just can't use complex numbers, the 2 registers thing is too... hmm "complex" for me... With the 15C approach, you still have 1 stack level by complex number, same logic as for real.
Please look at it this way: an 8-level stack is also useful for real calculations. You don't need to remember all its contents - your WP 34S does it for you. A 2*4-level stack a la HP-15C may be nice for complex stuff but is useless else. YMMV
d:-)
(03-19-2014 03:28 PM)walter b Wrote: [ -> ]Please look at it this way: an 8-level stack is also useful for real calculations. You don't need to remember all its contents - your WP 34S does it for you.
Hey that is an interesting comment. I myself tend to always remember what is in stack to seek for optimization... Also there is always the risk to stack 9 items - ok this is probably very unlikely but I wonder how you approach RPN with large stacks?
(03-19-2014 03:28 PM)walter b Wrote: [ -> ]A 2*4-level stack a la HP-15C may be nice for complex stuff but is useless else. YMMV
"useless" is may be going a bit far
but I tend to see your point.
This being said I guess there is a similar flaw in between 15C and 34S. To enter a complex value in the 15C you would do:
1. Real value
2. ENTER
3. Imaginary part
4. (f) I
So basically until step 4 you used 2 stack entries pretty much like the 34s.
BTW, are complex matrices supported?
(03-19-2014 10:13 PM)Tugdual Wrote: [ -> ]To enter a complex value in the 15C you would do:
1. Real value
2. ENTER
3. Imaginary part
4. (f) I
So basically until step 4 you used 2 stack entries pretty much like the 34s.
There is a somewhat convoluted method to enter a complex value on the 15C stack without first using two stack levels. Useful in case you have something in Z that you want to keep for future use but need to enter a complex value. It goes something like this:
1. key in imaginary component
2. press f Re<>Im
3. press <-- (backarrow to clear x and disable stack lift)
4. key in real component
5. proceed with calculations
There is an even more convoluted method to accomplish the same thing on the 42s.