forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Attributes of file
Goto page Previous  1, 2, 3, 4  Next
 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> General
View previous topic :: View next topic  
Author Message
JohnCampbell



Joined: 16 Feb 2006
Posts: 2554
Location: Sydney

PostPosted: Mon Jun 08, 2015 2:10 am    Post subject: Reply with quote

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
View user's profile Send private message
DanRRight



Joined: 10 Mar 2008
Posts: 2813
Location: South Pole, Antarctica

PostPosted: Tue Jun 09, 2015 2:42 am    Post subject: Reply with quote

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 Smile 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 Smile 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
View user's profile Send private message
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 2388
Location: Yateley, Hants, UK

PostPosted: Wed Jun 10, 2015 1:21 pm    Post subject: Reply with quote

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
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1885

PostPosted: Wed Jun 10, 2015 3:09 pm    Post subject: Reply with quote

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
View user's profile Send private message
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 2388
Location: Yateley, Hants, UK

PostPosted: Wed Jun 10, 2015 4:04 pm    Post subject: Reply with quote

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
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1885

PostPosted: Wed Jun 10, 2015 4:08 pm    Post subject: Re: Reply with quote

LitusSaxonicum wrote:
To which I simply reply: Supercalifragilisticexpialidocious!

Eddie

Please see http://en.wikipedia.org/wiki/Taumatawhakatangihangakoauauotamateapokaiwhenuakitanatahu#/media/File:New_Zealand_0577.jpg
Back to top
View user's profile Send private message
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 2388
Location: Yateley, Hants, UK

PostPosted: Wed Jun 10, 2015 4:35 pm    Post subject: Reply with quote

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
View user's profile Send private message
Wilfried Linder



Joined: 14 Nov 2007
Posts: 314
Location: Düsseldorf, Germany

PostPosted: Wed Jun 10, 2015 5:27 pm    Post subject: Reply with quote

As I've written somewhere else here, I always use IMPLICIT NONE because it avoids a lot of errors. In nearly every script to Fortran you can read something like "it is strongly recommanded to use implicit none". Some few examples:

http://www.personal.psu.edu/jhm/f90/statements/implicit.html
http://cs1313.ou.edu/CS1313_2000Spring/Q+A/implicitnone.html
http://en.wikibooks.org/wiki/Fortran_2003
http://www.codezone.co.uk/fortran/implicitnone.shtml
http://www.idris.fr/data/cours/lang/fortran/F77.html#p2.4.2
http://web.eecs.utk.edu/~mgates3/docs/fortran.html

Is there a comprehensible argument against IMPLICIT NONE? I would really like to learn about that.

Wilfried
Back to top
View user's profile Send private message
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 2388
Location: Yateley, Hants, UK

PostPosted: Wed Jun 10, 2015 5:56 pm    Post subject: Reply with quote

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
View user's profile Send private message
Wilfried Linder



Joined: 14 Nov 2007
Posts: 314
Location: Düsseldorf, Germany

PostPosted: Wed Jun 10, 2015 6:21 pm    Post subject: Reply with quote

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 Wink If I need a flight I go to a travel agency...

Best regards and a nice evening
Wilfried
Back to top
View user's profile Send private message
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 2388
Location: Yateley, Hants, UK

PostPosted: Wed Jun 10, 2015 7:38 pm    Post subject: Reply with quote

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
View user's profile Send private message
DanRRight



Joined: 10 Mar 2008
Posts: 2813
Location: South Pole, Antarctica

PostPosted: Thu Jun 11, 2015 1:52 am    Post subject: Reply with quote

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
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 2554
Location: Sydney

PostPosted: Thu Jun 11, 2015 7:54 am    Post subject: Reply with quote

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
View user's profile Send private message
DanRRight



Joined: 10 Mar 2008
Posts: 2813
Location: South Pole, Antarctica

PostPosted: Thu Jun 11, 2015 9:04 am    Post subject: Reply with quote

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
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1885

PostPosted: Thu Jun 11, 2015 12:35 pm    Post subject: Re: Reply with quote

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
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> General All times are GMT + 1 Hour
Goto page Previous  1, 2, 3, 4  Next
Page 2 of 4

 
Jump to:  
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