WP34S Rectangular/Polar (Suggested Change)

04062014, 06:31 PM
(This post was last modified: 04062014 06:59 PM by BarryMead.)
Post: #1




WP34S Rectangular/Polar (Suggested Change)
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 preoperation 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? 

04062014, 06:57 PM
Post: #2




RE: WP34S Rectangular/Polar (Suggested Change)
This makes sense to me. For the time being, in a limited way (modulo 2π) you can recover with the inverse function.
Marcus von Cube Wehrheim, Germany http://www.mvcsys.de http://wp34s.sf.net http://mvcsys.de/doc/basiccompare.html 

04062014, 07:01 PM
Post: #3




RE: WP34S Rectangular/Polar (Suggested Change)
If you do decide to make the change, be sure to let Walter know before he reprints the manuals.


04062014, 07:23 PM
Post: #4




RE: WP34S Rectangular/Polar (Suggested Change)
(04062014 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:? 

04062014, 07:35 PM
(This post was last modified: 04062014 08:48 PM by BarryMead.)
Post: #5




RE: WP34S Rectangular/Polar (Suggested Change)
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 twopart 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? 

04062014, 08:01 PM
(This post was last modified: 04062014 08:02 PM by orcinus.)
Post: #6




RE: WP34S Rectangular/Polar (Suggested Change)
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? 

04062014, 08:13 PM
(This post was last modified: 04062014 08:44 PM by BarryMead.)
Post: #7




RE: WP34S Rectangular/Polar (Suggested Change)
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. 

04062014, 09:18 PM
Post: #8




RE: WP34S Rectangular/Polar (Suggested Change)
Barry,
(04062014 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:) 

04062014, 09:50 PM
Post: #9




RE: WP34S Rectangular/Polar (Suggested Change)
(04062014 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. :) Marcus von Cube Wehrheim, Germany http://www.mvcsys.de http://wp34s.sf.net http://mvcsys.de/doc/basiccompare.html 

04062014, 11:37 PM
Post: #10




RE: WP34S Rectangular/Polar (Suggested Change)
(04062014 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 

04062014, 11:44 PM
Post: #11




RE: WP34S Rectangular/Polar (Suggested Change)
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 

04072014, 01:34 AM
Post: #12




RE: WP34S Rectangular/Polar (Suggested Change)
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. 

04072014, 03:18 AM
Post: #13




RE: WP34S Rectangular/Polar (Suggested Change)
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 

04072014, 03:35 AM
Post: #14




RE: WP34S Rectangular/Polar (Suggested Change)
Barry,
(04072014 01:34 AM)BarryMead Wrote: The only change I was suggesting was to change the 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. 

04072014, 03:53 AM
Post: #15




RE: WP34S Rectangular/Polar (Suggested Change)  
04072014, 05:20 AM
Post: #16




RE: WP34S Rectangular/Polar (Suggested Change)  
04072014, 09:01 AM
Post: #17




RE: WP34S Rectangular/Polar (Suggested Change)
(04072014 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: 

04072014, 09:12 AM
Post: #18




RE: WP34S Rectangular/Polar (Suggested Change)
(04072014 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 

04082014, 02:23 AM
Post: #19




RE: WP34S Rectangular/Polar (Suggested Change)
Thanks everyone!
(04062014 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 (04062014 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 

04082014, 03:39 AM
Post: #20




RE: WP34S Rectangular/Polar (Suggested Change)  
« Next Oldest  Next Newest »

User(s) browsing this thread: 1 Guest(s)