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: 1994
Location: Sydney

PostPosted: Thu Jun 11, 2015 2:24 pm    Post subject: Reply with quote

Mecej4,

My thoughts were based on:
Code:
   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
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1004

PostPosted: Thu Jun 11, 2015 2:39 pm    Post subject: Re: Reply with quote

JohnCampbell wrote:
Mecej4,

My thoughts were based on:
Code:
   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.
Quote:
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.
Back to top
View user's profile Send private message
John-Silver



Joined: 30 Jul 2013
Posts: 927
Location: Aerospace Valley

PostPosted: Sun Jun 21, 2015 4:15 pm    Post subject: Reply with quote

A very interesting post, although I hate posts like this which leave me with 8 tabs open in my browser which I am then loath to close because I know I'll never find some of the stuff again when I need it !!!
... and I concord fully with Eddie's assessment about 60's tchnology superiority Wink

... btw was Dan's 'problem' actually solved, I lost track after the third comment !
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 5542
Location: Salford, UK

PostPosted: Mon Jun 22, 2015 1:58 pm    Post subject: Reply with quote

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



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

PostPosted: Mon Jun 22, 2015 7:29 pm    Post subject: Reply with quote

Making long things short, in this code

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 Smile


Last edited by DanRRight on Mon Jun 22, 2015 8:49 pm; edited 1 time in total
Back to top
View user's profile Send private message
DanRRight



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

PostPosted: Sun Jul 12, 2015 11:35 am    Post subject: Reply with quote

As a bottom line, here is the question : is the subject of this post considered as a bug or feature at Silverfrost ?
Back to top
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 1994
Location: Sydney

PostPosted: Mon Jul 13, 2015 4:13 am    Post subject: Reply with quote

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



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

PostPosted: Tue Jul 14, 2015 2:20 am    Post subject: Reply with quote

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



Joined: 16 Feb 2006
Posts: 1994
Location: Sydney

PostPosted: Tue Jul 14, 2015 3:50 am    Post subject: Reply with quote

Quote:
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
Back to top
View user's profile Send private message
LitusSaxonicum



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

PostPosted: Tue Jul 14, 2015 3:21 pm    Post subject: Reply with quote

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 LOGICAL*1 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 LOGICAL*8 ...

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



Joined: 16 Feb 2006
Posts: 1994
Location: Sydney

PostPosted: Wed Jul 15, 2015 4:48 am    Post subject: Reply with quote

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



Joined: 31 Oct 2006
Posts: 1004

PostPosted: Wed Jul 15, 2015 2:06 pm    Post subject: Reply with quote

Quote:
(DanRRight, July 13, 2015) 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.
Dan is entitled to use whatever methods he prefers, but the justifications that he listed are incorrect.

First of all, IMPLICIT NONE and /undef are not mutually exclusive. We can use one or both or none, as appropriate to the situation at hand. IMPLICIT NONE is just one ingredient of static code checking, whereas /undef is just one ingredient of dynamic code checking.

There is more to debugging than just catching misspelled variable names, whether at compile time or at run time. A program may contain, in addition to misspelled variable names, incorrect argument lists passed to subroutines and functions, etc. With such errors present, even with /undef causing the program to issue an error and abort, you will still have to diagnose why the variable became undefined.

Dynamic error checking, in general, and /undef, in particular, only covers those parts of the code that got executed in a particular run. Consider this code fragment
Code:

      if (iter > itmax) then
         ierr = -1
         call vperr (iprint, ierr, 1)
         go to 95
      endif

Most of the time, the iterative algorithm that this code implements converges without iter exceeding itmax. If all the test runs worked this way, the entire body of subroutine vperr would never have been tested, whether or not the programmer used /undef. A few years later, a customer tries this code on a tougher problem, vperr gets executed, and lots of mysterious errors surface. Who gets the pleasure of finding the bugs in that case? Who gets the blame?

Dan's refusal to use IMPLICIT NONE, even occasionally, reminded me of the reason stated by some automobile passengers do not wear seat belts -- that wearing them might hinder a quick escape after a crash. A couple of months ago, Nobel Laureate John Nash and his wife Alice died in a taxi-cab crash on their way home in New Jersey (USA) from the airport. The Nashes were returning from a trip to Norway, where John Nash had just been honored with the Abel prize in mathematics. Neither was wearing a seat belt, and both were ejected from the taxi after the crash.
Back to top
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 1994
Location: Sydney

PostPosted: Thu Jul 16, 2015 3:35 am    Post subject: Reply with quote

Mecej4,

Your comment that /implicit is a static check, while /undef is a dynamic check is a useful interpretation.

Unfortunately, I rely on static checks, as at present I have problems with FTN95's /checking options that change the operation of ALLOCATE and stop my programs from working. /debug is about all that I can use.

John
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1004

PostPosted: Thu Jul 16, 2015 3:54 am    Post subject: Re: Reply with quote

JohnCampbell wrote:
Mecej4,

Unfortunately, I rely on static checks, as at present I have problems with FTN95's /checking options that change the operation of ALLOCATE and stop my programs from working. /debug is about all that I can use.

John, I prefer static checks as well, since a single compilation run will flag all the errors that the compiler can detect in the source file; in some infrequent cases, the compiler cannot grok the code and may go haywire.

With /undef, on the other hand, you have to run the compile/link/test-run cycle for each error that is caught. For large programs, this can be slow. This is yet another reason why large programs (such as Dan's) cannot be debugged efficiently using only dynamic error checking.

As to the ALLOCATE bug, I urge you to create a reproducer (MWE) and submit it. We need to hunt these bugs down.
Back to top
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 1994
Location: Sydney

PostPosted: Thu Jul 16, 2015 9:27 am    Post subject: Reply with quote

mecej4,

I have produced a reproducer, see:
http://forums.silverfrost.com/viewtopic.php?t=3071

A compilation option of /ALLOCATE:GlobalAlloc or /GlobalAlloc to go with /CHECK could change this, although I don't know of what other related issues this would cause.

I did not consider using GET_STORAGE@ instead of ALLOCATE, as I wanted to test the production code and thought this would require too many changes.

John
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 3 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