HP Prime: a student's view

[Liam Hays]

This post is about my experiences so far with the Prime. It is quite long. TL;DR: nerd kid likes the Prime.

-------
I want to clarify something about myself: I'm not an adult like most people here (hopefully this means I am still allowed to post). While posting my real age is obviously an unwise choice, suffice it to say that I'm in high school, currently taking AP Calculus AB.

I've been a general math + technology nerd since I was little. I started programming at about 10 and I currently use Java, Python, and C. I've always had an affinity for calculators, and since I've been programming computers for a long time, it only follows that I like programming calcs too. My first calculator was a Casio fx-9750G PLUS, a '90s graphing calculator which is programmed in a rudimentary BASIC. Despite its shortcomings, I had a shocking amount of fun learning how to program that thing.

My history with HP calcs starts with a calculator that is almost a family heirloom (my dad grew up in Loveland, Colorado, for reference): a 50th Anniversary edition HP 32S, complete with 50th Anniversary leather case. It was the first HP I ever used or played with, and it still functions perfectly. I learned RPN and RPN programming on it. More recently, I've accumulated a 35s, a 27S, and a 48GX. Eventually I'd like to get maybe an HP-97 and a 41C.

I happened to get the 48 at the beginning of last school year, for virtual school with Algebra II. After spending some time browsing hpcalc.org, I found Java (the stack replacement, not the programming language) and ALG48, and immediately put them to use. I have no expansion cards (I would have liked to run the Meta Kernel), so memory was tight. I made my own homebrew serial cable from some parts I had lying around.

Amazing as it is, the 48 simply wasn't cutting it for me. Even with that software, I still had no replacement for things like the EquationWriter or the graphing features, both of which are features I frequently use. Java in particular likes to crash, and when that happens, I have to re-upload all the libraries that were on the calculator (it crashes so hard that memory recovery does basically nothing). Finally, the keys suffer from the poor connection issue, which makes semi-one-handed use, a risky business at best.

-------
So I've got a Prime, and I've had it for a few weeks. I've grouped my thoughts into general sections below.

------- Hardware
I really like how thin the Prime is, especially because it manages to be so thin but still feel hearty. It takes the keys that were so close to perfect (but not quite there, for a few reasons) on the HP 35s and refines them, taking out a bit of vertical travel but making the buttons underneath actually reliable. The touchscreen is precise and well-calibrated, and the rocker wheel, while being different from the other keys, fits in perfectly with the rest of the keyboard. I wish that the top part of the keyboard weren't so susceptible to attracting fingerprints, but it's not that big of a deal. At least it isn't glass like the touchscreen itself.

The keyboard has a big Enter button! It's actually quite nice to have it on the right side of the keyboard, instead of the left as I'm used to, since it's closer to the four functions, and since I'm right-handed.

The screen is bright and colorful. I expected it to look grainy, at 320x240 and 3.5", but it isn't at all. While each pixel is clearly visible to my eyes, the resolution isn't obtrusive or annoying. I found the little lines caused by the bottom-to-top refresh annoying at first, but I've gotten used to them and barely even notice them now. They seem to be most visible under florescent lighting. Finally, the screen's viewing angles are not perfect but pretty good, and I would say significant color change happens past at least 60 degrees in any direction.

The slide-on cover is pretty generic, though the metallic HP logo is nicely unique. My particular Prime is rather unstable and shaky when it's in the case, so it rocks up and down with button presses. This is annoying but not a problem, as I can just put the cover aside while I use the Prime.

------- Software
I already had a small bit of experience with the UI because I had downloaded the Lite version of the emulator to my phone and played around a bit, but there's obviously much more to get out of the real thing. In general, it is clean and has obviously been designed around the touchscreen. It takes some getting used to, but I don't see that as a problem: typically, unconventional interfaces are designed that to better interact with hardware.

I keep the home screen in RPN mode, because I like it. The RPN is simple, sort of a cross between RPL and traditional RPN. I also like using the CAS, and it's shockingly fast (unlike ALG48 or the HP 48's built-in functions) and seems to have a practically endless set of features.

On the side of the apps, the Function, Advanced Graphing, and Graph 3D apps are incredible. I'm not sure I'll ever go back to low-res, monochrome plotting ever again. Functions appear instantly instead of after many seconds, zooming and panning is easy and intuitive (pinch to zoom is wonderful), and everything is just so fast. Whereas even a simple line on the HP 48 takes ten seconds to draw, the Prime renders it as soon as the Plot button is pressed.

Advanced Graphing is just as useful as Function, usually because I'm lazy and don't want to convert general form into slope-intercept form . Graph 3D is cool, though I have no real use for it. I haven't explored the other apps very much besides the Solve app (and Python, but my thoughts on that can wait a moment). It would be nice to be able to disable some of the apps, like Triangle Solver. I like the idea of the app, but I have the geometry and trig skill to solve a triangle by myself. I also don't think I'll ever have a StreamSmart, making Data Streamer useless.

While I found the three-view (Symb, Plot, and Num) interface confusing at first, I like that it deviates from basically every other calculator in that it isn't even close to a computer-style "wizard" interface. Most calculators have the user enter an equation in a form, optionally configure something, and view the plot. With the Prime, you can choose where you want to go, end of story. I think it actually ends up being simpler than other interfaces once you understand it.

------- Programming
But first, a thought I had a while ago. RPL is fun, it is powerful, and it is versatile. It is also obsolete. It was designed for systems far less powerful than what are available today, with piddling processors and minimal memory. Modern, complete systems like the Prime shouldn't be held back by old systems simply for the sake of tradition. Instead, we should file RPL into the past, something to be admired and enjoyed, and create new, better things to replace it.

The Prime has done this, with PPL and Python. I really like the editor and the programming environment. PPL as a language is simple, and the built-in help is practically a godsend (I can even save comments in a program!). Every other calculator I've ever programmed requires you to look at the manual or command reference---often hundreds of pages, like the 48G AUR---to figure out what a function or command does, but the Prime doesn't. It is a self-contained programming box.

Python is also awesome. The Prime's features and processing speed complement it well. I've used real Python for a long time, and while MicroPython is definitely stripped down, it's still Python. Much like PPL, I like that the editor menu is full of shortcuts, and that the editor in general is identical to PPL's. However, the help appears to disregard any parts of Python: for example, try pressing the Help key with the editor cursor on the Python builtin function int(). The help dialog explains the PPL INTegral function instead.

I have numerous other comments and feature requests for Python, and I'll probably put those in a separate thread so there can be actual discussion (and so this post isn't horribly long and convoluted).

------- Sidenote
A while ago, in my usual conversation-killing way, I said some rather negative things about the Prime.

That was a statement with no evidence (well, mostly---the Prime isn't exactly highly advertised by HP) and was uncalled for. I really like this device. Yes, that makes me a member of a niche society/fanclub. It wouldn't be the first time.

------- Final Verdict
If you're an RPN/RPL purist, this calculator is not for you. If you long for the good-ol'-days of LED digits and charming magnetic card readers, this calculator is not for you. If you want your calculator to run for thirty-odd years on a single set of batteries, this calculator is not for you. However, if you want excellent versatility, math features comparable to professional software, programmability capable of doing whatever you want to do, and a calculator without arbitrary limits, the Prime is for you.

The Prime is not Kinpo junk, nor is it a rebranded dollar store calculator. It is a quality, modern, well-designed, upgradable device that doesn't require any kind of wireless connection, subscription plan, forced updates, or planned obsolescence. That is a rare sight in today's world, and I think it should be appreciated. The fact that HP released a new hardware revision only three years ago tells me that the Prime won't be discontinued in the near future. The software team remains hard at work adding new features and fixing bugs. This is an ecosystem worth joining---it will not die anytime soon.

------- Uncategorized thoughts
Feature requests

• My biggest request is an even dimmer screen brightness. The dimmest of the four is still rather bright to use in darkness or even low light.
• Returning to the PPL editor or Python symbolic mode should remember the last location (and last file in Python mode).
• Only some Python modules, mostly the ones at the top of the Cmds list, have documentation through the Help button. Other modules, particularly matplotl and graphic, would benefit from documentation.
• The editor is excellent as it stands, but it would be even cooler with syntax highlighting and matching parentheses indication, like Emacs or an IDE. This isn't a big deal for PPL, due to its simplicity, but I think Python would benefit.
  

Comments

• It's kind of weird how functions like square root and absolute value are accessible from both the math palette and shifted functions on the keyboard.
• I like how the comma key moves the cursor to the next element of a matrix in an entry line.
• Why do I have to press Edit or use the Quote shifted key to get an algebraic in a symbolic view of an app (for example, editing an unchecked equation in Function)? It seems like I should be able to just start typing and automatically get an algebraic.
• Scrolling is choppy and uneven. I'm not really bothered by this, but it's one of those things that I noticed intensely at first.
• I really like how the Quick Settings menu unfolds into a full calendar. I had to program this myself on the HP 48!
  

Questions

• What is Intelligent Math and how do I use it? It doesn't seem to be documented.
• The Python "New File" dialog has options for JPG files, PNG files, and generic binary files. How would I use those options?
• Is there a way to tell when the battery is fully charged?
• What is the rubber thing on the end of the USB cable for?
• Why is Python so fast, compared to PPL? For reference, I ran the thimet.de Performance Index in PPL and Python. PPL scored about 27,200, and Python scored a little over 490,000. That's a factor of 18 times faster in Python.
  

[TheLastMillennial]

Thanks for posting your thoughts in such detail! I think I can answer one of your concerns. To avoid the flickering, press and hold [on]+[shift] then press [+] or [-] repeatedly. That will adjust the screen refresh rate and mitigate the flickering. It will go from 55hz at the lowest to 125hz at the highest.

The only way I know to tell if the Prime is charged is to turn it on and look at the battery level. If the charging indicator is gone then it's done charging. Charging while off is a little finicky apparently. I really don't know why the rubber boot was included on the cable. My guess is to possibly relieve strain on the plug when plugged into something but that's just a guess. I haven't messed around with Python too much but that's quite interesting that program ran faster on Python than PPL.

[toml_12953]

(08-30-2021 01:11 AM)Liam Hays Wrote:  [*]Why is Python so fast, compared to PPL? For reference, I ran the thimet.de Performance Index in PPL and Python. PPL scored about 27,200, and Python scored a little over 490,000. That's a factor of 18 times faster in Python.

One HP guru told me that HPPL runs under a type of virtual machine. Python runs directly on the processor.

I ran a Python translation of the C program on that site on a TI-84 Plus CE Python and got an index of 2302.74. Not bad for a cheap school calculator.
Here's what I ran:

Code:

from math import *
from time import *
t=monotonic()
loops=1000
for i in range(0,loops):
    r0=10
    while True:
      x=r0
      x+=1
      x-=4.567E-4
      x+=70
      x-=69
      x*=7
      x/=11
      r0-=1
      if r0<=0:
        break
    x=log(x)
    x=sin(x)
    x=sqrt(x)
    x=sqrt(x)
print(x)
t=monotonic()-t
print("Index: {0:.2f}".format(34/t*loops))

[toml_12953]

(08-30-2021 01:11 AM)Liam Hays Wrote:  [*]Why is Python so fast, compared to PPL? For reference, I ran the thimet.de Performance Index in PPL and Python. PPL scored about 27,200, and Python scored a little over 490,000. That's a factor of 18 times faster in Python.
[/list]

Could you post the Python code you ran to get 490,000? I only get 17,340.68 using the code below:

Code:

from math import *
from hpprime import *
t=eval("ticks()")
loops=10000
for i in range(0,loops):
  r0=10
  while True:
    x=r0
    x+=1
    x-=4.567E-4
    x+=70
    x-=69
    x*=7
    x/=11
    r0-=1
    if r0<=0:
      break
  x=log(x)
  x=sin(x)
  x=sqrt(x)
  x=sqrt(x)
print(x)
t=(eval("ticks()")-t)/1000
print("Index: {0:.2f}".format(34/t*loops))

[Liam Hays]

TheLastMillennial Wrote:To avoid the flickering, press and hold [on]+[shift] then press [+] or [-] repeatedly. That will adjust the screen refresh rate and mitigate the flickering. It will go from 55hz at the lowest to 125hz at the highest.

Yep, that works. It looks way better, and scrolling is much smoother. On that subject, is there a table or something explaining all the [on]+key codes? The only ones I know of are [shift]+[on] together for coma mode and [on]+[symb] to warmstart (or whatever it's called on the Prime).

TheLastMillennial Wrote:If the charging indicator is gone then it's done charging.

I don't think the charging indicator on mine ever vanished. I won't check again, though, until it needs a charge, so we'll have to wait and see.

toml_12953 Wrote:I ran a Python translation of the C program on that site on a TI-84 Plus CE Python and got an index of 2302.74. Not bad for a cheap school calculator.

I'm curious, how cheap is "cheap"? $120?

toml_12953 Wrote:Could you post the Python code you ran to get 490,000?

Sure. I converted mine from the PPL version on thimet's Prime page.

Code:

from math import *
def perf_ind():
    for i in range(100000):
        for l in range(10):
            x = l
            x += 1
            x -= 4.567e-4
            x += 70
            x -= 69
            x *= 7
            x /= 11
       x = log(x)
       x = sin(x)
       x = sqrt(x)
       x = sqrt(x)

I then used a different Python file to run ticks, the function, and calculate the difference. I do the math to convert the sampled time into a performance index by hand. Importantly, my code uses just for loops and range(), so there isn't any operation to decrement a counter nor check its value. Could this be making an incorrect value?

[Didier Lachieze]

(08-30-2021 01:11 AM)Liam Hays Wrote:  Questions

• What is the rubber thing on the end of the USB cable for?
  

ESD protection.

[Thomas_Sch]

(08-30-2021 04:50 PM)toml_12953 Wrote:  

Code:

 ...
t=(eval("ticks()")-t)/1000
print("Index: {0:.2f}".format(34/t*loops))

just to understand better, where it the

Code:

34/t

coming from?
At http://thimet.de/CalcCollection/CalcPerformance.html i can't find this.

[toml_12953]

(08-31-2021 05:38 AM)Thomas_Sch Wrote:  

(08-30-2021 04:50 PM)toml_12953 Wrote:  

Code:

 ...
t=(eval("ticks()")-t)/1000
print("Index: {0:.2f}".format(34/t*loops))

just to understand better, where it the

Code:

34/t

coming from?
At http://thimet.de/CalcCollection/CalcPerformance.html i can't find this.

Measurement
The evaluation program (see below) performs 20 additions and substractions, 10 multiplications and divisions, 2 square roots, a sine and a logarithm, in total 34 operations. This is assumed to be a "representative" set of operations commonly used in a program. (In fact there are some additional substractions needed for the loop counter but those are not considered.)

The run time T of the above procedure is measured. If it is below 5 sec or so an outer loop is added to increase measurement accuracy.
The final result of the calculation should be 0.264577 provided degrees are used and log() returns the logarithm base 10.
If log() is base e then the result is 0.325915.
If log() is base e and radians are being used the result is 0.880982.
If log() is base e and the sine is replaced by exp() the result is 1.175412.

The performance index is calculated as "representative operations per second":

P = 34/T

My note: The above calculation of P is for ONE loop. You have to multiply P by the number of loops to get a figure in line with the published table.

[toml_12953]

(08-31-2021 01:30 AM)Liam Hays Wrote:  Importantly, my code uses just for loops and range(), so there isn't any operation to decrement a counter nor check its value. Could this be making an incorrect value?

Yes, it definitely is changing the value. In a benchmark, it's important to use the exact same algorithm (and identical code, if possible). Otherwise, the results are meaningless. It's like comparing apples to oranges as we say. Since Python doesn't have a GOTO command, pick one of the published programs to convert that doesn't use GOTO. That leaves out the BASIC version. The closest one I saw to Python is the C version so I used that.

Many people don't get the purpose of benchmarks and change the algorithm or add special features of their machine then boast of faster runtimes. They're not really comparing their computer to the others in the published benchmark that way.

[Albert Chan]

(08-31-2021 01:30 AM)Liam Hays Wrote:  Importantly, my code uses just for loops and range(), so there isn't any operation to decrement a counter nor check its value. Could this be making an incorrect value?

"for l in range(10)" really loop from 0 to 9

Instead, we should loop from 10 down to 1

Code:

    xs = range(10,0,-1)
    for i in range(100000):
        for x in xs:
            ...

(08-31-2021 11:10 AM)toml_12953 Wrote:  Many people don't get the purpose of benchmarks and change the algorithm or add special features of their machine then boast of faster runtimes. They're not really comparing their computer to the others in the published benchmark that way.

see How do cars fare in crash tests they're not specifically optimized for?

Quote:Any time you have a benchmark that gets taken seriously, some people will start gaming the benchmark.

[Thomas_Sch]

(08-31-2021 10:42 AM)toml_12953 Wrote:  Measurement
The evaluation program (see below) performs 20 additions and substractions, 10 multiplications and divisions, 2 square roots, a sine and a logarithm, in total 34 operations. This is assumed to be a "representative" set of operations commonly used in a program. (In fact there are some additional substractions needed for the loop counter but those are not considered.)

The run time T of the above procedure is measured. If it is below 5 sec or so an outer loop is added to increase measurement accuracy.
The final result of the calculation should be 0.264577 provided degrees are used and log() returns the logarithm base 10.
If log() is base e then the result is 0.325915.
If log() is base e and radians are being used the result is 0.880982.
If log() is base e and the sine is replaced by exp() the result is 1.175412.

The performance index is calculated as "representative operations per second": P = 34/T

My note: The above calculation of P is for ONE loop. You have to multiply P by the number of loops to get a figure in line with the published table.

Many thanks,
sorry, but I have missed this.

[Thomas_Sch]

Now I did the performance checks on my G2. Here are my programs and results.

Code:

#PYTHON perf
from math import *
from hpprime import *
lo = 100000

def perf_ind():
   for i in range(lo):
      r0 = 10
      # for l in range(10):
      while r0 > 0:
         x = r0
         x += 1
         x -= 4.567e-4
         x += 70
         x -= 69
         x *= 7
         x /= 11
         r0 -= 1
      x = log(x)
      x = sin(x)
      x = sqrt(x)
      x = sqrt(x)
   print("* x:  ",x)

print("") 
print("Python: start, lo: ",lo)
t = eval("ticks()")
perf_ind()
t = (eval("ticks()") -t) / 1000
print("* end. time: ",t)
indx = (34 / t) * lo
print("* Index: ", indx)
----------------------------------
//  HPPPL:
PerfInd(lo);
EXPORT Perf()
 BEGIN
 Local t,l0,indx,loops = 10000;
 PRINT(".");
 PRINT("HPPPL start, loops = " + loops);
 t := TICKS;
 PerfInd(loops);
 t := (TICKS -t) /1000;
 PRINT("* Time: " + t);
 indx := (34 / t)  * loops;
 PRINT("* Index: " + indx);
 PRINT("");
END;

PerfInd(l0)
BEGIN
 LOCAL i, x, r0;
 // PRINT("* start sub, loops = " +l0); 
 FOR i FROM  1 TO l0 DO
    r0 := 10; 
    WHILE (r0) > 0 DO 
         x := r0;
         x := x + 1;
         x := x - 4.567e-4;
         x := x + 70;
         x := x - 69;
         x := x * 7;
         x := x / 11;
        r0 := r0 - 1; 
       END;  // while
       x = log(x);
       x = sin(x);
       x = sqrt(x);
       x = sqrt(x);
  END;   // for
  PRINT("... x=  " + x);
END;

are these programs comparable?

my results:
- HPPPL: 22 460 (10 000 loops, 15 sec)
- Python: 529 100 (100 000 loops, 6.4 sec)

[John Keith]

(08-31-2021 11:10 AM)toml_12953 Wrote:  In a benchmark, it's important to use the exact same algorithm (and identical code, if possible). Otherwise, the results are meaningless. It's like comparing apples to oranges as we say. Since Python doesn't have a GOTO command, pick one of the published programs to convert that doesn't use GOTO. That leaves out the BASIC version. The closest one I saw to Python is the C version so I used that.

Many people don't get the purpose of benchmarks and change the algorithm or add special features of their machine then boast of faster runtimes. They're not really comparing their computer to the others in the published benchmark that way.

This is true as far as the algorithm is concerned. However I don't think it is necessary to insist on identical code. All languages have features (or misfeatures) that differentiate them from other languages. A programmer writing in a given language should use the strengths of that language to create the best possible program. To do otherwise is to unnecessarily cripple the program, which would also skew the benchmark result, albeit in the opposite direction.

[toml_12953]

(08-31-2021 03:14 PM)Thomas_Sch Wrote:  Now I did the performance checks on my G2. Here are my programs and results.

WHILE (r0) > 0 DO

Although it works the same in this particular case, in general, this isn't the same as

Code:

while True
# do something
if r0<=0:
  exit

Why? Suppose r0 =-4 when the code reaches the while statement. What will your loop do? What will mine do?

Yours isn't executed at all if r0 <=0. The example from the website and my example will execute the loop at least once.

[Thomas_Sch]

(08-31-2021 03:41 PM)toml_12953 Wrote:  Although it works the same in this particular case, in general, this isn't the same as

Code:

while True
# do something
if r0<=0:
  exit

Why? Suppose r0 =-4 when the code reaches the while statement. What will your loop do? What will mine do?

Yours isn't executed at all if r0 <=0. The example from the website and my example will execute the loop at least once.

Many thanks, this is correct.

Did you find out why your results are so different?
("I only get 17,340.68 ...")

[toml_12953]

(08-31-2021 04:06 PM)Thomas_Sch Wrote:  

(08-31-2021 03:41 PM)toml_12953 Wrote:  Although it works the same in this particular case, in general, this isn't the same as

Code:

while True
# do something
if r0<=0:
  exit

Why? Suppose r0 =-4 when the code reaches the while statement. What will your loop do? What will mine do?

Yours isn't executed at all if r0 <=0. The example from the website and my example will execute the loop at least once.

Many thanks, this is correct.

Did you find out why your results are so different?
("I only get 17,340.68 ...")

Not yet. Why don't I run your code and you run mine to see if the results agree?

[Thomas_Sch]

(08-31-2021 04:13 PM)toml_12953 Wrote:  Not yet. Why don't I run your code and you run mine to see if the results agree?

Done with your code. Result on Prime G2: 170426
I have no explanation for the difference.

[toml_12953]

(08-31-2021 03:37 PM)John Keith Wrote:  

(08-31-2021 11:10 AM)toml_12953 Wrote:  In a benchmark, it's important to use the exact same algorithm (and identical code, if possible). Otherwise, the results are meaningless. It's like comparing apples to oranges as we say. Since Python doesn't have a GOTO command, pick one of the published programs to convert that doesn't use GOTO. That leaves out the BASIC version. The closest one I saw to Python is the C version so I used that.

Many people don't get the purpose of benchmarks and change the algorithm or add special features of their machine then boast of faster runtimes. They're not really comparing their computer to the others in the published benchmark that way.

This is true as far as the algorithm is concerned. However I don't think it is necessary to insist on identical code. All languages have features (or misfeatures) that differentiate them from other languages. A programmer writing in a given language should use the strengths of that language to create the best possible program. To do otherwise is to unnecessarily cripple the program, which would also skew the benchmark result, albeit in the opposite direction.

The whole purpose of the benchmark is to compare machines running the same algorithms. If you use special features of one machine, you can't validly compare it to the others. It doesn't skew the benchmark, it gives a real comparison. Once a benchmark is published, individual programmers no longer have freedom to rewrite the programs if they want to compare their machines to the others. If their goal is to compare algorithms then that's a different story. Then they can try different features and methods to compare the algorithms but they should be run on the same machine. Again, you can't vary multiple parameters. You either have to run the same program on different machines to compare hardware or different algorithms on the same machine to compare software techniques. If you change both the machine and algorithm at the same time, the results are meaningless.

[toml_12953]

(08-31-2021 04:27 PM)Thomas_Sch Wrote:  

(08-31-2021 04:13 PM)toml_12953 Wrote:  Not yet. Why don't I run your code and you run mine to see if the results agree?

Done with your code. Result on Prime G2: 170426
I have no explanation for the difference.

And your code on my machine gives the same results as you got. As was pointed out the main difference between our programs is between for loops and manually decrementing and testing a counter.

It seems like for loops are highly optimized in the Prime's Python interpreter.

Since the benchmark manually decrements and tests r0, the conversion should, too. The first for loop is valid, however, since the original C program uses a for loop in that part of the program.

[Thomas_Sch]

(08-31-2021 05:22 PM)toml_12953 Wrote:  

(08-31-2021 04:27 PM)Thomas_Sch Wrote:  Done with your code. Result on Prime G2: 170426
I have no explanation for the difference.

And your code on my machine gives the same results as you got. As was pointed out the main difference between our programs is between for loops and manually decrementing and testing a counter.

It seems like for loops are highly optimized in the Prime's Python interpreter.

Since the benchmark manually decrements and tests r0, the conversion should, too. The first for loop is valid, however, since the original C program uses a for loop in that part of the program.

Thank you for Support and testing, very interesting findings.
From the C/C++ program at thimet.de/CalcCollection/CalcPerformance.html related to the while loop

Code:

  do {
      x=r0;
      x+=1;
      x-=4.567E-4;
      x+=70;
      x-=69;
      x*=7;
      x/=11;
      r0-=1;
    } while (r0>0);

imho there are few differences in the implementation.

@Liam Hays: Many thanks for the challenge ;-)
and your detailed review.