New to RPL; Please critique this working sample. Thanks.

[Nick]

(09-14-2016 09:40 AM)wojtek Wrote:  

Code:

<< 0 -> m d y a

I like that technique.. that opens up a lot and cleans up the nesting.

...then stacking and evaluating the formulas.. it's a good mix, that makes sense to me. I haven't thought about RPN being faster... I'd guess the formulas would have another layer of interpretation.

I read mention that formulas could be used to improve readability, that's what started this test. I'll try it in RPN as well and compare (perhaps benchmark).

Right, Formula 'a' ->NUM was optional but as there was nothing to simplify, would it improve performance slightly in this case to reduce it or is it better practice to let the interpreter handle it later in each separate evaluation.. or it just depends (I can see that in some cases it might improve accuracy)?

Thanks.

(09-14-2016 02:12 PM)DavidM Wrote:  you are actually creating two distinctly different copies of 'y' and 'm' in your code.

It was clear that I was 'overwriting' them in some way (I had assumed it was changing the value). Knowing that two distinct objects remain will be useful to know.

Right, thinking of local variable 'scope' in those therms helps. I had to make peace with the debugger and do some trial and error to figure out why my sequenced approach wasn't working. The added flexibility of RPL makes it easy to think for a moment you might be working in a higher level language than you are.

I'll have to think more on the link. I recall in the Advanced User's Guide that locals reemerge as they were which can cause different behaviors than coming off of the stack/variables. Thank you.

(09-14-2016 09:51 PM)Philippe Wrote:  May be you are looking for compiled local variables...

I did try that but was unable to expand the scope. It may be the usage of compiled locals is still unclear to me.

Thanks @ All.