|
forums.silverfrost.com Welcome to the Silverfrost forums
|
View previous topic :: View next topic |
Author |
Message |
JohnCampbell
Joined: 16 Feb 2006 Posts: 2554 Location: Sydney
|
Posted: Mon Jun 08, 2015 2:10 am Post subject: |
|
|
Eddie & Dan,
/implicit_none is not some way of making you change the way you start integers with I:N, but a way of setting up a table of valid variable names.
I use it all the time, as when writing new code, I look through all the undeclared variable names, placing them in INTEGER*4 or REAL*8 declaration lists, ensuring that each name is a variable I want to use. ( I have always been frugal with variable names!)
All Modules have variables declared and for common, I prefer to use them as include 'name.ins' ; with all variables declared.
For me, too many local variables means the routine is too complex and should be split into simpler tasks. While not always possible, it can help in confirming smaller routines do not affect other tasks when not intended.
I also check the use of common and modules in each routine, by commenting out the INCLUDE or USE line and noting the variables that are identified as undeclared, which identifies the list of variables being used in this routine from that common or module.
It provides me with a useful coding error filter, which says only variables from this defined name table can be used.
Changes to code also benefit from this name filter.
Every time I get an error report from mis-typing a name, it reinforces my view of the usefulness of this approach.
I would certainly recommend you give it a try. You may be surprised by the number of incorrect variable names still in your code, waiting to produce a new unexpected program malfunction.
Back to the origins of this thread, FILES8@ was introduced to give the size of files larger than 2gb, so REAL*8 was provided. ( I would have preferred INTEGER*8 (and KIND=8!) although there has been a reluctance to use integer*8 in FTN95, as it's more general use has been gradually supported. It might be due to software support? Are there I*8 instruction support for x32 ? It is an essential kind for x64)
John |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2816 Location: South Pole, Antarctica
|
Posted: Tue Jun 09, 2015 2:42 am Post subject: |
|
|
Thanks mecej4 and John for the info.
John, i ran the same program as above (i call Searcher and include in my Tools after adding nice GUI to it) and found 110 times i used "implicit none" in my programs. This surprised even myself, i have to check this tool. The result you know: after years i conclude - I do not like it and stopped its use. The only bug this caused was this one above because people hesitate or are lazy to report the bugs and improvement suggestions. Those who use PE version must report 10 bugs/suggestions as "payment" for privilege of using this unique compiler which like all software has bugs.
My subprograms are not large, one code for example has 805 subroutines in 260K lines. I'd beat that i do not have many such bugs you claim because all of them including ones in PARAMETERS (which is the compiler bug) are revealed by /UNDEF. I'd beat 20 bucks for that but adding telephone book of names on top of programs (49 MB of crossreferences!!!) is a lot of work with no benefits specifically when this bug will be fixed and /NO_TRUNCATE will be commonly used. Even if /XREF will help to automate this work it's pure waste of time for potentially obsolete feature. Talking about change in implicit integers and reals, implicit none may actually make more hidden errors then it cures when you will think the variable is real but it is actually integer and will never find that. That bug i found just by chance was the last straw recently when i said NO to IMPLICIT NONE. But may be you see some other benefits i do not see. And did i forget to say that debugging will be longer? And how about exponential decrease of prorammer's productivity (measure in new lines of code per unit time) with program size?
My general point is that it's compiler which has to find all syntax bugs, not people. It has to work like a blind immune system. Humans must fix more complex problems
But your exclusion of USE is good idea. Will try it.
Last edited by DanRRight on Fri Jun 12, 2015 11:05 am; edited 1 time in total |
|
Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2388 Location: Yateley, Hants, UK
|
Posted: Wed Jun 10, 2015 1:21 pm Post subject: |
|
|
Hi John,
Quote: | /implicit_none is not some way of making you change the way you start integers with I:N |
Well I agree that it doesn't have to be, but it also creates verbosity that I don't like. I'm happy to believe that it could help, and that lots of people might love it, but it doesn't work for me, and worse (with my ingrained habits) I find it irritating.
I've only ever used an INCLUDE in one program, other than WINDOWS.INS, and in the end I removed it. It was a way of getting variable size array limits. But I'm content to use fixed size arrays. For example, I wrote a program for computing out and plotting student surveys on a field course. If every student recorded ten times the number of sights by working harder than they do, for ten times as many days as the spend in the field, with ten times the number of students we ever had - it still fits in a gigabyte. Not only that, but they also work in groups, so they don't all get a unique set of results every day. So there's a huge safety factor on the array sizes that we never had when we worked even in DOS.
Plus, if any variable name was mistyped, the survey plot would be wrong, and the proof of the pudding is in the eating.
I'm a great realist about these things, and don't advocate that anyone else does as I do, I just note that one can operate perfectly satisfactorily without following every fad and fashion in computer science theory, and I have the prejudiced view that many things introduced since Fortran 77 are alternative ways of doing something already doable, and are no advance in reality.
Eddie |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1886
|
Posted: Wed Jun 10, 2015 3:09 pm Post subject: |
|
|
Dan,
Here is an example that I constructed in order to shake up your weltanschauung. I have made it easy to find the error by careful visual inspection, by aligning a couple of the lines. Using only the methods and techniques that you have declared in this thread to be acceptable to you, find the error in the program.
Code: | program buggy
integer :: Lwllllantysiliogogogoch = 13
!
! Imagine large block of code here that does some complicated
! calculations that depend on the above variable
!
if(Lwllllantysiliogogogoch > 10) &
Lwllllantwsiliogogogoch = 10
print *, 'Factorial (',Lwllllantwsiliogogogoch, &
') = ',ifact(Lwllllantysiliogogogoch)
contains
integer function ifact(n)
integer n
ifact = n
do while(n > 1)
n = n-1
ifact=ifact*n
end do
return
end function
end program
|
Remember, careful visual inspection is not one of the allowable techniques, since there could be a huge block of code placed after the declarations in the main program, which we shall assume to be too time-consuming to inspect.
[Apology to Eddie: I actually used 'Llanfairpwllgwyngyllgogerychwyrndrobwllllantysiliogogogoch' as the variable name in the example code, and the preview of the post came out fine. However, when I pressed the 'Submit' button the forum software gave SQL errors, so I reluctantly truncated the name, and abandoned my plan to try 'Taumatawhakatangihangakoauauotamateapokaiwhenuakitanatahu'.] |
|
Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2388 Location: Yateley, Hants, UK
|
Posted: Wed Jun 10, 2015 4:04 pm Post subject: |
|
|
To which I simply reply: Supercalifragilisticexpialidocious!
Eddie
PS. I'm sure that your post is akin to antidisestablishmentarianism, or perhaps it is floccipaucinihilification ... |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1886
|
|
Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2388 Location: Yateley, Hants, UK
|
Posted: Wed Jun 10, 2015 4:35 pm Post subject: |
|
|
Your code uses all sorts of things that I don't, even print* instead of write (*,*). I never put functions in output, because it means you can't drop a write into the function for testing, and you probably understand that I don't like DO loops without statement numbers, and as for CONTAINS ... I've gone to get something to ward off the evil eye.
The point you are trying to make is very simply found if you know how to pronounce Welsh, as the names are then very different - which leads me to point out that if one reads them as names rather than as abstruse symbols, the spelling variations are easy to detect - if you can spell. Latin is good too, as are the other European languages that I can pronounce.
I might add that when you try all that Maori stuff, sticking your tongue out, grunting and striking a pose - the crowd in Cardiff Millennium Stadium will simply sing over the top of you with a beautiful melody and nonsense words:
Mae bys Meri-Ann wedi brifo ... |
|
Back to top |
|
|
Wilfried Linder
Joined: 14 Nov 2007 Posts: 314 Location: Düsseldorf, Germany
|
|
Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2388 Location: Yateley, Hants, UK
|
Posted: Wed Jun 10, 2015 5:56 pm Post subject: |
|
|
Wilfried,
It's a fashion and a fad. I don't like it, and its use is not essential. It's a personal choice, and I never tell other people what to do. If you like it, use it. If it helps you, then all to the good.
I never make the mistakes it is said to avoid*, and dislike the verbosity it (and other post-77 constructs) generate. Indeed, it can be unspeakably stupid to include it, like this example from one of your example websites:
Code: | program hello
implicit none
write (*,*) "Hello, world."
end program hello |
There are no variables in that program, and the line is simply an irritant. (As indeed are the two unnecessary words after 'end'.)
The genius Backus invented implicit typing for variables, and believe me, some things in technology were better in the past than they are now. Don't believe me? Then try to book a flight that gets you from London to New York in under 3 and a half hours!
I've got a shelf of Fortran books, and some of them recommend all sorts of odd things. Like using lower case, so that you don't confuse 1 and I, or 0 and O - but they remain silent on confusing 1 and l, and they don't tell you that it simply depends on the font your computer uses. Some people say that using upper case is shouting - that's fine, my computer(s) need shouting at, like all idle servants!
Eddie
* Not once, not ever. I've been programming Fortran since 1970. Granted, it isn't my main job. I make plenty of other mistakes ... |
|
Back to top |
|
|
Wilfried Linder
Joined: 14 Nov 2007 Posts: 314 Location: Düsseldorf, Germany
|
Posted: Wed Jun 10, 2015 6:21 pm Post subject: |
|
|
Eddie,
OK, it's a fashion. It was not my intent to tell other people what to do! I started programming in the early 1980s, Algol68 and Fortran77. The "implicit none" was introduced with Fortran90, as far as I know.
In earlier times everything was better, even the future If I need a flight I go to a travel agency...
Best regards and a nice evening
Wilfried |
|
Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2388 Location: Yateley, Hants, UK
|
Posted: Wed Jun 10, 2015 7:38 pm Post subject: |
|
|
Dear Wilfried,
The 'under 3 and a half hours' was the flight duration, not the booking time!
It was possible with 1960s technology, but nothing comes close nowadays!
Regards
Eddie |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2816 Location: South Pole, Antarctica
|
Posted: Thu Jun 11, 2015 1:52 am Post subject: |
|
|
mecej4,
If you look at the Linux OS source code which was couple million lines 15 years back when i last time touched it, you will find crown examples of variables 63 character long. That may shake anyone's weltanschauung. After that i asked FTN95 developers (i think it was Paul?) to implement long variables in FTN95 and thanks to guys this compiler supports ... hell long variables. Longer variables are not necessarily bad things and harder to remember, they are much easier to remember if done right way then for example the ones you have used above. And FTN95 will take care and pesticide all syntax mistakes like no other compiler in the world. Even though this compiler did not show me the bug which started this thread, it did not mask it to allow me to run faulty code.
Wilfried,
These recommendations became obsolete at the time Salford introduced /undef. (I am now not sure if this was done from the start of FTN77. What is official birthdate of it by the way?). Other compilers simply did not know it. Lahey also have done that but it was 20x slower then FTN77. I had a discussion on comp.lang.fortran about that 20 years back. No one there - and there were a lot of Fortran hacks and Fortran standard committee members at that time - had a clue about its superior debugging opportunities and were really surprised. Since then other compilers started to add it too. But still how many people know about it?
The implicit none gives you some primitive form of syntax error check. But /undef gives you 100 times more - it gives you check of program flow and logical mistakes in the design. And also meantime checks for your syntax. Change something in large programs and you will get tons of flow errors. Here /undef is a truly a super tool of bugs hunt. By th way, have you ever used /undef ? If not, try it, and then we will all laugh here at implicit none "great" bug hunting capabilities !
Last edited by DanRRight on Thu Jun 11, 2015 12:57 pm; edited 1 time in total |
|
Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2554 Location: Sydney
|
Posted: Thu Jun 11, 2015 7:54 am Post subject: |
|
|
mecej4,
To me, The error is in function ifact, as n is being corrupted.
Code: | integer*4 ifact,i,n
do n = 0,13
i = ifact (n)
write (*,*) n,i
end do
end
integer*4 function ifact (n)
integer*4 n, i
ifact = n
do i=n-1,2,-1
ifact=ifact*i
end do
return
end function
[quote][/quote] |
|
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2816 Location: South Pole, Antarctica
|
Posted: Thu Jun 11, 2015 9:04 am Post subject: |
|
|
No, that was with an artificial (though still possble) example of very low probability.The error is in mistyping some variable Lwllllantysiliogogogoch as Lwllllantwsiliogogogoch, initializing mistyped Lwllllantwsiliogogogoch to be hidden from /undef (which uses statistical approach that probability to make the same typos are small) and then ***mistyping original variable second time exactly like fist time when using it***. With the number of letters this variable has this is literally impossible. Someone may argue that after first mistyping the variable was copy-and-paste'd into new place. But then how the typo was made ? Why the original variable was not copy-and-pasted too? LOL
The strength of /undef is in revealing a lot of damage which cause mistyped variables as well as anything not originally intended. The larger code the more damage. I'd stress that not necessarlly mistyping may leave variables uninitialized, some variables not in the range of code stability can do that too. Destruction in the code takes place mostly in the arrays and due to IFs made wrong way - to the source body too. /UNDEF guards your code every second code works. Statistically it takes most of the "implicit none" job too. Implicit none work is just done ones at the time of code writing and that's it.
Last edited by DanRRight on Thu Jun 11, 2015 12:54 pm; edited 1 time in total |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1886
|
Posted: Thu Jun 11, 2015 12:35 pm Post subject: Re: |
|
|
JohnCampbell wrote: | To me, The error is in function ifact, as n is being corrupted.
Code: | integer*4 function ifact (n)
integer*4 n, i
ifact = n
do i=n-1,2,-1
ifact=ifact*i
end do
return
end function
|
|
John, why do to think so? The function has only one dummy argument, and that argument is not being altered in the function. |
|
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
|