newRPL: [UPDATED April 27-2017] Firmware for testing available for download

[Han]

(10-25-2015 12:31 PM)Claudio L. Wrote:  

(10-25-2015 11:31 AM)Han Wrote:  While I think the "dot" notation is nice for immediate evaluation, it really seems to be contrary to the whole notion of RPN.

'X^2+Y' 1 + --> 'X' SQ 'Y' + 1 +
'X^2+Y.' 1 + --> 'X' SQ Y + 1 +

This is exactly right, but I fail to see why it's contrary to RPN (??).

Waxing philosophical:

You're using an algebraic expression. That's not very RPN-like in my opinion. Now, I understand that it may be easier to understand the content of a program if a formula is written algebraically rather than using RPN to build the expression. However, we can add comments with @ and comments are not removed. Or are they removed? RPL programs will never be "readable" but that's not the goal of RPL. Otherwise, you would have created a separate program compiler for newRPL like the HP50G did for "algebraic" (i.e. non-RPL) programs. An RPL program should be RPL, and include comments to make the code more readable. Anyone looking at the code will not only learn from the RPL code but also from the comments.

Claudio L. Wrote:

Quote:All you are telling the machine is that you want the value of Y replaced ASAP.
I think for instance of a quadratic solver.
You have the generic equation:
'a.*X^2+b.*X+c.' stored somewhere

Then the user defines 'a', 'b' and 'c' to his liking.
Next time you operate on that expression, all 3 values will be immediately replaced, but not X, so you can display the final equation even if X has a value. Doing EVAL would also replace the X if it has any value. This way you control what gets replaced in the expression.
Currently, you'd need to make sure X doesn't exist in current or higher directories to get the equation.

(10-25-2015 11:31 AM)Han Wrote:  But even with the feature, I am not sure it would be used as described. If I wanted immediate substitution, I imagine that I would still end up double checking the value of Y prior to having the calculator actually include it into a formula. So a quick RCL of the contents of Y would most likely occur -- and at this point I may as well just build my formula with the Y value already on the stack.

Ah, but you are thinking interactively only. The dot in the expression is most useful when executed inside a program, since the mere presence of the symbolic in the runstream would trigger the replacement. Without the dot, you'd have to break down the expression in the program so you can evaluate the different parts and then reconstruct the symbolic.

Think of my example above:
Currently:
<< a 'X^2' * b 'X' * + c + >>
Proposed:
<< 'a.*X^2+b.*X+c.' >>

They produce the same result.

In the HP48, one could type 'X.' and get an 2-character identifier whose name is X followed by a period. This would break in newRPL. I am not suggesting this feature would not be useful. However, I think that the feature can be achieved in a different way. When the command line is active, using left or right shift with a variable will insert: 'VARNAME' RCL or 'VARNAME' STO depending on the shift. I recommend that the these key combinations instead reveal what is stored in the variable (maybe a preview) using the status area at the bottom, or (via the other shift) recall the contents into the program area. Thus, the "." operation can be achieved by pressing the [VAR] key, finding the variable, previewing its contents if necessary, and inserting the content of a directly into the command line.

OR

You could optionally make the "." operation a key sequence that only works with a command line present. So the idea of immediate substitution could even happen DURING edit mode as opposed to after hitting the ENTER key. This would be even more useful because you can determine whether or not the content of the variable is in fact what you wanted (as opposed to having to go back into the program and check the code to see if it was right).

Either way, it does not break compatibility with "oldRPL" insofar as "." trailing an identifer name is concerned

EDIT: just to be clear -- I'm not opposed to the feature itself (I think it's useful) but I would rather it be implemented in a way that is compatible with old RPL code.