 |
forums.silverfrost.com
Welcome to the Silverfrost forums
|
| View previous topic :: View next topic |
| Author |
Message |
tarley33
Joined: 06 Jan 2009
Posts: 3
|
 Posted: Fri Jan 09, 2009 4:06 pm Post subject: 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) |
|
| Back to top |
|
 |
tarley33
Joined: 06 Jan 2009
Posts: 3
|
| Posted: Fri Jan 09, 2009 4:31 pm Post subject: |
|
|
| One more thing... I think the program was originally written in FTN77 |
|
| Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005
Posts: 2402
Location: Yateley, Hants, UK
|
| Posted: Fri Jan 09, 2009 5:32 pm Post subject: |
|
|
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 |
|
| Back to top |
|
|
tarley33
Joined: 06 Jan 2009
Posts: 3
|
| Posted: Fri Jan 09, 2009 5:38 pm Post subject: |
|
|
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."? |
|
| Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005
Posts: 2402
Location: Yateley, Hants, UK
|
| Posted: Sat Jan 10, 2009 12:57 pm Post subject: |
|
|
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
| Code: | DOUBLE PRECISION A, B
B=SIN(A) |
it is as though you wrote
| Code: | 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,
| Code: | | 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.
| Code: | | FUNCTION BESSEL (A, B, C) |
in which case you could easily miss it.
You could always be getting a better 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 |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
