 |
forums.silverfrost.com
Welcome to the Silverfrost forums
|
| View previous topic :: View next topic |
| Author |
Message |
DanRRight
Joined: 10 Mar 2008
Posts: 2877
Location: South Pole, Antarctica
|
 Posted: Mon Jul 20, 2015 9:04 pm Post subject: Best of all worlds: No More IMPLICIT NONE |
 |
|
Consider this code
| Code: | a=1.
b=a*c
Print*,b
end |
NO ERRORS, 1 WARNING [<main program> FTN95/Win32 v7.10.0]
Compiler says OK, go ahead, and the code produces its absurd result. Surprised?
Now let's add IMPLICIT NONE to it
| Code: |
implicit none
real a,b
a=1.
b=a*c
Print*,b
end |
and we get what we must get, and error
*** C must appear in a type declaration because IMPLICIT NONE has been used
1 ERROR, 1 WARNING [<main program> FTN95/Win32 v7.10.0]
*** Compilation failed
IMPLICIT NONE, designed to get rid of implicit definitions of variables based on their first letter had two additional spurious consequences, positive and negative. The positive one is that compiler now finds static typos in the source at the compile time and issues an error mesage. Negative is that you need to declare every variable. Bad about last one is that if you do that in the module, then when you look at the code you have to jump into distantly placed module to see how specifically you declared everything including each and every index i,j,k...That becomes a hell when you make variables long but differ in few letters. By the time you get back and forth, you forget the variable  doing that few times. And I am dead serious! With very large codes that is unacceptable, killing time and certainty and making huge inconvenience. And by the way, the integers and reals are given evils in Fortran, IMPLICIT NONE makes them all same faced, like males and females become of something middle.
I suspect that the absurdness of first example most probably has some strong backing by the Fortran Standard a la "It is the used who has to take care of everything in his own code , not compiler" or "if change that behavior this will break a lot of old codes" etc.
There exist an option in FTN95 to make all WARNINGs to become errors, but that is absolutely not acceptable with large codes, they have megabytes of different kind warnings.
To make all happy i suggest to add the compiler special switch which will oblige compiler to declare an error on every statically undefined variable it finds at compilation time like the C variable above. May be this option exists already hiddenly ?
Then we will get best of all worlds by checking static and dynamic errors (with /undef) forgetting forever annoying error-prone IMPLICIT NONE
Last edited by DanRRight on Tue Jul 21, 2015 7:13 pm; edited 1 time in total |
|
| Back to top |
|
 |
mecej4
Joined: 31 Oct 2006
Posts: 1897
|
| Posted: Mon Jul 20, 2015 11:51 pm Post subject: Re: Best of all worlds: No More IMPLICIT NONE |
|
|
| DanRRight wrote: | ... i suggest to add the compiler special switch which will oblige compiler to declare an error on every statically undefined variable it finds at compilation time like the C variable above. May be this option exists already hiddenly ?
|
This is already implemented, but hidden from those who do not read the documentation.
| Code: | ftn95 /err /set_error_level error 298 <file.f90>
|
See the help file for details.
The usefulness of static code analysis is going to be limited because the depth of such analysis made by FTN95 (and most compilers) is limited. In the first example code above, the error is easy to detect because there is no assignment to c ("c=" or "read...c") prior to the expression containing c. If the code is a bit more complex, as given below, the compile will fail to detect the error, nor should we expect it to do so in normal usage (to keep compilations going fast). It is a bit too much for the compiler to analyse the code and note that the IF condition will not be satisfied since a = 1.
| Code: | program danR
real a,b,c
a = 1.
if (a > 2) c = 3.
b = a*c
Print*, b
end
|
The implication of all this is that static analysis, as with other types of tests and checks, can only go so far. The intelligent programmer will not be made superfluous anytime soon. |
|
| Back to top |
|
|
DanRRight
Joined: 10 Mar 2008
Posts: 2877
Location: South Pole, Antarctica
|
| Posted: Tue Jul 21, 2015 6:39 am Post subject: |
|
|
Thanks for digging it out, mecej4. Great Silverfrost has done that already.
Why they did not publicise it harder? That's exactly what we need.
For simplicity good would be to make nice name for
the compiler switch instead of this one. And the /undef with catch many
other errors this one miss. |
|
| Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006
Posts: 2593
Location: Sydney
|
| Posted: Tue Jul 21, 2015 10:27 am Post subject: |
|
|
Dan,
I compiled your example and got a good response.
John
| Code: | {dan.f90}
real a,b,c
a=1.
b=a*c
Print*,b
end
ftn95 dan
{FTN95 report}
[FTN95/Win32 Ver. 7.10.0 Copyright (c) Silverfrost Ltd 1993-2014]
0001) real a,b,c
WARNING - 298: Variable C has been used without being given an initial value
NO ERRORS, 1 WARNING [<main program> FTN95/Win32 v7.10.0]
|
|
|
| Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005
Posts: 2393
Location: Yateley, Hants, UK
|
| Posted: Tue Jul 21, 2015 11:47 am Post subject: |
|
|
An interesting discussion. Of course, the statement:
must be considered to be unsafe, or possibly incomplete, because it has no ELSE, whereas the far less easy to comprehend and reviled arithmetic IF covers all the avenues! With the arithmetic IF, the programmer had to construct the arithmetic test AND consider what to do with all the possible results. Some possible ways of completing the IF include:
(a) ELSE (including sufficient ELSE IFs and possibly a final ELSE)
(b) Initialisation of variable c with the IF doing special cases,
e.g.
| Code: | c=2.
if (a > 2) c = 3. |
In this construct, the ELSE cases are catered for adjacent to the IF.
(c) Detection of special cases that would crash the program, e.g.
| Code: | if (c .eq. 0.) go to 200
b=a/c |
This could be done even if the likelihood of getting c=0. was negligible: the compiler writer considers detection of a divide by zero and a tidy close down of the program to be a successful conclusion to proceedings, but the Fortran programmer like me considers it to be a crash, and therefore a fault in the program or its data. At the very least I would want to take the opportunity to allow the user to save their work in progress, AND to give a helpful diagnostic (more helpful than the FTN95 report, which is fine for the programmer). I would normally put everything associated with that at the end of the affected subprogram so it was out of the way of normal logic, which is why I find the equally reviled GO TO to be of more use than to do it within an IF .. THEN .. ELSE .. construct.
Eddie |
|
| Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005
Posts: 2393
Location: Yateley, Hants, UK
|
| Posted: Tue Jul 21, 2015 5:35 pm Post subject: |
|
|
... and Dan,
Suggesting that the standard isn't followed is not a suggestion that Silverfrost can take forward, is it?
Anyway, I think this belongs in 'Discussion' not 'Suggestions' ...
Eddie |
|
| Back to top |
|
|
DanRRight
Joined: 10 Mar 2008
Posts: 2877
Location: South Pole, Antarctica
|
| Posted: Tue Jul 21, 2015 7:17 pm Post subject: |
|
|
John,
Sorry i made a typo in second example. Fixed.
Eddie,
What, you don't like this suggestion to make compiler switch to hunt some static undefined variable errors? I do not offer to kill implicit none. Why i posted here? I see no response of Silverfrost in previous discussion 'Attributes of file' in 'General" that the example i posted logged for investigation while few people hinted that it's an error, so i posted this one here in 'Suggestions'. What is left now to discuss is may be to give good name for compiler switch and though this feature will not be commonly accepted among all compilers, it will still hunt you bugs. Did we violate standard with that somehow? Absolutely not.
As to is it an error in my first example above or it isn't? Anyone please try different compilers, let's see how majority of Fortran compiler developers treat the Standard.
Last edited by DanRRight on Wed Jul 22, 2015 12:30 am; edited 2 times in total |
|
| Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005
Posts: 2393
Location: Yateley, Hants, UK
|
| Posted: Tue Jul 21, 2015 9:12 pm Post subject: |
|
|
Dan,
I was operating on your 'No more IMPLICIT NONE'. I could be wrong about your intentions here, and I'm happy to be corrected. However, the case for it as elaborated by others fails if you program defensively - although IMPLICIT NONE lovers claim to be doing just that.
As for me, it's never IMPLICIT NONE!
Eddie |
|
| Back to top |
|
|
DanRRight
Joined: 10 Mar 2008
Posts: 2877
Location: South Pole, Antarctica
|
| Posted: Wed Jul 22, 2015 5:20 am Post subject: |
|
|
No, Eddie, that "No more Implicit none" is just my own crusade against that damn thing.
Of course, the /err /set_error_level error 298 is much less powerful then mighty /undef. But it is always useful to get some errors cleaned without running the code. |
|
| Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006
Posts: 2593
Location: Sydney
|
| Posted: Wed Jul 22, 2015 9:37 am Post subject: |
|
|
Eddie & Dan,
I can't agree as my world has /implicit_none.
This discussion must be what happens when worlds collide !
Unfortunately, at present I can't /undef or even /check, as I need /alloc_global to overcome checking with lots of allocate.
I appears that I am going too close to 2gb limit when /check is being included.
I would make a suggestion that something like /alloc_global be implemented, although I would like to know what this means for using SDBG.
John |
|
| Back to top |
|
|
mecej4
Joined: 31 Oct 2006
Posts: 1897
|
| Posted: Wed Jul 22, 2015 1:54 pm Post subject: Re: |
|
|
| JohnCampbell wrote: |
Unfortunately, at present I can't /undef or even /check, as I need /alloc_global to overcome checking with lots of allocate.
|
I don't understand "overcome checking". Surely, you don't intend to ask for /check and then prevent checks from occurring?
The following is not related to this thread, but please retry the example code discussed in your post at http://forums.silverfrost.com/viewtopic.php?t=3071 with FTN95 7.2. I did that, and there was no error this time.
Perhaps you need to redo the example with larger arrays, now that nothing untoward happens with small arrays.
Last edited by mecej4 on Wed Jul 22, 2015 6:33 pm; edited 1 time in total |
|
| Back to top |
|
|
DanRRight
Joined: 10 Mar 2008
Posts: 2877
Location: South Pole, Antarctica
|
| Posted: Wed Jul 22, 2015 6:22 pm Post subject: Re: |
|
|
| JohnCampbell wrote: |
Unfortunately, at present I can't /undef or even /check |
Even no /check? Wow, you are doomed. I can not use allocatables, they cause me crashes with /3GB, the only way is to use large stacks which is pure devilry business
Silverfrost must do 64bit fast and make sure its allocation works reliably with huge multi-GB arrays. Hope i will not see the word /stack in the HELP file anymore.
What is the size of your code? |
|
| Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006
Posts: 2593
Location: Sydney
|
| Posted: Thu Jul 23, 2015 2:22 am Post subject: |
|
|
Dan,
Just like /implicit_none, I am also convinced on using ALLOCATE and defining these arrays in MODULES, which overcomes some of the problems identified in TR-15581.
This approach works well. About a year ago, I wrote a program that interrogates a personal finance database I have. I wrote it with no array size limits. The design approach was to do multi-pass reading of the database to first identify the size of data structures, then allocate arrays for their size and then re-read the information into these arrays; continuing with the data recovery. The data base has 3 types of records; companies, prices and adjustments.
My database typically has about 200 company records, but on recent use, there was a failure with data input to the finance package and this number exploded to 5000. My program was able to read the database and report the problems. If I had written this using COMMON arrays, I probably would have allowed for 500 companies and the program would have failed, giving a cryptic error report that would have caused me to go back and debug the program when I had other problems to address with the finance package.
It was pleasing that my program design approach had worked so well.
It is good to have a win every now and then.
John |
|
| Back to top |
|
|
DanRRight
Joined: 10 Mar 2008
Posts: 2877
Location: South Pole, Antarctica
|
| Posted: Thu Jul 23, 2015 6:12 am Post subject: |
|
|
How can you do no size limit with 32bit compiler? Did you use some other 64bit compiler? Or actual numberof byts in memory is less then 2-3 GB? What is the size of database you need to load?
Just one variant of mine is ~20-100GB, i can barely load tiny part of it at a time, let alone to use any allocatables conflicting with stack when the size in memory approaches 1-2 GB. Simple tests with one allocatable array may show up to 4GB is loaded (2 in allocatable and 2 into stack) but in real task with few arrays this breaks into freezes with no ends possible to find. The solution is to wait for 64bits
And what is the size ( lines of code) of your fortran text? If it is not very large then implicit none works. If not, in my experience in the 100-200k lines, then it is barely useful. At some size you start to feel that the difficulties to add something increase exponentially. And there you will start appreciating /undef like no other switch. That size estimation above may depend on your writing skills in regular human languages as there exist some people who can write the whole scientific articles or novels from the beginning to the end with no single typo or change and some rewrite 7 (Tolstoj) or 777 (me) timers. I speculate those unique writers would be good programmers when size grow.
Right now this bewitched at its almost useless 32bits compiler with its totally absurd errors is trying to degrade me to the state of neanderthal. No single line of progress today. |
|
| Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006
Posts: 2593
Location: Sydney
|
| Posted: Thu Jul 23, 2015 9:17 am Post subject: |
|
|
Dan,
Certainly 32 bit or 64 bit implies limits to the data size. The database I am using is a byte addressable file with 4-byte addresses, so is limited to 2gb. ALLOCATE can be very helpful for memory limits, as you can define array sizes to be minimal for the problem you are solving, then release the memory when no longer required.
I probably mentioned previously another terrain model I have for a 75km long channel, which I divide into virtual pages of 1000m x 1000m points. there are 75 x 75 virtual pages but only about 200 in use. The virtual address of (IX, IY) to nearest metre is converted to (Page, JX, JY). I have found this to work well with 32-bit. I process the info, based on active pages only, which reduces the workload substantially.
The main program I am trying to use /check on is about 40k lines and 500 routines. It has many sub projects which makes it easier to work with. I have been working on it for 30 years.
John |
|
| 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
