Complex Lock mode for WP-34s

[Marcus von Cube]

I haven't checked your code changes. otherwise I might be able to answer the question myself: Have you checked that complex lock mode doesn't conflict with some XROM code? CPX as a command prefix might be used for some code optimization tricks or just for handling complex arguments. A safe way to deal with this is to ignore the setting when executing XROM code.

[Brad Barton]

This is a very welcome improvement in the 34s ability to manipulate complex numbers. I love that you can see both components simultaneously.

If we're voting, I prefer option 3 'Mag' and 'Angle'. Option 2 is a close runner up, and option 1 a distant 3rd.

Thanks Nigel, fantastic work!

[Nigel (UK)]

(03-20-2015 02:25 AM)BarryMead Wrote:  I discovered a discrepancy between what the actual calculator/emulator does and what the manual says it does. In the manual it says that if "Pi" (h + EEX) is pressed immediately after CPX it puts the pi value into the Imaginary part of the number. But this is not what the actual calculator/emulator does. It ALWAYS puts the pi value into the REAL part of the number and 0 (zero) in the imaginary part, irregardless of weather you just pressed CPX or not. You cannot enter (0 + i pi) unless you exit complex lock mode and put the 0 and pi values into the X and Y registers and reenter complex lock mode.

There is another related issue that I discovered, which doesn't seem to work as one would expect. If you are entering the Real part of a number (haven't pressed CPX yet) and you select from the "const" menu (h + Enter) you get a number pair that makes sense (selected constant + i 0). Also if you start with a zero number pair (press CLx) then CPX and select a constant you get a pair that makes sense (0 + i constant).

But if you attempt to make your own CUSTOM pair (1 + i Constant) by pressing 1 CPX const you still get (0 + i const) The 1 you just entered gets overwritten by a zero. I can see why this happens, the Constants are always (Constant + i 0), or (0 + i Constant), but does it need to erase the Real part when you are entering the Complex part of the pair?

I think the manual is correct so far as pi is concerned. There are two pi functions:

• (h + pi) enters the complex number (pi + i 0), overwriting any number currently being entered. This overwriting is not what I intended; pressing (h + pi) should complete any entry in progress before entering pi. I shall correct this.
• (f + pi) does what you want, and more. So:
  
  Code:
  

  
CPX f pi ENTER
  enters 0 + i pi, and
  
  Code:
  

  
4 CPX 2 f pi ENTER
  enters 4 + i 2pi.
  

You are correct about the catalogue of constants issue. At present entering a constant either simply enters it, or overwrites the number currently being entered with (const + i 0) or (0 + i const). There is a choice here:

• If a constant is entered during the entry of a number the entry should be completed first and then the constant should be pushed onto the stack.
• If a constant is entered when a number is being entered the constant should replace the part of that number (real or imaginary) currently being entered leaving the other part unchanged.
  

Either option is possible - which would you prefer? I have a slight preference for the first option but no strong feeling.

Thank you for finding these issues. The (h + pi) problem has been present for a while without me noticing it, which surprises me. I press pi many times a day, but perhaps most often at the start of a calculation.

Nigel (UK)

[BarryMead]

(03-20-2015 10:48 AM)Nigel (UK) Wrote:  I think the manual is correct so far as pi is concerned. There are two pi functions:
[*](h + pi) enters the complex number (pi + i 0), overwriting any number currently being entered. This overwriting is not what I intended; pressing (h + pi) should complete any entry in progress before entering pi. I shall correct this.
[*](f + pi) does what you want, and more.

Nigel: Thanks for clearing that up for me. I never tried the "f" shifted Pi because the Pi on the keyboard is green not yellow. I guess when I read the manual my mind auto-corrected the "f" to an "h". I thought I understood what I read, but didn't. Yes it DOES work as you describe in the manual. Sorry for my misinterpretation. On the related topic of constants, I certainly see why you implemented it the way you did. If one needs custom number pairs involving constants, they can always exit complex lock mode and enter them separately into the X and Y registers.

[Bit]

(03-19-2015 05:41 PM)Jeff O. Wrote:  

(03-18-2015 02:50 AM)Bit Wrote:  This looks like a very useful feature indeed!

Bit, you seem to be very adept at code optimization. If you have the time, willingness, and desire to do so, please take a look at the code for possible improvements in code size, to preserve library space and space for crystal and printer options. Also, the polar mode operating speed is a little sluggish for certain operations (principally on entry of a new polar value), so that could also be a candidate for optimization.

This request should in no way be interpreted as expressing dissatisfaction with Nigel's work. I checked with Nigel first, he said he would not be insulted if I asked you to take a look at the code, because as said above, you are very adept.

Thank you for your kind words. The beauty of open source development is that everyone can contribute to whatever they care most about or are most skilled at. I'll definitely have a closer look at this feature when I have the time. Right now I'm tied up with other projects, and I probably won't be able to do much until mid April earliest.

[Paul Dale]

Another way to scrape back some space would be to remove features. e.g. the statistical distributions or the matrix functions are both sizeable.

Pauli

[Jeff O.]

(03-23-2015 12:40 AM)Bit Wrote:  I'll definitely have a closer look at this feature when I have the time. Right now I'm tied up with other projects, and I probably won't be able to do much until mid April earliest.

Anything you can do, on whatever schedule is good for you, will be be much appreciated.
Jeff

[emece67]

Just upgraded my 34S to include this complex mode. Really good mod. In may case it turns the machine much more usable.

Regards.

[walter b]

(03-19-2015 09:47 PM)Brad Barton Wrote:  If we're voting, I prefer option 3 'Mag' and 'Angle'. Option 2 is a close runner up, and option 1 a distant 3rd.

What's wrong with 'r' and '[theta]'? Sorry Brad, I can't see to which post you were responding.

d:-?

[walter b]

(03-17-2015 11:36 AM)Sanjeev Visvanatha Wrote:  

(03-17-2015 07:31 AM)Paul Dale Wrote:  Thought about a 34C branch? Maybe 34i is a better name to avoid confusion (34j is just plain wrong .

I suggest 34cx.

Well, then I'd suggest 34cpx. But 34i is nice as well.

d:-)

[Nigel (UK)]

I'm sorry for my absence; other pressing matters have been engaging my attention. I'm back now!

From the comments in this thread it seems to me that the current interface and behaviour of the complex lock mode is satisfactory. Because of this I've made no substantial changes. There have been a few minor bug fixes, and a change in behaviour of the constants menu. I have changed the names displayed when entering numbers in polar form and I have tried to speed up polar display mode (which works well on the emulator but is rather slow on the calculator).

The updated patch file, calc.bin file, emulator, wp34s.op file, and documentation are available from the links at the end of the first post of this thread.

A few more details:

• Entering a constant from the constants menu (h + ENTER) now completes numeric entry before pushing the constant to the stack.
• The key sequence f + ENTER allows the entry of a constant as the real or imaginary part of a complex number. If no number is being entered, pressing f + ENTER brings up the constants menu and enters the constant as the real part of a complex number; pressing CPX then allows an imaginary part to be entered. Pressing f + ENTER and choosing a constant after CPX has been pressed enters the chosen constant as the imaginary part of the complex number currently being entered. I hope that someone finds this useful.
• "Mod:" and "Arg:" have changed to "Length:" and "Angle:", which seemed to be the most popular choice. However, what about "Amp:" and "Phase:"? This might make the electrical engineers even happier. Or how about using "r:" and "theta:" (Walter's suggestion, I think) in CPXI mode, while allowing another pair of names in CPXJ mode?
• Entering a number in polar display mode was slow on the calculator (about 1 second). The delay seems to be caused by the op_p2r function in decn.c; I don't really understand why this function is slower when called by my code than when it is called by the P->R keyboard function, but there it is. I've rewritten the op_p2r function so that it only calls the sincosTaylor function once (roughly doubling the speed) but I feel I'm missing the point of something. Am I supposed to do something to put the calculator into fast mode when calling a function like this? Any suggestions gratefully received!
  

Thanks for all the feedback and suggestions in this thread. I hope to upload the code as a separate branch of the WP-34s project once I find myself somewhere with decent internet speeds.

Nigel (UK)

[Paul Dale]

(04-12-2015 02:59 PM)Nigel (UK) Wrote:  Entering a number in polar display mode was slow on the calculator (about 1 second). The delay seems to be caused by the op_p2r function in decn.c; I don't really understand why this function is slower when called by my code than when it is called by the P->R keyboard function, but there it is. I've rewritten the op_p2r function so that it only calls the sincosTaylor function once (roughly doubling the speed) but I feel I'm missing the point of something.

Different angle units I suspect. sincosTaylor works in radians only. decNumberSin and decNumberCos honour the current unit settings. In complex mode, they are all the same since radians is always in force. Out of complex mode, you'll have possibly broken things. I coded p2r this way to save space

The performance issue is probably due to a low clock rate being used during keyboard entry. Try calling update_speed(0) first, if you are not in a program. I don't think you need to use full speed, the trigonometric functions evaluate pretty quickly and you're working at user speed here.


Pauli

[Nigel (UK)]

(04-12-2015 09:29 PM)Paul Dale Wrote:  

(04-12-2015 02:59 PM)Nigel (UK) Wrote:  Entering a number in polar display mode was slow on the calculator (about 1 second). The delay seems to be caused by the op_p2r function in decn.c; I don't really understand why this function is slower when called by my code than when it is called by the P->R keyboard function, but there it is. I've rewritten the op_p2r function so that it only calls the sincosTaylor function once (roughly doubling the speed) but I feel I'm missing the point of something.

Different angle units I suspect. sincosTaylor works in radians only. decNumberSin and decNumberCos honour the current unit settings. In complex mode, they are all the same since radians is always in force. Out of complex mode, you'll have possibly broken things. I coded p2r this way to save space

The performance issue is probably due to a low clock rate being used during keyboard entry. Try calling update_speed(0) first, if you are not in a program. I don't think you need to use full speed, the trigonometric functions evaluate pretty quickly and you're working at user speed here.

Pauli

Thanks for your reply. The angle units are ok (I've included a call to cvt_2rad before sincosTaylor) and everything seems to work properly. Still, space is definitely at a premium and if the call to update_speed works I'll return to the original code.

Nigel (UK)

[Nigel (UK)]

(04-12-2015 10:57 PM)Nigel (UK) Wrote:  

(04-12-2015 09:29 PM)Paul Dale Wrote:  The performance issue is probably due to a low clock rate being used during keyboard entry. Try calling update_speed(0) first, if you are not in a program. I don't think you need to use full speed, the trigonometric functions evaluate pretty quickly and you're working at user speed here.

Pauli

Thanks for your reply. The angle units are ok (I've included a call to cvt_2rad before sincosTaylor) and everything seems to work properly. Still, space is definitely at a premium and if the call to update_speed works I'll return to the original code.

Nigel (UK)

Works like magic! update_speed(0) does the trick perfectly. I've updated the downloadable files in the first post.

Nigel (UK)

[Jeff O.]

(04-12-2015 02:59 PM)Nigel (UK) Wrote:  I'm sorry for my absence; other pressing matters have been engaging my attention. I'm back now!

No need to apologize, glad you are are back.

(04-12-2015 02:59 PM)Nigel (UK) Wrote:  [*]"Mod:" and "Arg:" have changed to "Length:" and "Angle:", which seemed to be the most popular choice. However, what about "Amp:" and "Phase:"? This might make the electrical engineers even happier.

I cannot speak for all electrical engineers, but I work with a variety of value types in complex polar form in addition to Amperes, i.e. Volts, MVA, and impedance, so "Amp:" and "Phase:" would not fit in all cases. Better to have more universal names that apply to all types of values.

(04-12-2015 02:59 PM)Nigel (UK) Wrote:  Or how about using "r:" and "theta:" (Walter's suggestion, I think) in CPXI mode, while allowing another pair of names in CPXJ mode?

I have no objection to "Length:" and "Angle:" or to "r:" and "theta:". If you wish to implement a difference pair of component names when CPXJ mode is selected, my preference would be "Mag:" and "Angle:" since that is the way I learned it in my EE course work all those years ago. (Again not trying to speak for all EEs, just my personal preference.)

Thanks for your continued work on this, I am anxious to try the latest version.
Jeff

[Nigel (UK)]

(04-13-2015 01:55 PM)Jeff O. Wrote:  

(04-12-2015 02:59 PM)Nigel (UK) Wrote:  [*]"Mod:" and "Arg:" have changed to "Length:" and "Angle:", which seemed to be the most popular choice. However, what about "Amp:" and "Phase:"? This might make the electrical engineers even happier.

I cannot speak for all electrical engineers, but I work with a variety of value types in complex polar form in addition to Amperes, i.e. Volts, MVA, and impedance, so "Amp:" and "Phase:" would not fit in all cases. Better to have more universal names that apply to all types of values.

By "Amp:" I meant "amplitude" so this would apply to any sinusoidally varying quantity. Not so good for 2D vectors though. I'll leave things as they are for now!

Nigel (UK)

[Jeff O.]

(04-13-2015 08:31 PM)Nigel (UK) Wrote:  By "Amp:" I meant "amplitude" so this would apply to any sinusoidally varying quantity. Not so good for 2D vectors though. I'll leave things as they are for now!

Nigel (UK)

Oops, that did not even occur to me! When I see "Amp", it means "Ampere" to me. (I do actually prefer the full word over the abbreviation - after all, the unit of electric current is named in honor of André-Marie Ampère, and I'm not sure it's nice to abbreviate someone’s name.)

[walter b]

(04-14-2015 11:42 AM)Jeff O. Wrote:  Oops, that did not even occur to me! When I see "Amp", it means "Ampere" to me. (I do actually prefer the full word over the abbreviation - after all, the unit of electric current is named in honor of André-Marie Ampère, and I'm not sure it's nice to abbreviate someone’s name.)

If you look for the official abbreviation for Ampere, it's A. Period.

d:-)

[Massimo Gnerucci]

(04-14-2015 12:18 PM)walter b Wrote:  

(04-14-2015 11:42 AM)Jeff O. Wrote:  Oops, that did not even occur to me! When I see "Amp", it means "Ampere" to me. (I do actually prefer the full word over the abbreviation - after all, the unit of electric current is named in honor of André-Marie Ampère, and I'm not sure it's nice to abbreviate someone’s name.)

If you look for the official abbreviation for Ampere, it's A. Period.

d:-)

No, there's no period after the A

:D

[walter b]

(04-14-2015 01:14 PM)Massimo Gnerucci Wrote:  

(04-14-2015 12:18 PM)walter b Wrote:  If you look for the official abbreviation for Ampere, it's A. Period.

d:-)

No, there's no period after the A

Si, si
You finish sentences by blanks , don't you?

d;-)