▼
Posts: 1,216
Threads: 75
Joined: Jun 2011
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
▼
Posts: 248
Threads: 5
Joined: Feb 2008
[cpx]DROP is found in the X.FCN catalog: [CPX][h][X.FCN][D] gives cDROP
Posts: 3,229
Threads: 42
Joined: Jul 2006
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.
▼
Posts: 3,283
Threads: 104
Joined: Jul 2005
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. :-)
Posts: 1,216
Threads: 75
Joined: Jun 2011
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.
▼
Posts: 3,283
Threads: 104
Joined: Jul 2005
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.
▼
Posts: 1,216
Threads: 75
Joined: Jun 2011
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.
Posts: 429
Threads: 31
Joined: Jul 2011
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?
▼
Posts: 3,283
Threads: 104
Joined: Jul 2005
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.
Posts: 3,229
Threads: 42
Joined: Jul 2006
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
▼
Posts: 3,283
Threads: 104
Joined: Jul 2005
Pauli, cRCF needs to be duplicated as well.
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
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
▼
Posts: 3,283
Threads: 104
Joined: Jul 2005
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.
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
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
Posts: 3,229
Threads: 42
Joined: Jul 2006
The documentation doesn't give the keystroke sequence for complex DROP. That is an issue.
- Pauli
▼
Posts: 4,587
Threads: 105
Joined: Jul 2005
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.
▼
Posts: 255
Threads: 22
Joined: May 2011
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.)
▼
Posts: 4,587
Threads: 105
Joined: Jul 2005
Point taken. Obviously, that was too fast writing late at night ;-)
Use [^c]DROP instead 8-)
Walter
|