Post Reply 
Little explorations with HP calculators (no Prime)
04-03-2017, 09:59 PM
Post: #114
RE: Little explorations with the HP calculators
(04-03-2017 06:47 PM)pier4r Wrote:  ...the part that you used as example is repeated a tiny fraction of times in the entire procedure (although you made it pretty fast). I definitely need to try to use more STREAM and operations with lists and DOSUBS. The problem is as usual, first be correct, then be correct and fast.

I agree. My example wasn't intended to be focused on performance, but rather to show some of the power of RPL's list processing. The slight bump in performance was nice, but not the reason I explored the alternate version of the function.

My own thought process defaults to an iterative approach to processing the elements of a list (as opposed to thinking about them as a single object), so I have to remind myself to look for opportunities to make good use of the list processing features of RPL. That particular procedure took a list as input, and then stored the result in the same format. So it seemed a good candidate to practice coding for lists. I usually find that forcing a list-based data model on top of something that started off as something else loses all the advantages. This was a good example of when everything was in sync, so it worked well.

(04-03-2017 06:47 PM)pier4r Wrote:  Actually the most executed part, that I suppose is pretty inefficient, is to increase the value in a list. This is executed at least 480 times for main iteration. So for 1000 iterations it is 480k times.

for the moment I have this.

Actually I may do a sequence of 0 with NDUPN, then replace (with ROLLN or something similar) the value on the stack in the wanted position, then create the list and add the new list to the given one.

I'm doubtful that would perform any better in this situation. Part of the problem here is that there's a fair amount of system overhead in dealing with the discrete elements of RPL lists, no matter how you approach it. Internally, the contents of lists are always accessed sequentially because there are no indices/offsets maintained for each discrete object. So any time you read or write an individual list element, the system has to traverse each and every element that precedes it in the list to find it's location. Making a change to a specific element requires rebuilding the entire list. In this case, you'd actually be adding yet another list traversal to each iteration of your loop (so that you could ADD it).

I know that you are still warming up to the idea of using the stack for temporary data storage within RPL programs, but it's probably one of the only UserRPL ways that you would be able to speed this up. More specifically, I'm referring to exploding the rrResList elements onto the stack before starting the inner loops, using ROLL/ROLLD to update the stack-based team values while in the loops, then ->LIST after the loops are completed before storing the new rrResList.

As it stands right now, your innermost loop recalls, explodes/rebuilds (implicitly), updates an element, and stores rrResList in each iteration. All but the update could be moved out of the inner loop by leaving the list contents on the stack while the loop executes.
Find all posts by this user
Quote this message in a reply
Post Reply 

Messages In This Thread
RE: Little explorations with the HP calculators - DavidM - 04-03-2017 09:59 PM

User(s) browsing this thread: 1 Guest(s)