How much has RPN/RPL spoiled you?

[Dave Britten]

(06-05-2015 11:54 PM)Thomas Klemm Wrote:  But we can split the calculation into three tasks:

• TRANSFORM ( a b c -- p q )
• DISCRIMINANT ( p q -- D )
• PLUSMINUS ( p D -- x₁ x₂ )
  

Code:

%%HP: T(3)A(R)F(.);
DIR
  SOLVE \<<
        TRANSFORM
        DISCRIMINANT
        PLUSMINUS
  \>>
  UNROT \<<
        ROT ROT
  \>>
  TRANSFORM \<<
        UNROT OVER / -2 /
        UNROT /
  \>>
  DISCRIMINANT \<<
        OVER SQ SWAP - \v/
  \>>
  PLUSMINUS \<<
        DUP2 -
        UNROT +
  \>>
END

This also allows to test each of them individually.

That's the kind of approach I try to take on the 48, and to some extent on RPN models where appropriate/feasible, e.g. I made programs called XMIN, XMAX, etc, rather than opaque blobs of code pulling things out of PPAR.

(06-05-2015 11:54 PM)Thomas Klemm Wrote:  Whether your code is maintainable has little to do with the programming language you use.
It is more related to how the code is organized.
Using subroutines or local variables is a way to give meaningful names. This helps to understand and thus maintain the code.

Cheers
Thomas

When the language lacks meaningful whitespace and inline comments, and functions can be getting their arguments from heaven knows where previously in the code, I wouldn't put all of the blame on the user.

Something like this lends itself even better to easy understanding: (\@ = weird TI-89 comment symbol)

Code:

quadrdce(a,b,c)
Func
\@Reduced quadratic equation:
\@x^2-2px+q=0
Local p,q,d
b/(-2*a)\->p
c/a\->q
\SQRT(p^2-q)\->d
Return {p+d,p-d}
EndFunc

So even though the 89 is really obnoxious to use as a number cruncher, it does offer a nice programming environment. The Prime has similar paradigms from the little that I've seen.