HP49-50G : test IF THEN 'Instruction1' END ≠ test 'Instruction1' IFT

[Gil]

HP49-50G
test IF THEN 'Instruction1' END ≠ test "Instruction1“ IFT

Try the following program with
\<< 5 6 <
IF
THEN 's<?s.0'
END 5 6 < 's<?s.0' IFT
\>>

With the IF.. THEN 'Instruction1' END : it works.
With the 'Instruction1' IFT : it does not work.

Of course, 5 6 < "s<?s.0" IFT works, but the quotation marks are not so nice...

Regards,
Gil Campart

[Han]

(03-27-2021 07:17 PM)Gil Wrote:  HP49-50G
test IF THEN 'Instruction1' END ≠ test "Instruction1“ IFT

Try the following program with
\<< 5 6 <
IF
THEN 's<?s.0'
END 5 6 < 's<?s.0' IFT
\>>

With the IF.. THEN 'Instruction1' END : it works.
With the 'Instruction1' IFT : it does not work.

Of course, 5 6 < "s<?s.0" IFT works, but the quotation marks are not so nice...

Regards,
Gil Campart

In the second case, you may want to use << 's<?s.0' >> if you want to place an algebraic expression on the stack. The reason is that IFT can use both programs (encapsulated with << and >>) or algebraic expressions as an operand to evaluate. Thus, what happens is that it tries to evaluate the algebraic expression as if it were a program.

[Gil]

The correct way is to use {} in that case.

So <<
5 6 < { 's<?s.0'} IFT
>> works perfectly and has a similar structure with

<< 5 6 < { SWAP} IFT >>. [/align]

[Han]

(04-06-2021 11:44 PM)Gil Wrote:  The correct way is to use {} in that case.

So <<
5 6 < { 's<?s.0'} IFT
>> works perfectly and has a similar structure with

<< 5 6 < { SWAP} IFT >>.

That depends on what you mean by "correct way." The "correct way" according to the manual would have you use << blah >> for a program that you want to evaluate or ' blah ' for a formula you want to evaluate. When a program that is already running evaluates an object delimited by << >> (or by ' ', or { }), it will push the contents with those delimiters onto the stack (including the delimiters). This is necessary if you wish for IFT to evaluate a sequence of commands rather than just branch to an atomic object.

Since you wish for IFT's evaluation to push a formula to the stack, it needs to be done within a program. Hence << 'formula-to-push' >> would be the "correct way" because it is not possible to create an algebraic object whose evaluation pushes another algebraic object in User-RPL. A program is necessary for such a goal, and typically programs are delimited by << and >>.

The allowance for the use of { } in place of << >> has to do with how User-RPL was designed to evaluate composite objects. For composite objects, it simply just treats the contents as if it were a program during evaluation. Incidentally, algebraic objects are actually stored in the exact same manner as lists and programs (they are displayed differently, though) because they too are composite objects. The evaluation simply evaluates each object in the order that they appear (internally) in the list (left-to-right). So in theory (and in practices, as you have shown) you could simply create your programs (that you wish to push to the stack) using lists.

The advanced user's manual says that the last argument of IFT is any object.

[Gil]

Thanks for this thorough, detailed answer.

Regards,
Gil

[Jonathan Busby]

(03-28-2021 04:39 AM)Han Wrote:  In the second case, you may want to use << 's<?s.0' >> if you want to place an algebraic expression on the stack. The reason is that IFT can use both programs (encapsulated with << and >>) or algebraic expressions as an operand to evaluate. Thus, what happens is that it tries to evaluate the algebraic expression as if it were a program.

Actually, symbolic objects *are* programs for all intents and purposes When a DOSYMB ... objects ... SEMI composite object is evaluated ( in User-RPL by =xEVAL which calls =COMPEVAL or directly in Sys-RPL by calling =COMPEVAL ), the elements of the symbolic are executed as if they were in a normal secondary. This is possible because although symbolic objects are displayed in infix notation, they're actually stored in-memory in RPN

Regards,

Jonathan

[Jonathan Busby]

(04-07-2021 03:02 AM)Han Wrote:  

(04-06-2021 11:44 PM)Gil Wrote:  The correct way is to use {} in that case.

So <<
5 6 < { 's<?s.0'} IFT
>> works perfectly and has a similar structure with

<< 5 6 < { SWAP} IFT >>.

That depends on what you mean by "correct way." The "correct way" according to the manual would have you use << blah >> for a program that you want to evaluate or ' blah ' for a formula you want to evaluate. When a program that is already running evaluates an object delimited by << >> (or by ' ', or { }), it will push the contents with those delimiters onto the stack (including the delimiters). This is necessary if you wish for IFT to evaluate a sequence of commands rather than just branch to an atomic object.

Since you wish for IFT's evaluation to push a formula to the stack, it needs to be done within a program. Hence << 'formula-to-push' >> would be the "correct way" because it is not possible to create an algebraic object whose evaluation pushes another algebraic object in User-RPL. A program is necessary for such a goal, and typically programs are delimited by << and >>.

The allowance for the use of { } in place of << >> has to do with how User-RPL was designed to evaluate composite objects. For composite objects, it simply just treats the contents as if it were a program during evaluation. Incidentally, algebraic objects are actually stored in the exact same manner as lists and programs (they are displayed differently, though) because they too are composite objects. The evaluation simply evaluates each object in the order that they appear (internally) in the list (left-to-right). So in theory (and in practices, as you have shown) you could simply create your programs (that you wish to push to the stack) using lists.

The advanced user's manual says that the last argument of IFT is any object.

Oops I didn't see this post by you You essentially say ( with more elaboration ) what I mentioned in my reply to your previous post

Regards,

Jonathan