without .NET

I'm pretty much a Fortran newbie and just installed it on my machine for a project. I was wondering what the effect of not using .NET with FTN95. I received some code from the AirForce and had to make some corrections to make it run. When I finally got it to run, the results didn't match the output file that was sent. I didn't make any significant changes (mostly format/spacing changes) so I don't think I've changed the way it's supposed to run.
The only other thing I can think of is that I don't have .NET installed. (I don't have admin priveleges so it'll probably be a hassle to get it installed on my machine)

Any thoughts on the effect of not having .NET?

Thanks... any help would be appreciated.

(Running XP SP2 and silverfrost FTN95)

One more thing... I think the program was originally written in FTN77

I don't use .NET, so can only speak for the advantages of raw FTN95. The ClearWin+ system is amazingly powerful for building Windows applications, but it has a steep initial learning curve, and several critical things are rather difficult to master. If you are simply building a 'console application', then FTN95 does that. Since FTN95 contains FTN77 in its entirety (other than ther obsolete non-Windows graphics), it works fine. Indeed, as a long-time user of Fortran 77, my code tends to have only one or two 'cherry-picked' things from later Fortran standards, and works fine.

If you are not getting the same answers as an earlier run using the same code, there are several explanations. One of them is that the old run used a different precision for real arithmetic than you are using. This may be a matter of changing some global settings, or more complicated and less likely, your constants need specifying in the right precision, and you need to check functions are generic (precision independent) or of the correct type. Even less likely, there can be a problem with integer sizes, including but not limited to this causing problems in Common blocks between routines.

Eddie

thanks...

They've already changed most, if not all, the constants to double precision. I'll have to double check to make sure I didn't change any of them, but I'm pretty sure I didn't.

what global settings do I need to look at? and what do you mean by '...need to check functions are generic (precision independent) or of correct type.'?

If you program (say) SIN or COS, then Fortran 90/95 etc treats them as giving the precision associated with the function argument, so that if you have

DOUBLE PRECISION A, B
B=SIN(A)

it is as though you wrote

DOUBLE PRECISION A, B
B=DSIN(A)

MIN and MAX for instance are much more rational than all that MIN, AMIN, AMIN0 stuff we had to wade through.

There are some functions (although I can't think of one right now!) where the precision is fixed.

When I went through several programs of mine converting to double precision (the infinitely more sensible REAL*8 is now 'outlawed'), I converted everything to the double precision function type, but I didn't need to - only to make sure that I have got the correct precision-independent functions. As always with Fortran, you need to read the manual, as the exceptions to the rules are ever present traps for the unwary.

FTN77/95 also has a helpful compiler switch for setting the default real kind.

This is not obvious if you have simply migrated from Fortran 77 which is why I mentioned it, but if you already knew then I didn't want to labour the point.

You sometimes need to be a bit careful with returns from user-defined functions which can be a lower precision than you think depending on how you have declared the function, so for example,

REAL FUNCTION BESSEL (A, B, C)

will send you a single precision result even if you defined A, B, and C to be double, and used the result in a formula containing double prevision variables. This would change precision (I think) if you used the compiler switch, but not if you laboriously edited your code but missed the function definition (which you could do more easily if the type was assumed from the name, e.g.

FUNCTION BESSEL (A, B, C)

in which case you could easily miss it.

You could always be getting a [u:ee7776a9fe]better[/u:ee7776a9fe] answer from your PC than from the old mainframe - Crays for example, worked to 60-bit precision, whereas a PC is sometimes working to 80-bit!

Eddie