Done and done
May. 3rd, 2010 09:47 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
altivoGary's huge project was submitted 20 minutes before the deadline, so that's done, thank goodness.
I finished the spinning guild newsletter this evening, so that's finished too.
Also found time this morning to further pursue my geekish comparison of FORTRAN implementations.
I was dissatisfied by the textbook example that calculated the value of PI by using the Monte Carlo method. So I wrote my own algorithm, using the formula to plot the perimeter of a circle centered on the X-Y axes: x2 + y2 = r2
I then used the sequential trapezoidal section method to integrate that function and find the area under the curve in the first quadrant for a circle with radius of one. Since the area of a circle is given by PI * r2, if the radius is one then the area is just PI. Multiplying the area of a quarter circle by four yields a value for PI.
The FORTRAN program was only 16 lines long. By dividing the range of X from zero to one into 1000 segments, I obtained a value of 3.1415911 for PI in less than a second on an 8-bit processor running at just 4 MHz. Then I tried the same program on the g77 compiler on Linux, and on the VMS FORTRAN on the Alpha. All produced results in less than a second. The two larger processors actually yielded a slightly less precise result of 3.1415908. (The correct rounded value should be 3.1415927. Actually, g77 may be more precise, and the slightly larger value on the 8-bit processor could be due to cumulative error.) Pressing the software for more digits turned out to be tricky. Shifting to double precision failed with the 8-bit processor due to apparent underflow in the tinier increments required, and even if the radius of the circle was increased to 10.
The Alpha and Linux FORTRANs withstood the challenge until the range was subdivided into 10 million segments at a radius of 10, yielding accuracy to ten decimal places: 3.1415926535 (I'll count that as ten, though the next digit according to Wikipedia is an 8 so the last 5 should be rounded to a 6.) There was only a slightly noticeable hesitation after pressing enter before the result appeared. So far I haven't squeezed out any more digits using this method, as once again I'm encountering underflows when infinitesimal values are squared.
For reference, PI to 15 decimal places is 3.141592653589793
I finished the spinning guild newsletter this evening, so that's finished too.
Also found time this morning to further pursue my geekish comparison of FORTRAN implementations.
I was dissatisfied by the textbook example that calculated the value of PI by using the Monte Carlo method. So I wrote my own algorithm, using the formula to plot the perimeter of a circle centered on the X-Y axes: x2 + y2 = r2
I then used the sequential trapezoidal section method to integrate that function and find the area under the curve in the first quadrant for a circle with radius of one. Since the area of a circle is given by PI * r2, if the radius is one then the area is just PI. Multiplying the area of a quarter circle by four yields a value for PI.
The FORTRAN program was only 16 lines long. By dividing the range of X from zero to one into 1000 segments, I obtained a value of 3.1415911 for PI in less than a second on an 8-bit processor running at just 4 MHz. Then I tried the same program on the g77 compiler on Linux, and on the VMS FORTRAN on the Alpha. All produced results in less than a second. The two larger processors actually yielded a slightly less precise result of 3.1415908. (The correct rounded value should be 3.1415927. Actually, g77 may be more precise, and the slightly larger value on the 8-bit processor could be due to cumulative error.) Pressing the software for more digits turned out to be tricky. Shifting to double precision failed with the 8-bit processor due to apparent underflow in the tinier increments required, and even if the radius of the circle was increased to 10.
The Alpha and Linux FORTRANs withstood the challenge until the range was subdivided into 10 million segments at a radius of 10, yielding accuracy to ten decimal places: 3.1415926535 (I'll count that as ten, though the next digit according to Wikipedia is an 8 so the last 5 should be rounded to a 6.) There was only a slightly noticeable hesitation after pressing enter before the result appeared. So far I haven't squeezed out any more digits using this method, as once again I'm encountering underflows when infinitesimal values are squared.
For reference, PI to 15 decimal places is 3.141592653589793
