HP Forums

Full Version: WP34S: cpx DROP & CLx ?
You're currently viewing a stripped down version of our content. View the full version with proper formatting.

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

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

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.

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

- Pauli

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. :-)

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.

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.

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?

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.

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.

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

Pauli, cRCF needs to be duplicated as well.

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

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.

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.

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.)

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

Use [^c]DROP instead 8-)

Walter

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