Threaded Mode | Linear Mode

brianddk · 05-10-2016, 09:22 PM

(05-10-2016 08:43 PM)Dieter Wrote: If you want a fast RPN calculator, get resp. make yourself a WP34s. It's also in a class of its own in terms of precision, accuracy and its huge function set.

Huh... I thought the WP34s was original HW, just with new FW. If this isn't the case what original HW does it use? Just the keyboard and the case? Regardless, a sight better than the cost of the DM41L

(05-10-2016 08:43 PM)Dieter Wrote: Well, a "4" or "4.0" does not store the value of this number, it stores exactly what you typed. On an HP41 each character takes one byte, so 4.0 uses three bytes and -3.5E-17 requires eight.

Great tips... I'll look at replacing 1000000 with 1e6 or 6,10^x

(05-10-2016 08:43 PM)Dieter Wrote: The 35s is somewhat different. Numeric constants can take up to 37 bytes, and they noticeably slow down the calculator. That's why I try to avoid this kind of constants in my 35s programs, e.g. by prestoring 1 and 2 in two registers as the program initializes (which also has the advantage of RCL-arithmetics: instead of "1 +" or "2 x" you can use RCL+A resp. RCLxB, which is much faster and requires less memory). Even replacing a simple 1 by "π SGN", a 2 by "e IP" or a 3 by "π IP" usually is a good idea.

More food for thought. I could have my 'compiler' find all constants and create a block of STO commands then replace all references with the appropriate RCL cmd. Costs size, but might gain speed in loops.

(05-10-2016 08:43 PM)Dieter Wrote: While we're at it: why did you use 10 and y^x several times instead of the faster and shorter 10^x command?

I had originally intended this to be just a 35s app, but when I looked at the final version I decided that some degree of testing and debugging would be required. Not wanting to steal my son's calculator (and the awkward discussion that would follow about Daddy's important work writing an 8bit game for it), I decided to use the 42s emulator instead. Once there, 41cx was a short leap.

Anyway, I soon found out that 42s and 41cx don't have simple hex mode selectors like 35s does, so I went with decimal. This makes you more susceptible to the overflow bug, but I'm working on code for that as well.