996
|
1
|
|
2 pi.i is easily the most twisted and obscure INTERCAL program I've yet
|
|
3 written. I say that because even I don't fully understand why it
|
|
4 works. The program writes in one number from the input, then prints
|
|
5 out that many digits of pi. There are no fancy INTERCAL tricks here;
|
|
6 all it does is simple integer arithmetic.
|
|
7
|
|
8 The algorithm used comes from an old TECO macro that was recently
|
|
9 discussed on alt.lang.teco. Mark Henderson posted a translation
|
|
10 into C, which at least made it easier to read, if not much easier to
|
|
11 understand. I played around with that program a bit, fixed a couple
|
|
12 of minor bugs which may or may not have existed in the original TECO,
|
|
13 and modified it a bit to put in into a form that would be easy to
|
|
14 translate into INTERCAL. That modified program, which corresponds
|
|
15 closely to the algorithm in pi.i, is reproduced at the end of this
|
|
16 file.
|
|
17
|
|
18 The INTERCAL version has only been tested up to a hundred digits,
|
|
19 which took almost 30 minutes on a Sparc 1. The C version below,
|
|
20 with variables declared unsigned short to correspond to the INTERCAL,
|
|
21 gives up to 535 accurate digits and then starts printing garbage,
|
|
22 presumably because of an overflow. If the declarations are changed
|
|
23 to short only the first 262 digits are accurate, while using int
|
|
24 yields thousands of accurate digits. Though I don't understand
|
|
25 what the inner loop is doing, it looks like the largest numbers
|
|
26 encountered are O(n), where n is the number of digits requested.
|
|
27 If, as I expect, the present INTERCAL version does fail after about
|
|
28 535 digits, it could easily be converted to a 32-bit form which
|
|
29 would run as long as almost anyone would desire.
|
|
30
|
|
31 The only feature likely to be of utility in other INTERCAL programs
|
|
32 is the new (2030) routine, which performs a 16-bit division with
|
|
33 remainder. It is faster than the (1040) routine for two reasons:
|
|
34 First, it is a true 16-bit version, whereas the (1040) routine just
|
|
35 shifts over its operands and then calls the 32-bit division routine
|
|
36 (1550). Second, the (1550) routine generates a remainder as part of
|
|
37 the computation, but then simply throws it away. I needed the
|
|
38 remainder, so I have my (2030) routine return it in .4 and the
|
|
39 quotient in .3. In other respects this is just a 16-bit translation
|
|
40 of the (1550) routine.
|
|
41
|
|
42 Louis Howell
|
|
43 December 30, 1991
|
|
44
|
|
45
|
|
46
|
|
47 #include <stdio.h>
|
|
48 unsigned short line[10000];
|
|
49 main(argc,argv)
|
|
50 int argc;
|
|
51 char *argv[];
|
|
52 {
|
|
53 unsigned short n, a, i, q, v, dummy, h=0, w=0;
|
|
54
|
|
55 if (argc==2)
|
|
56 n=atoi(argv[1]);
|
|
57 else
|
|
58 n=20;
|
|
59
|
|
60 n+=2;
|
|
61
|
|
62 for (i=(n*10)/3 ; i > 0 ; i--) {
|
|
63 line[i-1] = 2;
|
|
64 }
|
|
65
|
|
66 for (dummy=0; dummy < n; dummy++) {
|
|
67 q=0;
|
|
68 for (i=(n*10)/3 ; i > 0 ; i--) {
|
|
69 a = line[i-1] * 10 + (q*i);
|
|
70 q=a/(i*2-1);
|
|
71 line[i-1] = a%(i*2-1);
|
|
72 }
|
|
73 v = w;
|
|
74 w = h+(q/10);
|
|
75 h = q%10;
|
|
76 if (w==10) {
|
|
77 w=0;
|
|
78 v++;
|
|
79 }
|
|
80 if (dummy!=0)
|
|
81 printf("%d", v);
|
|
82 }
|
|
83 printf("\n");
|
|
84 }
|