-> I'm a little leery of altering my test conditions (consisting of  
-> saving your message to a test area, moving into a CMD window,  
-> invoking qbasic to read the message and edit out all plain text,  
-> insert 2 timing lines [a$=time$ & ?a$,time$] and then running]  
-> from my original process.... 
 
-> Expecially when this version now runs from 0 to 10000 
-> in >>> 3 <<<< seconds ! 
 
-> Well done - speed and style prevail. 
 
-> :-)) 
  
Triumph! 
  
For test purposes, I have been using a truly ancient computer - a 386 
with no math co-processor. It's something like ten times slower than 
the machine you're using. The very latest version of the program (the 
one you just tested) runs from 0 to 10000 in 39 seconds on this 
machine. The previous version took 40.2 seconds. So the 
most-significant digit flipped from a 4 to a 3 on both your machine and 
my old one. 
  
This latest improvement came just by changing the way in which the 
number C is calculated. Instead of C=(E*E+D*D)\2, I realized I could 
write just C=D*D+A (or D*D+B in the other case). This little bit of 
streamlining saved more than a second! 
  
This is equivalent to one of Jasen's empirical observations a while 
ago, when he noticed that the difference between the hypotenuse and 
the "even" side is always a perfect square. It falls out of the math, 
now that I understand the problem. 
  
The best improvement I've made recently came when I figured out an 
efficient way to calculate the loop limits (Q and R in the latest 
version). In earlier versions, a complicated expression including 
floating-point arithmetic and a SQR was done for each value of A. Now, 
in the vast majority of cases, all that's done is a simple comparison 
of two integers. Only when Q or R needs to be incremented is anything 
else done, and even that is fairly simple. This change saved about 
seven seconds on my old clunker! 
  
Fun stuff.... 
  
                             dow 
--- Platinum Xpress/Win/WINServer v3.0pr5