Post Reply 
Little explorations with HP calculators (no Prime)
03-31-2017, 06:34 PM
Post: #91
RE: Little explorations with the HP calculators
(03-31-2017 05:27 PM)pier4r Wrote:  First and foremost I steal your timeit program, I did not think about it. Pretty neat.

Well, it's not really much of a program. Since it appears that you are possibly using Debug4x for some of your explorations, you should note that the results of TEVAL on the emulated 50g in that environment aren't what you would expect if you are running with "authentic calculator speed" turned off. Relative timings should give you an idea how different algorithms might compare, but the actual reported timings aren't real in that case.

(03-31-2017 05:27 PM)pier4r Wrote:  Fourth, for the optimizations. Yes I used SEQ syntax as seen in a couple of examples over the internet, I may do a program to replace that just with a FOR, at the end I need a list though. Or maybe as you suggested: stack duplicates, number, \->LIST.

It really depends on the specifics as to how big an impact this can have on performance. It's just something to keep in mind, especially for loops which have a high count.

Also worth mentioning, based on looking at your code: there's a definite loop structure in RPL that can be used when you don't need the counter's value for a computation: START ... NEXT/STEP. Take a look at that in the reference manuals.

(03-31-2017 05:27 PM)pier4r Wrote:  About the algebraics. ... In general I tend to avoid direct stack operations unless they are very small, otherwise I need to put long comments in the code to remember myself how the operations will work. ... So I suppose there is room for improvements but not if I want to stick with certain principles for code readability and maintainability. ... Sure I know I lose quite a lot of speed. I would say that even when I fix the bug that your report showed me, I cannot wait 2 weeks for a result of just one tournament format, when I have to test 4 of them.

Believe me, I hear you. I share your views on the importance (and value) of code readability, and I generally feel that this issue is far too often neglected in these discussions at the expense of code compactness. Both are important, of course, but they sometimes work against each other and trade-offs have to be considered. Code size is easily measured and is thus objective. Readability, however, is often subjective and dependent on an individual's preferred coding style. This makes it all the more difficult to reach a consensus about readability assessments.

Similar to code size, performance is usually easily measured. In this particular case it seems apparent that performance is unacceptable with the current coding methods. While harder to read and edit, the stack-based operations will almost always perform better. This would seem to dictate that recoding at least parts of your application will be required to achieve reasonable results.

(03-31-2017 05:27 PM)pier4r Wrote:  Ok I killed the execution on the 50g. It had done 74 iterations completely, in 42h and 42m. So an average of 34 minutes per iteration on my side.

That's longer than I experienced, and I'd guess that you are probably running your 50g in exact mode as opposed to approximate. Mine was set to approximate when I ran the test. That could explain the difference. If the lists are growing over each iteration, that could also slow things down. I haven't looked at the code closely enough to see if that is that case, though.
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 - 03-31-2017 06:34 PM



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