▼
Posts: 4,587
Threads: 105
Joined: Jul 2005
Ladies & gentlemen, we ask you for your opinion in the following matter:
Assume you have a complex formula like
e -z - ( z 3 - 3 ) -1
with the complex number z = x + i y in x and y. No problem with the WP 34S:
CPX ENTER
CPX h X.FCN x^3
0 ENTER 3
CPX -
CPX 1/x
CPX +/-
CPX x<>y
CPX +/-
CPX f e^x
CPX +
and there you are :-) Now the question: Shall we ...
- keep the shortcut for the complex X.FCN catalog allowing CPX X.FCN x^3 in line 2 (omitting prefix h there) or
- introduce a shortcut for short real numbers in complex calculations, replacing line 3 by CPX 3 ?
Both alternatives exclude each other for obvious reasons. See also page 26 of "the manual" for an impression of the active keyboard.
TIA for your votes.
Walter
Edited: 4 Apr 2012, 4:17 a.m.
▼
Posts: 3,283
Threads: 104
Joined: Jul 2005
Just to elaborate on this: We have currently shortcuts for all one digit numbers with zero imaginary part by pressing CPX digit. The sequence will execute (or program) the c# 00n command with the digit as its argument. The command puts 0 in Y and the argument in X so that CPX 3 is equivalent to 0 ENTER 3 in interactive mode (in program mode this will cost 2 additional steps compared to c# 003).
There is no problem with CPX 0 to CPX 2 and CPX 4 to CPX 9 but CPX 3 used to be a shortcut for the complex catalogue, saving the keystroke for the prefix h. What we are asking is the following:
Shall CPX 3 enter (3,0) as a complex number (a) or shall it open the catalogue of complex functions (b)? The former is consistent with the other CPX digit combinations, the latter saves a keystroke when executing the commands in the complex X.FCN catalogue.
At present we have 2 votes for version (a), mine and Pauli's, while Walter is in favour of version (b).
Edit: (a) is Walter's second option, (b) his first alternative.
Edited: 4 Apr 2012, 5:14 a.m. after one or more responses were posted
▼
Posts: 1,216
Threads: 75
Joined: Jun 2011
Quote:
At present we have 2 votes for version (a)
Now you have (CPX) 3 votes for (a). :-)
IMO it's absolutely inconsistent that CPX n works for all digit but not for 3.
Edited: 4 Apr 2012, 4:35 a.m.
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
Not mentioned thus far is that in making CPX 3 open the complex X.FCN catalogue, we will lose short cuts to 4 through 9. Having such a gap is silly and inconsistent and this would be the fix.
This might extend to 0 through 2 as well but might not -- don't worry about this for the purposes of this poll however. This is a future discussion.
For reference the complex X.FCN catalogue contains the following commands:
- complex cube and complex cube root
- complex AGM - limit of the arithmetic / geometric mean
- complex conjugate
- complex DROP -- drops X and Y off the stack and lowers the stack two levels
- complex ex-1 and complex ln(1+x)
- complex Fibonacci -- the analytic extension of the Fibonacci numbers to the complex plane
- complex Gudermannian function and its inverse
- complex Lambert's W function and its inverse
- complex gamma, beta, log gamma and log beta functions
- complex SIGN
- complex SINC -- sin(x) / x
- complex xth root of y
- complex (-1)x + iy
- DOT and CROSS products for two dimensional vectors.
Apart from the conjugate, these seem like they'll be relatively uncommonly used -- most are in the group of functions for which we've a real implementation and there is a natural complex extension. Anyone who uses complex numbers a lot please let us know if this assumption is incorrect.
As for the conjugate, it is never more, and will mostly be fewer, keystrokes to type x<>y +/- x<>y than to open the catalogue up and execute the conjugate function. Thus, this one isn't really a concern for calculations from the keyboard, only in some programs.
- Pauli
Posts: 850
Threads: 10
Joined: Mar 2009
Quote:
IMO it's absolutely inconsistent that CPX n works for all digit but not for 3.
I agree, therefore my vote goes to (a) too.
Posts: 27
Threads: 2
Joined: Aug 2011
Option a (which is alternative 2 above right?)
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
Yes, option a is alternative 2 :-(
- Pauli
Posts: 455
Threads: 39
Joined: Jan 2011
I would vote for (a) too. Simply because it seems more consistant.
What I do find tedious though is having to press CPX before each and every function. Maybe it would be possible to put the calculator in "complex mode" by pressing CPX CPX and inverting the function of the CPX key (kind of like caps lock)?
Cheers,
Harald
▼
Posts: 1,216
Threads: 75
Joined: Jun 2011
Quote:
What I do find tedious though is having to press CPX before each and every function. Maybe it would be possible to put the calculator in "complex mode" by pressing CPX CPX and inverting the function of the CPX key (kind of like caps lock)?
Oh my god, you must have read my mind! :-)
Posts: 3,229
Threads: 42
Joined: Jul 2006
A locking CPX key is a bad idea IMHO. When you are in complex mode you want some operations to be complex and others to not be. Think ENTER just for a start (yes I know this one can most be coded around but I'm sure it isn't the only such dual mode function).
I've suggested a press and hold CPX option to Marcus -- we'll need to think this through properly but it would allow easier access to complex functions at the expense of requiring both hands. Hold the calculator in your right hand and the CPX key with your right thumb and use your left hand for other key presses.
What we really need is a properly integrated complex type but this will have to wait for the 43S.
- Pauli
▼
Posts: 1,216
Threads: 75
Joined: Jun 2011
Quote:
I've suggested a press and hold CPX option to Marcus -- we'll need to think this through properly but it would allow easier access to complex functions at the expense of requiring both hands. Hold the calculator in your right hand and the CPX key with your right thumb and use your left hand for other key presses.
And for the emulator we'll have to use a 2nd mouse!? ;-)
I don't like this 'hold CPX' option and I'm quite sure it will not be so easy to implement (and probably break many other things again). A complex mode with on/off switching would certainly be more simple for both, to implement and to use.
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
My guess would be the press and hold will be slightly easier to implement than dealing with multiple CPX presses -- we've already got held key detection. I could be wrong of course.
I doubt either change would cause much breakage beyond the show term at least.
- Pauli
▼
Posts: 4,587
Threads: 105
Joined: Jul 2005
Just in case you've forgotten: I don't like the 'press & hold' paradigm. But maybe even a single CPX can do what Franz wants: first CPX entering 'complex mode' - second CPX leaving it (like [alpha] does for alpha mode). :-)
▼
Posts: 455
Threads: 39
Joined: Jan 2011
Quote:
But maybe even a single CPX can do what Franz wants: first CPX entering 'complex mode' - second CPX leaving it (like [alpha] does for alpha mode). :-)
Yes, or even that simple!
Posts: 455
Threads: 39
Joined: Jan 2011
Quote:
A locking CPX key is a bad idea IMHO. When you are in complex mode you want some operations to be complex and others to not be. Think ENTER just for a start (yes I know this one can most be coded around but I'm sure it isn't the only such dual mode function).
If it was done like "caps lock" you could then press CPX for that. Basically inverting the CPX key would be best in my opinion. CPX CPX could switch between inverted and non-inverted. That would result in far less keystrokes, as most of the operations are complex and only a few are real. As demonstrated by your examples.
Quote:
I've suggested a press and hold CPX option to Marcus -- we'll need to think this through properly but it would allow easier access to complex functions at the expense of requiring both hands. Hold the calculator in your right hand and the CPX key with your right thumb and use your left hand for other key presses.
(/quote]Hmm, I don't think i would want to use that. But that is only my personal preference of course.
[quote]
What we really need is a properly integrated complex type but this will have to wait for the 43S.
- Pauli
100% agreed, I would love to see that. The 42S is perfect in that respect. But I can understand this isn't really an option for the 34S. Display limitations beeing the obvious reason for that.
Cheers,
Harald
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
Quote: As demonstrated by your examples.
Look at the xrom sources for more substantial examples. Complex operations are generally interspersed with real operations and stack shuffling commands. While there are some sequences of complex operations, none are particularly long.
Typing [cmplx] in these sources is a *lot* more tedious than prefixing each with the CPX key BTW :-)
- Pauli
Posts: 3,283
Threads: 104
Joined: Jul 2005
It might be helpful at times but hurting at other times. In "complex lock" mode the digits should work as for normal digit entry, not as they do now after hitting CPX, entering the c# 00n command. As a possible alternative I may introduce a press and hold like the shift keys but this needs extra programming in the low level routines.
Posts: 3,229
Threads: 42
Joined: Jul 2006
Or more concisely (I hope):
CPX +/-
CPX f e^x
CPX RCL L
CPX h X.FCN x^3 navigating & selecting are two keystrokes
CPX 3
CPX +
CPX 1/x
CPX +
Yeah, I can't resist ;-)
There is a reason for wanting the full complex 3 here rather than using a single real value and a real operation -- the top levels of the stack break when a single value is pushed and an operation performed. X Y Z T -> 3 X Y Z -> X' Y Z Z. This has hurt in programming some internal functions :-(
- Pauli
▼
Posts: 1,216
Threads: 75
Joined: Jun 2011
Quote:
CPX +/-
CPX f e^x
CPX RCL L
CPX h X.FCN x^3
CPX 3
CPX +
CPX 1/x
CPX +
Well, seeing that many CPX prefixes, I would even vote for a complex 'mode': switching this mode on with CPX CPX and off again with a single CPX. Or any other (maybe better) on/off method.
Ok, I know, there's no bit left in RAM for such a complex mode ... ;-)
Franz
▼
Posts: 850
Threads: 10
Joined: Mar 2009
I find myself agreeing with Franz - again :-)
Posts: 4,587
Threads: 105
Joined: Jul 2005
Since my colleagues unveiled their opinions in that matter, let me do the same. Why don't I like CPX 3 entering (3 ; 0) saving a keystroke over 0 ENTER 3, and prefer CPX X.FCN saving a keystroke over CPX h X.FCN instead?
Well, we use CPX as prefix for complex operations consistently so far. CPX ENTER pushes a complex number on the stack, CPX x<>y swaps two complex numbers, CPX |x| calculates the absolute value of a complex number, CPX RCL recalls a complex number from two adjacent registers, etc. First of all, I think '0 ENTER n' is easy enough to be memorized for the cases it's needed. Second, CPX 3 entering a *real* number 3 may be misleading - it's simply not entering a complex number. So why should that carry a complex prefix? Just confusing terms ...
Walter
▼
Posts: 455
Threads: 39
Joined: Jan 2011
Quote:
I think '0 ENTER n' is easy enough to be memorized for the cases it's needed.
Agreed, still inconsisten though.
Quote: Second, CPX 3 entering a *real* number 3 may be misleading - it's simply not entering a complex number. So why should that carry a complex prefix? Just confusing terms ...
Walter
But thinking that through, it shouldn't work for ANY number. Maybe that would be the solution. That in combination with a "complex mode".
▼
Posts: 4,587
Threads: 105
Joined: Jul 2005
Quote:
But thinking that through, it shouldn't work for ANY number. Maybe that would be the solution. That in combination with a "complex mode".
Exactly. I doubt the use of 'CPX n' generally. '0 ENTER n' is sufficient.
Posts: 3,229
Threads: 42
Joined: Jul 2006
And in what way isn't 3 + 0i a complex number??
- Pauli
Posts: 1,216
Threads: 75
Joined: Jun 2011
Quote:
Well, we use CPX as prefix for complex operations consistently so far.
And exactly this would not be true anymore with your suggestion. Show me any other green function which doesn't require [h] as prefix, so why this CPX X.FCN ???
Quote:
Second, CPX 3 entering a *real* number 3 may be misleading - it's simply not entering a complex number. So why should that carry a complex prefix? Just confusing terms ...
I'd say you're VERY wrong!
Of course CPX 3 is entering a complex number (3+0i), because it puts 0 on the Y-stack (the imaginary part).
Just as all other CPX functions/operators are working, they simply manipulate 'real' numbers, but for X and Y and in a way that the result (in X and Y) can be interpreted as complex numbers.
Nevertheless I agree with Harald, I also won't really miss these CPX n shortcuts for complex integers of the type n+0i, because they are indeed VERY rarely needed.
(But that doesn't mean I would prefer CPX 3 as shortcut for CPX h X.FCN ;-))
Edited: 4 Apr 2012, 8:34 a.m.
▼
Posts: 1,216
Threads: 75
Joined: Jun 2011
Additionally to a special 'complex mode' I would even suggest a separate 'complex catalog' C.FCN, since CPX X.FCN not only contains complex functions from X.FCN, but also other complex operations from P.FCN (e.g. CPX DROP, etc.)
And there are still a few (green) key locations which could be used for this C.FCN: for example PSE or ./, are used either only in program mode or so seldom, that they would better be placed in a catalog or mode menu.
Franz
▼
Posts: 228
Threads: 7
Joined: Aug 2011
Franz,
With your suggestion of CPX working like a "caps lock", I don't think we would need a separate C.FCN catalog - just only show items in P.FCN and X.FCN that are valid in complex mode. DROP is an exception in that it is in both P.FCN and X.FCN catalog.
I think using CPX as a "mode lock" is fitting in that it is the same key that is used for the MODE catalog :-)
▼
Posts: 1,216
Threads: 75
Joined: Jun 2011
Quote:
With your suggestion of CPX working like a "caps lock", I don't think we would need a separate C.FCN catalog - just only show items in P.FCN and X.FCN that are valid in complex mode. DROP is an exception in that it is in both P.FCN and X.FCN catalog.
Well, in principle you're right, Dominic.
But the problem is that there are no complex functions in P.FCN at all, they are all put into the X.FCN catalog. Even for typical programming functions (like e.g. DROP) the complex function is in CPX X.FCN, whereas usually you find this DROP in the P.FCN menu - something that I don't like at all since a long time. And I've already mentioned this inconsistency a few times, but Walter is just keen on having all CPX functions in one catalog. :-(
Franz
Posts: 228
Threads: 7
Joined: Aug 2011
Quote:
introduce a shortcut for short real numbers in complex calculations, replacing line 3 by CPX 3 ?
I like this one - more consistent. I don't do complex math very often so consistency is important to me because I'll have forgotten how to do things.
However I also like the idea of CPX being a "mode lock", even though these two options are mutually exclusive. I know I used the complex mode on my HP-15C - never remember it being a hindrance. I guess though that with the parallel imaginary stack it was easier to do real domain calculations while in complex mode since the i register was always 0 unless you put something there with f i or f Re<->Im.
Posts: 66
Threads: 2
Joined: Aug 2007
CPX needs to do three things, and there's only one keytop. So:
CPX followed by CPX sets CPX mode, which is canceled by CPX; in CPX mode, all operations are done as if prefixed by CPX if there's a CPX version of the operation.
CPX followed by anything else executes anything else as complex; CPX mode is not entered.
CPX CPX ... gosub ... return ; subroutine is in CPX mode upon entry, can cancel it with CPX. upon return, CPX mode is restored if it was undone in the subroutine, cleared if set in the routine.
Posts: 764
Threads: 118
Joined: Aug 2007
I will go with option 1, keep things consistent.
▼
Posts: 1,216
Threads: 75
Joined: Jun 2011
Quote:
I will go with option 1, keep things consistent.
I guess you misunderstood something - just option 1 in Walters poll is the inconsistent one. ;-)
▼
Posts: 4,587
Threads: 105
Joined: Jul 2005
Franz, you may get driven out of the polling station ... ;-)
▼
Posts: 1,216
Threads: 75
Joined: Jun 2011
Quote:
Franz, you may get driven out of the polling station ... ;-)
Well, Walter, the problem with polls is that there's always a good chance that the result is not as you would like it.
So it might have been better (for you) if you had described your poll in the following way: ;-)
Quote:
Now the question: Shall we ...
1) keep the shortcut for the complex X.FCN catalog allowing CPX X.FCN
2) keep the shortcut for the complex X.FCN catalog allowing CPX X.FCN
Franz
Edited: 5 Apr 2012, 4:15 a.m.
▼
Posts: 4,587
Threads: 105
Joined: Jul 2005
Franz, I can live with the result. At least I don't insinuate the opposition doesn't understand the question.
▼
Posts: 1,216
Threads: 75
Joined: Jun 2011
Quote:
At least I don't insinuate the opposition doesn't understand the question.
No Walter, that was no insinuation, that was just an identification of a fact. ;-)
▼
Posts: 4,587
Threads: 105
Joined: Jul 2005
Quote:
No Walter, that was no insinuation, that was just an identification of a fact.
Now, Franz, that's enough. If you want to continue, please make your propaganda statements outside, at least 20m away from the polling station ;-)
Posts: 4,587
Threads: 105
Joined: Jul 2005
OK, we had eleven members participating in the poll so far. Of those, two vote in favour of alternative 1, and nine in favour of alternative 2. I modified the manual according to this result: CPX X.FCN is gone, CPX n is in. Changed and committed to SF :-)
▼
Posts: 3,283
Threads: 104
Joined: Jul 2005
If I find the time I'll add the press&hold feature of the shift keys to the CPX key without changing any other behaviour. CPX lock has been ruled out by some deeper analysis done by Pauli: It just doesn't pay off.
▼
Posts: 4,587
Threads: 105
Joined: Jul 2005
We had that press&hold-topic earlier already ad nauseam - it will exclude one-handed use - please refrain from implementing that.
▼
Posts: 1,216
Threads: 75
Joined: Jun 2011
Quote:
We had that press&hold-topic earlier already ad nauseam - it will exclude one-handed use - please refrain from implementing that.
Oh, that's one of the very rare cases where I have to agree with you. :-)
(dass ich das noch erlebe!)
For f/g/h prefixes such a 'hold function' is indeed a good idea, but not for CPX in my opinion. Otherwise the next 'hold' wish (e.g. for the -> prefix) would probably come soon ...
Posts: 3,229
Threads: 42
Joined: Jul 2006
This press and hold is entirely optional for the user and would operate just like the press and hold we already have for the other shift keys.
I just don't see what the problem is adding something that is oft requested and that has absolutely zero impact for those who choose to use their calculator one handed -- you can still prefix every complex command with CPX so the old entry model is absolutely unchanged. It isn't as if you are being forced to press and hold to access anything, it just makes life a bit easier...
- Pauli
|