source check
in [Fortran]
|
Prev: XLF V13.1 release for AIX -- fully compliant Fortran 2003 standard
Next: Matlab mexing with gfortran -- String handling.
From: glen herrmannsfeldt on 20 Apr 2010 13:16 user1 <user1(a)example.net> wrote: > Uno wrote: >> http://i43.tinypic.com/15qog09.jpg >> I make a living in the US southwest ostensibly working with my hands. >> I'm installing an engineered floor for my friend Matt. I can do this >> because by trade I'm a journeyman carpenter. (snip) > Why not use a spreadsheet, then go ask in a different group ? Well, more specifically, it is unusual to write in Fortran a specific case to a general problem. It would be more usual to have the program prompt for and read in the various values. Another possibility, also fairly common, is to read in a data file specifying the needed values. (The latter is sometimes preferred as you get to keep the file for future reference.) There are a few cases where one might write a program for one specific problem, when there is no general problem. One might, for example, use Fortran to calculate pi to many decimal places. There is only one pi, and there isn't really a generalization of the algorithm. Now, what I expect to be the problem in floor engineering is that floor products come in specific sizes, which don't divide up so easily. What one really wants to do is to find the optimal partition, number of cuts, of the pieces to fit a given floor size. That is a much harder problem, but also probably more useful. -- glen
From: Richard Maine on 22 Apr 2010 10:51 Uno <merrilljensen(a)q.com> wrote: > Louis Krupp wrote: > > > No. 'cases' should be integer. > > > > The whole idea behind 'implicit none' is to force you to declare > > variables so that if you misspell something, the compiler catches it for > > you: > > > > real r1 > > > > r1 = 0.0 > > r1 = rl + 1.0 > > > > The compiler will catch the substitution of 'rl' for 'r1' ... unless, of > > course, you've also declared 'rl', in which case you've set yourself up > > for trouble by declaring two variable names that look almost identical. > > But there's something to be said for > > implicit real (a-z) I don't think you understood Louis's comment - or my prior one. The problem Louis refers to applies to *ANY* implicit typing. Having all the types be real lowers the chance of being confused about what type something is, but it does *NOTHING* to avoid the problem that Louis refers to or many others of its ilk. I could go on for a long time listing the related problems I have seen. There are things such as if (condition) then a = 1 (which doesn't do anything at all like what you probably think), or common /whatever/ lots,of,variables,......, and, 1 more, where the last comma on the first line is in column 73, or many, many other such problems. > , in particular that there isn't much difference between 42 the integer > and 42 the real. I'm sorry, but there are very fundamental differences. I'm not going to try to list them all. I don't even think it is practical to list them. I'd say it was more the opposite - that they are different in every way except for a handful. The implicit conversion on assignment that you show is one of that small handful of places where they act somewhat alike... and that's also a place where people very often make mistakes (a common one being to write something like x=1.2, where x is double precision). Everything in my 40+ years of programming in Fortran says that it is a serious mistake to treat data type so casually. A significant fraction of the problems people ask about here relate to getting types wrong. I advise the entire opposite of the approach you seem to be taking. Rather than trying to paper over the differences in type, you should consciously think about the type of every data entity. > So I can have lines like the very readable > > sqft = 144 Oddly, I recall thinking of that line in your code as being particularly hard to read. The type promotion aside, I found the variable name confusing. Only by seeing how it was used in the code could I deduce that this was a conversion factor to turn square inches into square feet (by dividing). It occurs to me that there is much similarity in the issues of units of measure and types. Where units of measure are relevant in a program, it needs to be completely clear what those units are. People should not have to deduce it from the conversions used. I had to study the code to deduce that the input units must be inches, while the output was in square feet. It wasn't a very difficult deduction in this case, but I did have to deduce it. Extend this kind of practice to a larger program and it wil be a killer. You ask elsewhere about the benefits of object orientation. I would say that, for you at the current stage, they are zero - more like negative. Much of object orientation centers around type-related concepts. If you are still at the stage of trying to be able to ignore types, then I'd say that there isn't much point in worrying about running marathons before you get crawling down pretty well. As you bring more advanced language concepts into play and have larger programs, being careless about types tends to matter more. That's part of why I try to steer people away from implicit typing. You can get by with it in simple codes like the one at hand, but developing that habit will severely handicap you ability to handle larger codes. -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain
From: glen herrmannsfeldt on 22 Apr 2010 13:10 Richard Maine <nospam(a)see.signature> wrote: (big snip mostly related to implicit typing) > It occurs to me that there is much similarity in the issues of units of > measure and types. Where units of measure are relevant in a program, it > needs to be completely clear what those units are. People should not > have to deduce it from the conversions used. I had to study the code to > deduce that the input units must be inches, while the output was in > square feet. It wasn't a very difficult deduction in this case, but I > did have to deduce it. Extend this kind of practice to a larger program > and it wil be a killer. Maybe off topic for this dicsussion, or maybe not, but this reminds me of noting what I believe is a difference between physics (and maybe other sciences) and engineering in the use of units. It seems to me that engineers often don't give variables quantities with the units included, but factor out the units. One might, for example, say F(Newtons)=m(kg) times a(m/s**2), such that the variables F, m, and a, have numerical values in the specified units, but the variable doesn't include the units. One would be expected to convert the input data to the specified units, and convert the result to the desired units. In physics, it would be more usual to say F=m times a, where m might be 2kg, and a might be 5m/s**2, resulting in F being 10 kg*m/s**2, otherwise known at 10N. As another example, m might be 10g, and a 3m/s**2, such that F comes out 30 g*m/s**2, not a common unit. It would then be converted to the desired unit. One reason for this might be that most programming languages don't allow variables with units. One normally factors out the given units, specified in the prompts or documentation, and only gives the numerical value. Propagating units through a compiled language would not be so easy, though doing the conversion as part of the I/O library wouldn't seem so hard. -- glen
From: dpb on 23 Apr 2010 09:16 Uno wrote: > Richard Maine wrote: >> Uno <merrilljensen(a)q.com> wrote: > >>> sqft = 144 >> >> Oddly, I recall thinking of that line in your code as being particularly >> hard to read. The type promotion aside, I found the variable name >> confusing. Only by seeing how it was used in the code could I deduce >> that this was a conversion factor to turn square inches into square feet >> (by dividing). > > It would have been better if it were > sqft = 144.0 > > Since I measure to the closest sixteenth, these numbers show up as a > rational number of inches, usually having a fractional part. > > Most clients would be confused if I didn't do this small trick in > dimensional analysis. Dividing by a real is not something that > fortran's gonna drop the ball on. What would have been better was a descriptive name for the conversion factor that relates to how is is used was the point being made. Again, in trivial code it's not terribly difficult to dig thru and retrieve such things from context altho it takes time and effort. As code size and complexity grows, the importance grows with it and it's quite possible (actually quite common) that even the original coder will puzzle over "what was I doing there????" when re-visiting code later if it isn't made patently clear thru naming conventions and/or comments or straightforward coding what was being implemented. You seem oblivious to the underlying issues raised re: IMPLICIT NONE -- whether it's simply inexperience showing or stubbornness for the sake of maintaining present prejudices and practice it doesn't bode well for ease in debugging and code maintenance down the road... --
From: Richard Maine on 21 Apr 2010 02:22
Ron Shepard <ron-shepard(a)NOSPAM.comcast.net> wrote: > In article <hqkngl$h1l$1(a)naig.caltech.edu>, > glen herrmannsfeldt <gah(a)ugcs.caltech.edu> wrote: > > > > Why not use a spreadsheet, then go ask in a different group ? > > > > Well, more specifically, it is unusual to write in Fortran > > a specific case to a general problem. > > Not necessarily. If you need something that is in fortran, but not > in excel or some other language, then you would use fortran. A good > example of this is eigenvalue problems. Excel doesn't have any > eigenvalue routines built-in. I sometimes wish that it did, but it > doesn't. But I think Glen's point (I sometimes misunderstand him, but I think I got this one - probably means I'm wrong :-)) was that you wouldn't write Fortran code to solve a particular Eigenvalue problem. Instead, you would write (or more likely, use one from a library) a routine that solved a more general Eigenvalue problem, and you would feed it the particular array in question (assuming one was talking array eigenvalues). -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain |