WP-34S Rectangular/Polar (Suggested Change)

[BarryMead]

This is probably a question for Paul, or Marcus. Others may not find it interesting.

Since the Polar/Rectangular operations replace both X and Y with new values and now appear in the
display as a dual objects similar to complex numbers, do you think it makes more sense to call the
setlastXY(); function at the end of these two functions instead of setlastX(); ?

This would allow one to review/recover both X and Y pre-operation values. Both X and Y are of equal
value and can be thought of as an atomic unit with respect to Polar/Rectangular conversions.

What do you think?

[Marcus von Cube]

This makes sense to me. For the time being, in a limited way (modulo 2π) you can recover with the inverse function.

[BarryMead]

If you do decide to make the change, be sure to let Walter know before he reprints the manuals.

[walter b]

(04-06-2014 07:01 PM)BarryMead Wrote:  If you do decide to make the change, be sure to let Walter know before he reprints the manuals.

I may be also part of the decision, Barry. Anyway, please let me try to understand: Why do you want to have x and y saved in L before executing ->R or ->P ? On the WP 34S, you can revert both conversions easily ...

d:-?

[BarryMead]

Walter:

Because the Rectangular/Polar conversions operate on the Atomic Unit(X,Y) much like complex operations
do. Both X and Y are of equal importance so saving only X (last x) only saves half of the information lost
during the operation. Even though the operation can be reversed by selecting it's opposite function the
end result will be reduced modulo (2Pi) in radians mode or modulo (360) in degrees mode, so there is a true
loss of information. The Atomic nature of the X/Y, Range/Angle pair is even more apparent now that the new
display shows the pair of numbers after the Polar/Rectangular operations. Many other HP calculators show
range/angle, X/Y on the same line and treat them as a single entity much like a complex number. Obviously
the WP34S breaks complex numbers into two parts, but saves both parts in L (and I). It just seems logical
to save both parts of the two-part Rectangular/Polar objects as well.

I just looked through the manual, and it appears that there is no mention of lastX behavior
regarding Polar/Rectangular operations (at least not in the IOP). There may be a reference somewhere
else in the manual that I didn't see.

Does this help?

[orcinus]

Pardon me parachuting into a thread, but...

I never understood why complex value isn't always stored as P internally, with ->R and ->P only being different by a display flag (and input handling), in cases such as this.

In other words, is there a technical reason why both ->P and ->R don't assemble a polar vector internally from X: and Y: (taken literally, as polar, or calculated from rectangular coordinates, based on the key), then ->R sets a flag that triggers conversion to rectangular on display, while ->P does not?

Sure, doing all calculations in polar (internally) even when user wants them (and sees them) in R will accumulate an error, but isn't an error in the Nth decimal place of the mantissa better than a whole k*pi of error?

[BarryMead]

Orcinus wrote:


I never understood why complex value isn't always stored as P internally, with ->R and ->P only being different by a display flag (and input handling), in cases such as this.


This is the way some other calculators work, but looking into the source code, I would think this would be a major rewrite of the WP34S calculator. You can still buy the HP35S if you like that behavior.
Regarding the "Technical Reason". The WP34S does not provide any storage mechanism for complex numbers or range angle pairs. By convention the registers in the WP34S are all separate items.
Only CERTAIN functions operate on pairs or groups of registers, and the special meaning of those registers is spelled out in the IOP (Index of Operations). Even matrices are made of separate registers. They are
only handled as OBJECTS by the special matrix routines that understand how to group the registers. You have to FORMAT your matrix descriptor so that the matrix operations know which registers mean what.
This approach greatly simplifies the WP34s firmware, but does require that the user know what the functions do regarding groups of registers.

Many of us think the approach chosen by the WP34s has merit as well, because the simplified design allows the WP34S to pack in HUNDREDS of cool functions that don't exist in any other calculator.

[walter b]

Barry,

(04-06-2014 07:35 PM)BarryMead Wrote:  Does this help?

It explains what you want and why, and that's all I asked you for.

You're right, there's not special mentioning of LASTx with respect to P<->R in the manual. AFAIK it's treated the same way in HP's docs, but that's an explanation, no reason for the shortcoming.

d:-)

[Marcus von Cube]

(04-06-2014 08:01 PM)orcinus Wrote:  I never understood why complex value isn't always stored as P internally, with ->R and ->P only being different by a display flag (and input handling), in cases such as this.

Just to add a few facts to the answer Barry gave: We've run out out of resources on the hardware from the beginning. 2 KB of battery backed RAM (+ 4KB of scratch RAM) and 128 KB of flash isn't a whole bunch of memory to operate on. So everything is essentially at fixed addresses (or shuffled around when the configuration changes). We do not have objects which carry meta information about their nature. We just have a single array of registers (including the stack). What's in a register is solely determined by the mode the calculator is in (single/double precision, integer) and the command(s) operating on the data.

The 43S will be a different beast, though. :-)

[Paul Dale]

(04-06-2014 08:01 PM)orcinus Wrote:  I never understood why complex value isn't always stored as P internally, with ->R and ->P only being different by a display flag (and input handling), in cases such as this.

Marcus answered this well. We don't have any available RAM to indicate that these values are complex rather than two reals. We don't have types on the stack, just registers.

Most devices I'm familiar with store complex numbers in rectangular form not polar. I had a grand scheme for the OpenRPN project, to allow complex numbers stored in either form and to automatically convert as required.


- Pauli

[Paul Dale]

This isn't a silly suggestion. Tagging these conversions as complex operations would set L & I appropriately and indicate a complex operation occurred. Or just calling the routine to set both -- change setlastX() on lines 1448 and 1463 of decn.c to setlastXY(). There would be no visual indication of a complex operation having occurred this way.

We would lose backward compatibility with older devices' versions of these functions which is a fairly major concern.

Finally, you can always write a library routine to do this conversion exactly as you'd like and call that instead.


- Pauli

[BarryMead]

Look at my original posting. The only change I was suggesting was to change the

setlastX();

function call to

setlastXY();

at the end of the "Polar to Rectangular" and "Rectangular to Polar routines".

I apologize if I made it sound more grandiose that that small change.

The only case I can think of where incompatibilities with older programs might occur is if a program
COUNTED on the value in the I register not being altered by the R->P or P->R routines.
I think one would be hard pressed to find such a program.

[Paul Dale]

If we change the 34S's implementation of these, the 31S will be different -- it doesn't support complex operations and storing Y into I would be an anomaly there. Of course, the 31S has UNDO which kind of compensates.


Pauli

[walter b]

Barry,

(04-07-2014 01:34 AM)BarryMead Wrote:  The only change I was suggesting was to change the

setlastX();

function call to

setlastXY();

at the end of the "Polar to Rectangular" and "Rectangular to Polar routines".

Let's make it really simple. WP 34S is closed as stated here many times (already in the old forum). We are willing to correct bugs and we've shown we can do that pretty fast compared to HP. We are also willing to take suggestions whenever they make sense and fit smoothly into the package. If they lead to any trouble, however, we won't (and can't) take them.

Your suggestion is no bug report, definitivly. And it turns out falling into the latter bin. Sorry, we can't take it.

That's surprising since it looks simple as well. We can only ask you to wait for the 43S where will be more space as mentioned above and elsewhere many times.

d:-/

BTW, would you please use <Quote> for (1) correct quoting and (2) allowing the forum SW to file your posts correctly? TIA.

[Thomas Klemm]

(04-07-2014 03:35 AM)walter b Wrote:  We are willing to correct bugs and we've shown we can do that pretty fast compared to HP.

What's the proper way to report bugs?

[walter b]

(04-07-2014 03:53 AM)Thomas Klemm Wrote:  What's the proper way to report bugs?

Send us an email, post your finding here, ... whatever you like.

d:-)

[Thomas Klemm]

(04-07-2014 05:20 AM)walter b Wrote:  Send us an email, post your finding here, ... whatever you like.

Quote:Just noticed a bug in the method Vec_Magnitude:

[Paul Dale]

(04-07-2014 09:01 AM)Thomas Klemm Wrote:  

Quote:Just noticed a bug in the method Vec_Magnitude:

I think I've fixed this now. Replaced RCL* T by x^2.



- Pauli

[orcinus]

Thanks everyone!

(04-06-2014 09:50 PM)Marcus von Cube Wrote:  We do not have objects which carry meta information about their nature. We just have a single array of registers (including the stack). What's in a register is solely determined by the mode the calculator is in (single/double precision, integer) and the command(s) operating on the data.

Got it. This was the answer i was looking for

(04-06-2014 09:50 PM)Marcus von Cube Wrote:  The 43S will be a different beast, though. :-)

I keep avoiding buying/making a 34S because i keep waiting for 43S.
So nice to hear that

[Paul Dale]

(04-08-2014 02:23 AM)orcinus Wrote:  I keep avoiding buying/making a 34S because i keep waiting for 43S.
So nice to hear that

I wouldn't. The 43S is several years away minimum.


Pauli