WOW, that's really the greatest new feature which I've seen implemented since a long time! :-)
Now if we could only have the same for input of complex numbers, i.e. switching the entry line to the top alpha display after pressing any [i] key ... ;-)
Many thanks for this great improvement,
Franz
It didn't take long for someone to notice :-) Thank Nigel Dowrick for the inspiration for this one, he provided a number of patches to the firmware and this is a slight modification of one.
There is still a rough edge to work out and (no doubt) some bugs still.
Unfortunately, we don't know how we'd implement this on input sensibly.
- Pauli
Quote:
Now if we could only have the same for input of complex numbers, i.e. switching the entry line to the top alpha display after pressing any [i] key ... ;-)
Why do you want to make simple things complicated?
d;-)
Quote:
Why do you want to make simple things complicated?
Well, I won't say that "Re [i] Im" is more complicated than "Im [ENTER] Re" - and it's definitely more 'natural'.
Franz
Well, beyond the fact that complex numbers aren't natural at all (pun intended) it's just a matter of habitude. And since we haven't got a spare key left on the WP 34S, anything will become more complicated than a straightforward ENTER. So forget [i] for this model.
d:-)
Quote:
complex numbers aren't natural at all
The same is true for irrational/real numbers, isn't it? ;-)
Quote:
And since we haven't got a spare key left on the WP 34S
We won't need an extra key for this, the existing [CPX] could be used.
If [CPX] is pressed during number input, then it could simply switch an internal state 'complex entry' and use the following digits/number as imaginary part (and maybe even display the previous real part temporarily in the alpha display).
And after the whole complex number is entered (i.e. when pressing any input-terminating key), it could just swap X and Y before executing the desired function.
You see, no so difficult at all, it's just a matter of 'desired or not?'.
Franz
Your suggestion would break something (see p. 123). And - since you asked for this statement - I don't want that. Content?
d:-I
Quote:
Your suggestion would break something (see p. 123).
123? There's only the list of printing commands.
And even if it would break something - who says that everything is optimal as it is currently?
Quote:
And - since you asked for this statement - I don't want that. Content?
No, not content at all!
Who are you compared with the vast majority here which has already requested this feature long time ago? ;-)
Franz
Edited: 5 Jan 2013, 10:16 a.m.
Quote:
Who are you compared with the vast majority here which has already requested this feature long time ago?
Most easy: I'm one of the two developers from the very beginning. And I take pride of it. Make your own calculator and your vote will count more - regardless whether there's just one loud Austrian or even really some majority.
d;-)
Quote:
loud Austrian
Well, being neighboured to Germany and only 1/10 of your population, we Austrians must be loud to be heard. :-)
Franz
Quote:
We won't need an extra key for this, the existing [CPX] could be used.
If [CPX] is pressed during number input, then it could simply switch an internal state 'complex entry' and use the following digits/number as imaginary part (and maybe even display the previous real part temporarily in the alpha display).
I agree that it wouldn't be overly difficult to implement. That isn't the point here.
This feature would break consistency pretty badly. I'm allowed to execute any function with a number in the input area -- with this change, I can no longer execute any complex function from the same position but all other functions are still available.
The only way I can see to bring consistency back would be to totally disallow function execution while a number is being entered and this will have far reaching ramifications with respect to stack lift, enter etc.
- Pauli
Did I miss something? Just updated to the latest firmware but didn't notice any changes.
Perform a complex operation. e.g. CPX +
You'll notice something then :-)
- Pauli
Quote:
This feature would break consistency pretty badly. I'm allowed to execute any function with a number in the input area -- with this change, I can no longer execute any complex function from the same position but all other functions are still available.
I don't see any inconsistency here, and here's why:
If you want to execute a complex function then you must have entered a 'full' complex number previously (i.e. entered the real and imaginary part). So when you've only entered the first (=real) part, pressing [CPX] makes no sense for calling any complex function - the only sensible usage would be switching to the input of the imaginary part.
This _first_ press of [CPX] while in input mode can then set any internal flag and just expect the imaginary part, while every _further_ pressing [CPX] would then be executing the desired function.
Quote:
The only way I can see to bring consistency back would be to totally disallow function execution while a number is being entered and this will have far reaching ramifications with respect to stack lift, enter etc.
Of course that would indeed be a very bad idea, but not necessary as I've explained above. Everything could be solved with just an additional internal status flag with the meaning '[CPX] pressed the first time while entering a number?'.
Franz
You haven't thought this suggestion through anything like enough.
- Program mode doesn't know if numeric entry is in progress or not when CPX is pressed. In fact it cannot know, consider this sequence in a program:
x=0?
1
CPX
What should CPX do here? This means we'd have to store CPX as a separate command op-code and figure out on the fly what it should do. Currently, CPX isn't stored separately in program mode, it is merged into the relevant instructions. That would have to change so it became a prefix word -- something we've none of currently and no support for. You'd likely lose the c indicator for complex commands which would make understanding programs more difficult. In fact you'd have to lose it because of beautiful sequences like this:
FC? 04
CPX
COS
- CPX digit pair would become problematic. That CPX 3 I typed doesn't always enter 0 and 3 onto the stack anymore. It depends on what came before.
- We'd need another annunicator to indicate the tri-state nature of the CPX key -- something completely new in the user interface and probably different enough to be considered an exception which is something we try really hard to avoid.
- We'd also lose the current method of inputting complex numbers which is useful at times.
I'm sure some means can be found to address some of these and I'm sure there are other issues I've not considered which will pop up -- I haven't spent much time considering the ramifications.
I'm certainly not going to be implementing this until we've discussed the pros and cons at length and we reach a consensus. We being Marcus, Walter and myself. Input will be accepted from others as always, but the final decision and responsibility is ours.
- Pauli
Quote:
You haven't thought this suggestion through anything like enough.
Of course my idea was just a first thought - only you know what and where anything has to be done to make it work correctly.
Quote:
Program mode doesn't know if numeric entry is in progress or not when CPX is pressed. In fact it cannot know, consider this sequence in a program:
x=0?
1
CPX
What should CPX do here?
I guess you mean 'entering a program' but not 'running a program' with 'program mode', correct?
Well, when entering a program there's no 'numeric entry mode' at all, each digit you enter is immediately stored as separate program step. So how should your sequence above be any problem?
Of course my idea for complex number input with "Re [CPX] Im" is only working in manual/calculator mode, not while entering a program - in a program a complex number has to be entered as it is currently.
So there's of course also no reason to make this CPX an extra op-code.
Quote:
CPX digit pair would become problematic. That CPX 3 I typed doesn't always enter 0 and 3 onto the stack anymore. It depends on what came before.
Despite of the fact that this CPX digit won't be used very often (at least IMO), it still would work exactly the way you already mentioned: it does depend on being in 'complex number input state' or not.
Quote:
We'd need another annunicator to indicate the tri-state nature of the CPX key -- something completely new in the user interface and probably different enough to be considered an exception which is something we try really hard to avoid.
Why tri-state?? CPX would use this indicator only when in input mode, and then only check if it has already been pressed or not (i.e. if it's the first time in which case it would just expect the imaginary part).
Edit: I've overlooked the 'annunciator' at the first read. Well, no extra annunciator needed - just push the previously entered real part to the alpha display when you press [CPX] to start the imaginary part entry.
But of course it's your decision, I just wanted to express my idea how such a (IMO more natural) complex number input could be realized.
Going in the background again, ;-)
Franz
Edited: 6 Jan 2013, 8:27 a.m. after one or more responses were posted
One further remark about this "tri-state nature of the CPX key -- something completely new in the user interface", which just came into my mind:
Isn't the decimal-point key [.] behaving exactly like this?
The first time you press [.] it enters a decimal point, but the next time (during the same input) it switches to 'fractional number input'.
I'd say quite similar to what I suggested for the CPX key ... ;-)
And about this:
Quote:
We'd also lose the current method of inputting complex numbers which is useful at times.
Well, a complex number could still be entered as "Re [ENTER] Im [X<>Y]".
Not very complicated. :-)
Franz
Edited: 6 Jan 2013, 8:10 a.m.
Quote:
Well, a complex number could still be entered as "Re [ENTER] Im [X<>Y]".
Warum einfach, wenn's auch kompliziert geht.
d;-)
I would assume he meant when executing a program... How would tht be handled?
Quote:
I would assume he meant when executing a program... How would tht be handled?
His code part
x=0?
1
CPX
can't be meant as program execution, because there's no CPX as stand-alone opcode.
My idea only affects the input of complex numbers but not the execution of any code.
Franz
I have just noticed there is a version 3339. For some reason I thought the 3335 was the latest. I'll give it a go when I get home.
Quote:
I have just noticed there is a version 3339. For some reason I thought the 3335 was the latest. I'll give it a go when I get home.
I guess you're still using the old SVN link, 3335 and 3339 are definitely outdated.
The new WP34s repository is at this link:
http://sourceforge.net/p/wp34s/code/
The version there is already at 3354, but I would recommend going back to 3350, because the real calc builds after 3350 have been compiled with a new compiler and seem to be buggy.
Franz
Oops, that is true. Completely forgot about the repository relocation.
Thanks for pointing that out!
I've made an attempt at fixing the bugs.
I like it, I think it is pretty close to a request that I made somewhere along the line. Glad to see it implemented. Is there or could there be a way to invoke this display mode at any time? (Temporarily, of course, exactly as if the displayed values were the result of a complex operation.) How about CPX SHOW (CPX - g - EXIT)?
Edited: 7 Jan 2013, 3:57 p.m.
Quote:
How about CPX SHOW (CPX - g - EXIT)?
Won't even require the [g] prefix, because the EXIT key has no complex function.
But a simple [x<>y] would also display the imaginary part - ok, not in such a nice way. ;-)
Franz
I predicted this would be asked for :-)
We've not come up with a way to do this. At least nothing seems better than x<>y. It is going to be hard to beat two keystrokes (x<>y to see the complex component and x<>y again to restore the stack). With x<>y you also get a proper display according to the current display mode settings -- no truncation required.
- Pauli
Edited: 7 Jan 2013, 4:55 p.m.
Quote:
We've not come up with a way to do this. At least nothing seems better than x<>y.
And what about displaying it immediately whenever the CPX key is pressed (and removing it again with any next key, also with a 2nd CPX)?
Any problems with this method?
Franz
I flashed the calculator with the latest revision now and I like it. Very nice! So now that the display limitations are overcome, how about a "real" complex stack? Something like the 42s has.
On the other hand, that is probably too much to ask, as this would probably turn everything on its head.
Cheers,
Harald
This one was mooted and things get ugly once you start pressing shift keys after CPX.
- Pauli
The display limitations aren't overcome. It is possible to get down to 3 and perhaps even 2 mantissa digits showing.
- Pauli
Quote:
This one was mooted and things get ugly once you start pressing shift keys after CPX.
I don't understand, what's the problem?
As I said, every next key (i.e. also shift/prefix keys) should just remove the alpha display again - exactly the same happens with the currently implemented imaginary alpha display after a complex operation.
Franz
Edited: 7 Jan 2013, 6:05 p.m.
Quote:
... how about a "real" complex stack? Something like the 42s has.
You won't get that with the WP 34S for various reasons, we're sorry. Please wait for the 43S.
d:-)
We won't do that. Period.
d:-)
Quote:
I predicted this would be asked for :-)
Too bad you didn't bet on it :-)
I realize that the imaginary part can be viewed by x<>y followed by another, I was just looking for a way to get that nifty display back. CPX - CHS twice should do the job with no harm if I really feel the need.
In a program you can do it "manually" with the alpha register but a cVIEW function could become handy to show progress in a program dealing with complex numbers.
Something like cVIEW X ...
d:-)
Quote:
We won't do that. Period.
Oh, a typical Walter's argumentation again - compelling and convincing as usual! ;-)
Franz
Maybe, but it seems the only way you understand. Else you repeat and repeat ... ad nauseam. So it's kind of self-defense.
d:-/
Quote:
Maybe, but it seems the only way you understand. Else you repeat and repeat ... ad nauseam. So it's kind of self-defense.
Well, I did understand
that you (or Pauli) don't want to implement it, I just wanted to understand
why you won't do it. So your reply wasn't really helpful, at least not for me.
Of course "it is as it is, point!" is always the simplest answer - especially if you don't have a real reason, but it doesn't really increase the pleasure to actively participate in improving the WP34s project.
Franz
A cVIEW command with a register argument makes sense to me.
CPX h-shift VIEW . . is five keystrokes whereas x<>y twice is two so it isn't a win there but it could be useful in a program.
- Pauli
Quote:
I said why.
All you said was "things get ugly once you start pressing shift keys after CPX", and that should be a satisfying answer???
I've explained that displaying "i..." in the alpha display after pressing CPX is exactly the same situation as displaying "i..." after any complex function (as it is in the current version). Pressing any key after this immediately removes the alpha display again - if this works (and it does work!) for complex results, then why shouldn't it work exactly the same way after just pressing the CPX key?
Sorry, but maybe I'm the only one who doesn't understand this ...
Franz
Edited: 8 Jan 2013, 7:57 a.m.
Quote:
Obviously.
Ok, then an idiot like me is obviously in the wrong place here.
Cheers,
Franz
Quote:
In a program you can do it "manually" with the alpha register...
I came up with the following long ago, but it does not handle display formatting as well as Pauli's new complex results display mode. Did you have something better in mind?
CLa
ai
aRC# Y
PROMPT
(“a” means “alpha”)
I'd use VW[alpha]+ instead of PROMPT for obvious reasons.
d:-)
The latest subversion build has a new complex VIEW command. CPX h-shift VIEW.
Let us know of any bugs or problems.
- Pauli
Seems to work fine. Thanks. From the keyboard, it takes five keystrokes, as opposed to only four for CPX - x<>y - CPX - x<>y if I really feel the need to redisplay the x and y values as a complex number. But my program to do the job is now only three steps:
LBL 16
cVIEW X
RTN
Of course the command would also be useful to view higher stack levels without disturbing the stack, e.g. cVIEW A to take a look at the the complex value in the pseudo-Z level of the pseudo-complex stack.
...
Quote:
From the keyboard, it takes five keystrokes, as opposed to only four for CPX - x<>y - CPX - x<>y if I really feel the need to redisplay the x and y values as a complex number.
Almost ;-) Just x<>y x<>y is sufficient (i.e. two keystrokes). Please see p. 31 and notice the difference between
x and
xc.
Quote:
Of course the command would also be useful to view higher stack levels without disturbing the stack, e.g. cVIEW A to take a look at the the complex value in the pseudo-Z level of the pseudo-complex stack.
Yes. As designed now,
cVIEW A will display
zc in an 8-level stack.
d:-)
Edited: 9 Jan 2013, 12:54 p.m.
I just saw that [CPX][Rv] and [CPX][R^] (also [CPX][ENTER] and [CPX][DROP]) don't show this new "i..." alpha display.
Since it works for [CPX][x<>y] and [CPX][+/-] it seems that it has been overlooked for those 4 operations!?
Franz
Edited: 12 Jan 2013, 8:00 a.m.
Quote:
I just saw that [CPX][Rv] and [CPX][R^] (also [CPX][ENTER] and [CPX][DROP]) don't show this new "i..." alpha display.
Since it works for [CPX][x<>y] and [CPX][+/-] it seems that it has been overlooked for those 4 operations!?
Thanks for reporting. I forwarded it to our SW department.
d:-)
These ones never set the complex operation flag -- so the bug has been there forever it is just more noticeable now. Also complex FILL.
Fixed now.
- Pauli