FORTRAN II output integer FORMAT question

[Yifan Nie]

Hi there,

I was playing around with the FORTRAN II yesterday and this morning, I entered an example program from a manual (i forgot which one from bitsavers) to calculate the first 100 Fibonacci numbers, however if I output them in Integers like FORMAT(' FIB ', I20), the output s were not correct, if I output them in Float like FORMAT(' FIB ', F20.0), the output were correct.

My program is as follows:

C       FIBONACCI SERIES 100 TERMS

          DIMENSION FIB(100)

          FIB(1)=1.0

          FIB(2)=1.0

          K=3

5       FIB(K)=FIB(K-1)+FIB(K-2)

6       K=K+1

          IF (K-100) 5,5,10

10      DO 20 I=1,100

          WRITE(1,11) I,FIB(I)

11      FORMAT(' ITER ', I4, ' FIB ', I20)

20      CONTINUE

           END

the output were

ITER    1 FIB                 1036

 ITER    2 FIB                 1036

 ITER    3 FIB                 1044

 ITER    4 FIB                 1046

 ITER    5 FIB                 1053

 ITER    6 FIB                 1060

 ITER    7 FIB                 1062

 ITER    8 FIB                 1069

 ITER    9 FIB                 1076

 ITER   10 FIB                 1078

 ITER   11 FIB                 1085

 ITER   12 FIB                 1092

 ITER   13 FIB                 1095

 ITER   14 FIB                 1101

 ITER   15 FIB                 1108

If I change the line 11 to  FORMAT(' ITER ', I4, ' FIB ', F20.0)

the output would become float numbers with . but the values were correct

why? are the I format in the command decimal numbers?

Thanks

[Kev Ashley]

Yifan,

I'm not sure if the answer's the same for the PDP-8 Fortran as it is on my IBM 1130 Fortran: variables that start with the letters I through N are integer values by default.  All others are floating point.

You should be able to declare FIB as:

INTEGER FIB(100)

and this'll override the default naming convention.

Cheers, Kev

--
You received this message because you are subscribed to the Google Groups "PiDP-8" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-8+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/fe2b7a95-d512-46d3-9a9c-fed3fba9e2bfn%40googlegroups.com.

--

Cheers, Kev

[August Treubig]

I don’t think Fortran II supported INTEGER and FLOAT declarations.  It didnt on IBM 1620?  You are speaking Fortran IV.  

But that all was 50 years ago.  

So he may have to rely on the I, J, K variable name beginnings.

Aug

Sent from my iPad

On Dec 28, 2020, at 2:46 PM, Kev Ashley <kash...@gmail.com> wrote:



To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/CAC1%3Db%2BnJvABZnUffFoL%3DwBOiG-Gkz9HsqY-s06XPrhWDxKf06g%40mail.gmail.com.

[Steve Tockey]

OS/8 Fortran II is a really primitive compiler.

1) It does (obviously) support DIMENSION but it does not support explicit INTEGER or REAL declarations. A variable's data type is determined entirely by the first letter of the name. Variables beginning with I, J, K, L, M, and N are integer typed, all others are real typed. Explicit typing did not appear until Fortran IV. By somewhat ancient convention, YiFan should probably use DIMENSION IFIB(100) to make the array values truly INTEGER typed.

2) Fortran II REALs use a three x 12-bit word floating point format. INTEGERs use a one x 12-bit word format. If you write out any REAL typed variable in Ix format, it is simply interpreting the first one of the three 12-bit floating point words as a 12-bit integer. What YiFan is seeing printed is the floating point exponent and the top couple of bits of the floating point mantissa being interpreted as a 12-bit integer.

3) Given that OS/8 Fortran II INTEGERs are only 12 bits (signed), the range supported is only -2047 to +2047. Further, over- & under-flow are neither trapped nor reported. As soon as FIB overflows +2047 it will wrap around to a minus number. Specifically, 2047 + 2047 == -2. And you won't be told that's what happened.

The most complete description of OS/8 Fortran II is probably in "AA-H609A-TA OS8 v3d Language Reference Manual". It's available here:

http://www.bitsavers.org/pdf/dec/pdp8/os8/AA-H609A-TA_OS8_Language_Reference_Manual_Mar79.pdf

Cheers,

-- steve

[Yifan Nie]

Hi everyone,

Thanks a lot for your help. Fortran II is really very primitive, I just read the manual mentioned above. The supported int range is only -2047,+2047. So it could not properly represent a large Fibonacci number, unless I use REAL...

I now moved on to play with FOTRAN IV😂, I wanted to port some code (in F77 or F90?) back to FORTRAN IV to calculate PI digits,

its here (https://rosettacode.org/wiki/Pi#Fortran)

program pi
implicit none
integer,dimension(3350) :: vect
integer,dimension(201) :: buffer
integer :: more,karray,num,k,l,n
more = 0
vect = 2
do n = 1,201
   karray = 0
   do l = 3350,1,-1
      num = 100000*vect(l) + karray*l
      karray = num/(2*l - 1)
      vect(l) = num - karray*(2*l - 1)
   end do
   k = karray/100000
   buffer(n) = more + k
   more = karray - k*100000
end do
write (*,'(i2,"."/(1x,10i5.5))') buffer
end program pi 

I ported back as:

C       THIS PROGRAM CALCULATES THE DIGITS OF PI

C       IN FORTRAN IV

        DIMENSION(3350) IVEC

        DIMENSION(201) IBUF       

        MORE=0

        KARR=0

        NUM=0

        K=0

        L=0

        N=0

C       INIT OF IVEC

        DO 10 IM=1,3350

        IVEC(IM)=2

10      CONTINUE

C       ========CALC OF PI========

        DO 200 N=1,201

        KARR=0

        DO 150 L=3350,1,-1

        NUM = 100000 * IVEC(L) + KARR * L

        KARR = NUM/(2*L - 1)

        IVEC(L) = NUM - KARR * (2*L - 1)

150     CONTINUE

        K = KARR/100000

        IBUF(N) = MORE + K

        MORE = KARR - K * 100000

200     CONTINUE

C       WRITE OUT BUFFER

        DO 260 IM=1,201

        WRITE(4,255) IBUF(IM)

255     FORMAT(I1)

260     CONTINUE

          END

But when I do .EXE PIDIG

I got several errors:

TD  0002

TD  0003

SF  0022

SF  0031

(1) I read the manual it says that after the error code, there is the ISN, does ISN mean something about line number? So 0002 is the 2nd line (including the comments lines or not?)?

I checked the manual TD means that there was a bad type declaration, but I declared IVEC and IBUF as integer arrays (with I in front) ...

How can I correct this code to calculate the PI digits?

Thanks a lot.

Happy New Year!

Yifan

[August Treubig]

Internal Statement Number.

DIMENSION IVEC(3350)  is the correct format.   

Aug

Sent from my iPad

On Dec 28, 2020, at 7:23 PM, Yifan Nie <yifan....@gmail.com> wrote:

Hi everyone,

--
You received this message because you are subscribed to the Google Groups "PiDP-8" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-8+un...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/0a333957-1096-473a-84e2-7037d6c392ben%40googlegroups.com.

[Clem Cole]

The problem is the implicit naming rules. The default implicit typing rule is that if the first letter of the name is I, J, K, L, M, or N, then the data type is integer, otherwise it is real.   So FIB is a 'real' currently, unless you declare it as an integer.

You might try to find an old Fortran IV book to take a look at some of the original rules. [See: http://userweb.eng.gla.ac.uk/peter.smart/com/com/f77-decl.htm]

You might want to add the line:   IMPLICIT NONE

As your first card, this will turn off the implicit naming and force you to declare your variable: 

--
You received this message because you are subscribed to the Google Groups "PiDP-8" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-8+un...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/fe2b7a95-d512-46d3-9a9c-fed3fba9e2bfn%40googlegroups.com.

ᐧ

[Rick Murphy]

Neither FORTRAN II or FORTRAN IV on OS/8 support IMPLICIT.

For this question:

>But when I do .EXE PIDIG

>I got several errors:

>TD  0002

> TD  0003

> SF  0022

> SF  0031

Those are line numbers - generate a listing while compiling and use the line numbers in the listing to find the lines with the errors.

   -Rick

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/CAC20D2OXWKRQ%2BLQcgTNggEq5VA3JKJBkd5WAFuXRbh%3DAZEWgJQ%40mail.gmail.com.

--

Rick Murphy, D. Sc., CISSP-ISSAP, K1MU/4, Annandale VA USA

[Clem Cole]

On Mon, Dec 28, 2020 at 9:54 PM Rick Murphy <k1mu....@gmail.com> wrote:

Neither FORTRAN II or FORTRAN IV on OS/8 support IMPLICIT.

Thanks  (FYI: I never ran FTN on OS/8)

Clem

ᐧ

[Yifan Nie]

Thanks a lot, I really appreciate all your help.

After generating a list, I found the errors (it should be DIMENSION IVEC(3350) .... I just copied the fortran77 code) and now it could be compiled successfully.

But the result is not correct since in the original F77 code, the output was write (*,'(i2,"."/(1x,10i5.5))') buffer, it seems that it dumped the whole buffer vector (which has 201 dims) to STDOUT?

I am not familiar with fortran (neither IV nor F77) so in my code ported to IV I only output the IBUF vec dimension by dimension....but they were strange values.

I will check the algorithm and try to understand what it is doing. Thanks.

Best

Yifan  

[Yifan Nie]

Ouch, Maybe I found the problem.

It seems that the FORTRAN IV on OS/8 could not do negative increment in a DO loop (descending order)

There's an statement DO 150 L=3350,1,-1 which only iterates once at L=3350 and never decrease to 3349 3348,....etc..

I checked the manual of FORTRAN IV for pdp8 on OS8, it says that the step could be any int or real but doesn't mention anything about whether negative steps are allowed?

The PDP10 FORTRAN manual explicitly said that the step could be negative,

It's a pity! I could not use this algorithm on this PDP-8...

[Steve Tockey]

YiFan,

Yes. Page 9-8 of the OS/8 manual says the DO loop increment parameter cannot be negative. However, you can easily change the loop to count up and then compute a derived value inside the loop. I.e., since you can’t say

DO 100 I=100, 1, -1

You can instead say

DO 100 II=1,100,1

I = 101-II

[Yifan Nie]

Hi, Steve

Thanks, inside the loop is actually kind of a recurrence of involving each dimension of the array, I checked its dependency, thankfully, it was kind of order-independent,

so I did the substitution as you said , it worked. Thanks.

Now, I could calculate arbitrary digits of PI as desired, by this tiny PDP-8.

It was as slow as nostalgically expected (300 digits took around 300s. I set throttle 416K which was around the speed of a PDP-8/E)

There's another minor problem about output: This algorithm outputs digits by group of K digits, say K=3, then it will out put 3; 141; 592; 653; .....   

sometimes there will be a very small number for example 006, i want to output the leading zeros, in F90, we have the format ' I3,3' which requires it to pad the leading zeros if it was not 3 digits

but in FORTRAN IV it seems that I can only do 'I3', not 'I3.3'... How can I force the padding of leading zeros?

Thanks 

[Steve Tockey]

Hi YiFan,

Unfortunately OS/8 F4 doesn't appear to support I3.3 as an output format specification. You will have to write code to print the leading zeroes yourself. Assuming K=3 is always true then for printing NUM with leading zeros, code such as the following could do the trick:

      IF ( NUM .GE. 10 ) GOTO 500

      WRITE ( 4,550 ) NUM

      GOTO 520

500   IF ( NUM .GE. 100 ) GOTO 510

      WRITE ( 4,560 ) NUM

      GOTO 520

510   WRITE( 4,570 ) NUM

520   CONTINUE

550   FORMAT ( '+00', I1, $ )

560   FORMAT ( '+0', I2, $ )

570   FORMAT ( '+', I3, $ )

Be aware that I have not tested this so I'm not 100% sure it will work exactly this way. On the other hand, it should be fairly close. Two notes on the three FORMAT statements:

1) The leading '+' is supposed to not advance printing to the next line(s), i.e., don't add any Line Feeds. See Table 12-3 Control Characters on page 12-15 of the OS/8 Language Reference Manual.

2) The trailing $ is supposed to keep printing at the end of this line, i.e., don't add any Carriage Return. See 12.2.12 $ Descriptor on page 12-11.

I hope you'll share your code when you finally get it working (smile).

Best,

-- steve

[Yifan Nie]

HI Steve,

Thanks a lot for your help, I finished a prototyping version (in attachment)...by adapting the code from here (https://rosettacode.org/wiki/Pi#Fortran) which is based on the algorithm of Rabinowitz et al. (https://www.maa.org/sites/default/files/pdf/pubs/amm_supplements/Monthly_Reference_12.pdf).

This algorithm could also be applied in base of 1000, 10000 ...etc, in the first case it will calculate 3 digits a time (like 141 592 653...) , in the latter it will calculate 4 digits a time (1415 9265...). To accelerate why not calculating more digits in one pass of the iteration? I tried to calculate 4 digits, but the trailing digits are not accurate even for 100 digits, I assumed that there are some overflows (there will be 1000* large numbers) in the integer calculations...(> 2^23-1=8,3xx,xxx). In this FORTRAN IV though it was improved from FORTRAN II which only used 12bits (1 word) to represent an INT, this version IV used 2 words (24bits), it really should have used 3 words... So I changed it to calculate 3 digits a time.

Another limitation (due to FORTRAN IV) the index of array could not exceed 4095....😢, So in this algorithm there's a long vector to iterate over each of its dimension, the len of this vec should be FLOOR(10n/3) + 1 where n is the num of desired PI digits, this also limits the largest NDigits i could calculate at around 1215...

Certainly this algorithm may  not be the best nor the most efficient, but I just wanted to have a try, Any improvements are welcomed! And you could also come up with more clever and efficient algorithms and share in the forum.

By coding this thing, I seemed return to the 60s (20y+rs before i was born) and experienced how difficult the programmers' lives were with so many restrictions (but already better than writing in assembly language I assume😊)

Thanks again for everyone's help.

Best

Yifan

[August Treubig]

Yifan,

Not all computers from the 60s had such few bits as the pdp8.  I cut my teeth on an IBM 1620.   It is a base 10 machine.   Fortran II could have up  to 10 integer digits an 28 digits of floating point precision.  Digits not bits.   Big long numbers were easy.   Well maybe not fast.

Aug

Sent from my iPad

On Dec 29, 2020, at 11:16 PM, Yifan Nie <yifan....@gmail.com> wrote:

HI Steve,

--
You received this message because you are subscribed to the Google Groups "PiDP-8" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-8+un...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/14619516-43ca-49e0-9421-2f2b52b6a8c8n%40googlegroups.com.

<PIDIG3.FT.zip>

<Screen Shot 2020-12-29 at 11.47.56 PM.png>