WP34S: cpx DROP & CLx ?



#2

While developing my TVM program I came across 2 problems:

I wanted to use [cpx]DROP and [cpx]CLx but couldn't do it.

What's the right way to get a [cpx]DROP ? After [cpx] I opened the menu [h]P.FCN and selected DROP, but the [cpx] wasn't accepted.

Then I just tried [cpx][<-] but the left-arrow just canceled the [cpx] again. So how to do it?

And with [cpx]CLx there's also a problem: [cpx][h][<-] doesn't work too for the same reason - the left-arrow key cancels also this attempt.

BTW, I've now looked in the opcode-table and saw that there is no [cpx]CLx at all!? But the token CLx appears twice, with opcode 0x0001 and 0x0140. Is this a bug?

Franz


#3

[cpx]DROP is found in the X.FCN catalog: [CPX][h][X.FCN][D] gives cDROP

#4

Quote:
What's the right way to get a [cpx]DROP ?

Complex DROP is in the complex X.FCN catalogue. I've had this argument with Walter several times and splitting functions between the complex X.FCN and the P.FCN catalogues is inconsistent to my mind. Having a complex function not in the complex X.FCN catalgoue is inconsistent to Walter.

Anyway, every complex function not on the keyboard is in the complex X.FCN. Or should be.

Quote:
And with [cpx]CLx there's also a problem: [cpx][h][<-] doesn't work too for the same reason - the left-arrow key cancels also this attempt.

Complex CLx makes no sense as a command.

Quote:
BTW, I've now looked in the opcode-table and saw that there is no [cpx]CLx at all!? But the token CLx appears twice, with opcode 0x0001 and 0x0140. Is this a bug?

No.

- Pauli

Edited: 4 Aug 2011, 6:38 a.m.


#5

Quote:
Anyway, every complex function not on the keyboard is in the complex X.FCN. Or should be.

There is a shorthand to get to the complex X.FCN. Just CPX and [V] are needed, the green shift is optional. :-)
#6

Quote:
Complex DROP is in the complex X.FCN catalogue. I've had this argument with Walter several times and splitting functions between the complex X.FCN and the P.FCN catalogues is inconsistent to my mind. Having a complex function not in the complex X.FCN catalgoue is inconsistent to Walter.

DROP in P.FCN and cpxDROP in X.FCN ???

That's indeed more than inconsistent!

And BTW: DROP is not a function but a command (or an operation).
Quote:
Complex CLx makes no sense as a command.

Well, that's a matter of opinion.
If almost all other stack operations have a CPX counterpart, it would just be consistent if CLx would have, too (deleting X and Y registers at once).

Edited: 4 Aug 2011, 6:53 a.m.


#7

Quote:
Well, that's a matter of opinion. If almost all other stack operations have a CPX counterpart, it would just be consistent if CLx would have, too (deleting X and Y registers at once).

We once had it but the problem is what to do with stack lift here. CLx disables stack lift such as ENTER^ does. But we cannot disable stack lift for two entries as would be needed if you wanted to replace X and Y after the cCLx. The equivalent of CLx for complex numbers would be cDROP in this case. I admit it is a bit tricky to replace X & Y with zero each but it can be done with CLx; ENTER^ if you don't care about the rest of the stack or with CLx; STO Y.

Edited: 4 Aug 2011, 7:17 a.m.


#8

Quote:
I admit it is a bit tricky to replace X & Y with zero each but it can be done with CLx; ENTER^ if you don't care about the rest of the stack or with CLx; STO Y.

Yes I know, every CPX stack manipulation can be emulated by a few 'normal' operations (with more or less effort), and this missing [cpx]CLx isn't really a big problem. It's just so that after I saw this CPx twice in the opcode-table, I thought you might have just overlooked to tag one of them with the [cpx] property.
#9

Quote:
splitting functions between the complex X.FCN and the P.FCN catalogues is inconsistent to my mind. Having a complex function not in the complex X.FCN catalgoue is inconsistent to Walter.

Can't you just put it in X.FCN and P.FCN as well? Or would that take too much memory?


#10

That's certainly possible. If we do it, cRCF (RCL from flash) and cDROP will both be duplicated. The rest in CPX X.FCN are math functions which only belong there.

#11

The most likely outcome is that complex drop stays in the *complex* x.fcn catalogue and drop will appear in both the x.fcn and p.fcn catalogues. This way we maintain consistency both ways -- all complex operations are in the complex x.fcn catalogue and their counterparts are in the x.fcn. The p.fcn copy is for utility only.

Still, I'm waiting for Walter to chime in -- he's been very busy with a new job recently and is far less responsive than previously.


- Pauli


#12

Pauli, cRCF needs to be duplicated as well.


#13

Nope.

All complex functions are in the complex X.FCN catalogue. They do not and shall not be duplicated. Walter will back me up here since we discussed this one just yesterday!


- Pauli


#14

Sorry, I misunderstood you. You aren't duplicating cDROP but DROP. But then the same question arises for cRCF versus RCF. The latter two are I/O commands which belong entirely into P.FCN. Solving all consistency problems looks like solving the Gordian nod to me.


#15

Quote:
Solving all consistency problems looks like solving the Gordian nod to me.

Yes :-( Just like pleasing everyone :-)

But we try to keep things sane nonetheless.


- Pauli

#16

The documentation doesn't give the keystroke sequence for complex DROP. That is an issue.

- Pauli


#17

You're right. The manual is corrected now but not committed yet :-)

And you're right again: Every complex operation not accessible on the keyboard directly is found in [CPX][X.FCN]. Thus that's the place to find [^c]DROP as well 8-)

Some background: Sorting items in catalogs is not trivial, since ASCII has some very special order for whatever historical reason. So we had to define our own sorting sequence. By no means, however, you'll get e.g. [^c]DROP following DROP directly in a sorted list.

And finally, [CPX][CLx] doesn't give any return on invest. You'll reach the same result via [CLx][CLx] with the same number of keystrokes.

Walter

Edited: 4 Aug 2011, 5:12 p.m.


#18

Quote:
And finally, [CPX][CLx] doesn't give any return on invest. You'll reach the same result via [CLx][CLx] with the same number of keystrokes.

Are you sure about that? I think if I punch [CLx][CLx], the second [CLx] is redundant since the stack did not drop. (At least that is the way my SVN 1356 works -- and my 11C.)


#19

Point taken. Obviously, that was too fast writing late at night ;-)

Use [^c]DROP instead 8-)

Walter


Possibly Related Threads...
Thread Author Replies Views Last Post
  [WP34S] WP34S firmware on the AT91SAM7L-STK dev kit? jerome ibanes 1 404 10-04-2012, 04:59 PM
Last Post: Paul Dale
  [WP34S] Entry? <-CLX Christopher Johnson 3 504 09-14-2012, 01:52 PM
Last Post: Walter B
  [wp34s] Incomplete Gamma on the wp34s Les Wright 18 1,528 12-06-2011, 11:07 AM
Last Post: Namir
  [wp34s] Romberg Integration on the wp34s Les Wright 2 512 12-04-2011, 10:49 PM
Last Post: Les Wright
  Samson price drop Ethan Conner 1 288 09-02-2011, 11:22 AM
Last Post: Thomas Radtke
  34S - Problem With CLx Jake Schwartz 6 629 07-17-2011, 02:45 AM
Last Post: Paul Dale
  Op-Amp Gain and Offset Design for the HP-67 Stefan Vorkoetter 6 677 12-05-2008, 10:57 AM
Last Post: Tom Mathes
  HP35s price drop on HP Web site Jon S Canale 8 754 04-08-2008, 06:40 PM
Last Post: Walter B
  AMP Rom for 71b PeterP 5 629 12-06-2007, 02:20 PM
Last Post: PeterP
  rpn stack drop K. Stefan Jansson (IL, USA) 38 2,558 06-18-2007, 01:09 PM
Last Post: Bob Wang

Forum Jump: