winio@

I was just getting my camera ready to take some photos at a formal dinner tonight, and I chose a 128Gb microSD card. Your mention of VAX takes me back. If I go further back to my days of using an Elliot/NCR 4120 or an ICL 1900 series machine, both with 32k words of memory, and respectively tapes or an 8Mb disk, then I’m back in the days of it being impossible to use DOUBLE PRECISION for all but a few named variables. It was worse with the 16k IBM 1130.The concept of a megabyte was alien, and a Gigabyte unimaginable. The idea that storage on the microSD card scale would be achievable – ever – was a pipedream. At least the word length on the 4120 and 1900 series machines was 24 bits, so 2-word standard REAL was effectively REAL6. I remember being told by Zienkiewicz (who I met at couple of times at the Institution of Civil Engineers in London) that in the early days of the numerically-integrated isoparametric finite elements, some Americans thought his results were fake as they couldn’t reproduce them using (effectively) REAL4. At Swansea Zienkiewicz’s people were running stuff on another ICL 1900 machine. Things ran brilliantly on the London Uni CDC machines with their 60-bit words. REAL8 is even better. I sometimes wonder about REAL10 or more, and what sort of calculations demand those precisions.

Ah yes, the olden-golden days of ICL 1900s, Maximop and George 3. That is what I used at Sunderland Poly. When the computer was shown to us when I started there in 1973, the operator turned up the volume control on the teletype console so we could hear the data and address bus. Seemingly they used it to tell whether a job was stuck in a loop! They also had an Elliot 803a. Times have changed. I used Real10 for the 'Whirling of Shafts' program on a PC, in the absence of Real16. It actually worked but the program is now effectively scrapped as it is not available in the new FTN95-X64.

As an aside, here is the chorus of a television program signature tune:

Oh what happened to you? Whatever happened to me? What became of the people we used to be? Tomorrow's almost over, today went by so fast It's the only thing to look forward to, the past

I'm sure you can guess the program.

I have a couple of MicroVax which I'm trying to give to a museum along with my 1980 Acorn Atom!!

Regards Ian

At least the word length on the 4120 and 1900 series machines was 24 bits...

There were some old mainframes with 36 and 48-bit words, too, on which 6-bit characters were standard. Running Fortran programs from those on a modern system will have to contend with the fact that a REAL4 or a REAL8 variable does not match an integer number of characters.

there is a Real*10 option available in 32-bit as the intel 8086 co-processor supported this resolution directly

The 80-bit float type was useful in the early days of X86/87 computing, but its use today has many drawbacks. The x87 used a floating point stack, and there were no instructions to transfer data between the FPU registers and the CPU registers. One had to first do a transfer to memory, and then transfer from memory to the target register. In doing this, it is a problem that there are no instructions to transfer ten bytes to/from any CPU register. Having to detect and process exceptions is an additional source of trouble. In summary, it may be best to forget about using REAL*10 in new code. especially when running in Win64.

I have a couple of MicroVax

In the VAX era, we might have written 'MicroVaxen' - cute?

Paul, I look forward to it.

I am not aware of any problems when using X87 extended precision under Win32. All the inherent drawbacks are handled successfully by the FTN95 compiler and are hidden from the user.

Having said that, there is no merit in using real10 when real8 will suffice and it may turn out that the user's algorithm is suspect when real*8 does not provide sufficient precision.

Paul, The text book describing the 'Transfer matrix' method specifically warns about the difficulty in calculating the determinant of the final matrix. As such, when it ran of Vax computers, it used the Real16 precision available on those systems and ran perfectly. The Real10 also gave satisfactory results. Whilst I agree that eigenvalue methods can be used which avoids the determinant problem, the solution requires the modification of the inertias with operating speed of the shaft and the ratio of excitation from propeller blades. Therefore a trial frequency stepping method has been used akin to the Holzer Frequency Table calculation. Regarding the Win32 platform, I stopped using that after the difficulty of using the file open function was found. Has this been corrected/solved? Regards Ian

I think that it would be beneficial to consider using, in place of the algorithm or routine that you are currently using, a call to one of the Lapack driver routines. Different routines are available for symmetric matrices, and for different matrix storage schemes.

Thank you for the idea. This particular part of the program was not written by me and I can no longer contact the person who created. I tried a seance but it didn't work and at my age, I will probably be able to contact him directly assuming we both end up going in the same direction. Perhaps the number of users of the program does not warrant the change required to use Lapack.

Ian

I don't know of any outstanding Win32 issuses of that nature so if you are using a recent release there should be no problems. Otherwise please remind me what the problem was and provide sample code.