Welcome to our forums
Quoted from LitusSaxonicum To which I simply reply: Supercalifragilisticexpialidocious!
Eddie
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 ...
As I've written somewhere else here, I [u:ff226d1a8b]always[/u:ff226d1a8b] 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
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:
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
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
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
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 !
mecej4,
To me, The error is in function ifact, as n is being corrupted.
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]
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.
Quoted from JohnCampbell To me, The error is in function ifact, as n is being corrupted.
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.
Mecej4,
My thoughts were based on: integer function ifact(n) integer n ifact = n do while(n > 1) n = n-1 ifact=ifact*n end do return end function
I have never liked do while, it sounds like it should skip invalid values, rather than exit.
John
Quoted from JohnCampbell Mecej4,
My thoughts were based on: integer function ifact(n) integer n ifact = n do while(n > 1) n = n-1 ifact=ifact*n end do return end function
OK, now I see that you made some changes to the code, thereby reducing the number of bugs in it. At any rate, Dan has his own ideas about how to fix the bugs in his code, so none of this matters as far as he is concerned.
I have never liked 'do while', it sounds like it should skip invalid values, rather than exit. DO WHILE is defined in the Fortran standards. The DO WHILE construct is very similar to the 'while(integer expression)' of C.
For selectively operating on some but not all elements of a set or array, based on a condition or mask, 'when' and 'where' would be more appropriate. In fact, Fortran has the WHERE construct.
This may be relevant to an earlier post that I saw on this thread.
/check implies /debug (i.e. /debug is part of /check), /undef implies /check, /full_undef implies /undef, /checkmate is an alias for /full_undef.
Students of Fortran are usually advised to write IMPLICIT NONE at the head of every subprogram - it saves the student and the tutor a great deal of wasted time and effort. Experienced users will have their own preferences.
I would advise users of FTN95 to always use /checkmate when testing and developing their code. Finished code should be built without using any of the debugging options.
Making long things short, in this code
parameter (leve1=10)
character*(level) chVar
chVar='Debug me'
Print*, chVar
end
either compiler or debugger or better both have to stop exactly on the offending line when compiler with /checkmate or /undef
/* John, Do you mean you have 8 browsers open or just 8 tabs? By the way, here are my current tabs, sans the Safari, Maxthon and one unnamed browser 😃
As a bottom line, here is the question : is the subject of this post considered as a bug or feature at Silverfrost ?
Dan,
I think that it is a compiler error, but you should use /implicit_none, which would more easily find this and other similar errors.
/implicit_none basically says that all used variable names should be in the dictionary of declared names. I find this a very useful approach when writing code, as each time I get an error I then check if the variable is misspelt or I have omitted the variable name from the dictionary. I put the variable declarations in include files and also modules. I don’t use dimension statements.
Also, thanks for your code example as I have learned how to drop a file into a clearwin+ program. see my pm for details
John
John, implicit none makes annoying necessity to declare default i,j,k,l,m,n and anything started with them. If you still have large portion of codes written with old style, you will be mixing the styles which is invitation for the disaster. You expect variable to be real but it is declared as integer - you are in troubles, you may never find this error.
You do not know the type variable in implicit none and with large code it is terrible work to go and find that all the time.
As i mentioned above /undef has MUCH more value then implicit none - it checks your program logic whole code's further life when you make additions or changes, not just initial typos as with implicit none (i usually do a lot of typos, nobody in the world make more errors and typos then me, unfortunately for me English language is just a colorless abracadabra, i do not feel it and hardly memorize it, i type too slow, permanently change everything, but all the typos are at the beginning when i write the program, then, since my variables are long, i just copy/paste them). Typos is too small portion of all possible errors. And /UNDEF will find them anyway.
OK, imagine you opened some regular (with no implicit none) source where error is. Your long name variables tell you what they are for, integer and real types are more or less clear and you quickly find the error not jumping anywhere. With implicit none style you permanently jump up to the header to find what the heck is this or that variable and the number of such variables in the large code called gazillion
So, no, thanks. Implicit none is dead wrong approach with large codes if compiler has /undef. Yes, undef does not catch some rare errors. But it catches 1000 times more then implicit none. Other compilers are too slow with /undef, Lahey, for example, is 10x slower then this one, see Polyhedron
You expect variable to be real but it is declared as integer - you are in troubles
Dan, it is YOU, the programmer who may declare what you expect to be real as integer, not implicit none. The only scare campaign you have should be directed at what you code. Having a list of active variables helps me understand what I am doing. It also lets me stop and review the name of each new variable, so that it's name helps with the code. I still typically use i,j,k as integer do loop counters, (but I avoid 'l' as most fonts make this difficult to differentiate from 1). I rarely have a real variable starting with i:n, but do generalise for integer counters. All logicals and characters need a declaration. Most of the code samples I have posted would probably adhere to the implicit type convention.
I have /implicit in ~\silverfrost\ftn95\ftn95.cfg so new code can be a challenge. I have to update all declarations, which I find a good thing.
Anyway, we'll both code the way we find best and perhaps choose other approaches from time to time.
At the moment I can't use /UNDEF, as I have trouble with any checking options; /check or stronger changes the way ALLOCATE works. I need something like /ALLOC_malloc to go with /CHECK.
John
Logicals and characters may need explicit typing, but commonly they are the smallest part of a Fortran program. You forgot to mention COMPLEX. Since a logical has to be true or false, then it is in effect the answer to a question, and a useful extension to implicit typing is to set all logicals to begin with 'Q', or 'Query' or couch its name as a question. Even a LOGICAL1 has 256 possible 'answers' so I consider them perhaps not to be LOGICAL as much as POLITICAL (and just imagine how may shades of grey you could have with a LOGICAL8 ...
I note that Dan isn't a native English speaker, but I get what he means when he reads code and makes an assumption about its type from its initial letter, and how tedious it is scrolling up and down codes to check on the type of something if you do use IMPLICIT_NONE.
Eddie
Eddie,
This is getting ridiculous !! YOU the programmer chooses what to start integer or real variable names with. All IMPLICIT NONE does is to make you list all variable names in declaration statements, so that you have a spell check for all variables being used. A secondary benefit is that when you introduce new variables into code as you are writing and testing, that the error report says 'this is a new variable name; is this what you want ?' You can then introduce it to the 'dictionary' or choose a better name.
Try it; you may be surprised how helpful it is. Otherwise use your other methods of spell check.
John