source check
in [Fortran]
|
Prev: XLF V13.1 release for AIX -- fully compliant Fortran 2003 standard
Next: Matlab mexing with gfortran -- String handling.
From: Ron Shepard on 22 Apr 2010 01:00 In article <1jh9sqf.k71rj3dcuoqoN%nospam(a)see.signature>, nospam(a)see.signature (Richard Maine) wrote: > 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). Perhaps I wasn't as clear as I should have been. Yes, I did mean that you would use some general library routine to solve the eigenvalue problem (probably fortran code from netlib, or LAPACK, or EISPAC, or wherever). I wasn't talking about writing the eigenvalue routine from scratch. What I meant is that if you had a specific problem to solve then you would dimension the matrices with constants, assign the matrix elements to the matrix with regular assignment statements, call the eigenvalue routine, and print out the results (or use the results in some subsequent step). You might not go to the extra effort to make the matrix dimensions general, or read in the matrix elements from a file, or do the other things that you might do for a more general situation. And you would not rewrite the fortran routine in some other language (VBA, or perl, or whatever) because that would be too much effort for a one-of-a-kind type of problem. On the other hand, if excel had eigenvalue routines built in along with the other math and statistical routines, this is the kind of problem that you might instead solve that way. But excel doesn't have those kinds of routines. Mathematica and Matlab and some of the other options are good alternatives for this kind of thing, but those packages are very expensive, not as commonly available as excel, and, interestingly enough, not really any easier to use than fortran for a one-of-a-kind solution to a general problem like this. Other possibilities include using perl libraries or python packages. I would say that if you already have the libraries or packages installed, and you are familiar with using them, then that would be another option that would require about the same amount of effort on the programmers part as the fortran approach (and for small matrix dimensions, the efficiency advantages of fortran over these other approaches would not be significant). But if you don't have those libraries already installed, and you have to go to the effort to install the software and figure out how to use it, then the fortran approach is probably easier in the end. $.02 -Ron Shepard
From: Uno on 22 Apr 2010 02:38 glen herrmannsfeldt wrote: > 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. But I do want to treat it in some generality. That the first version is hard-coded has everything to do with me having to write it in time to be able to recommend that we not do the area that was called r7, the foyer. I was much happier to make the fortran keystrokes than take up that tile. Now I'm looking for objects to be useful to me. I get a fair amount of work like this, so I'd like to be able to whip this up like microwave popcorn. Eventually I would like to have a control that goes through rooms and populates their data, but first I'll have some hard-coded values to sort out the syntax. $ gfortran -Wall -Wextra m2.f90 -o out $ ./out wood supply is 672.00000 calc is 4185.0000 $ cat m2.f90 implicit none real :: footage, sqft, calc, supply integer :: cases type room real :: hor real :: vert character(len=10) :: name real :: subtract end type room type(room) :: living sqft = 144 cases = 28 footage = 24 supply = cases * footage print *, "wood supply is ", supply living%hor = 42 living%vert = 100 living%subtract = 15 calc = living%hor * living%vert - living%subtract print *, "calc is ", calc end program ! gfortran -Wall -Wextra m2.f90 -o out $ So I create a room type that isn't too different from the fortran in the original post. One difference is the subtract component. This living room is typical in that it has an overall area that you would measure in the usual fashion, but you need to knock that down because it's got a fireplace that takes up 15 sq ft, which is half a case of wood, so it's a fudge factor I need. Here's my question: how do I traverse these structures to do the same type of summing up the areas in the original post, with the added wrinkle that their will also be this subtract component, which should default to zero? Thanks for your comment, and cheers, -- Uno
From: glen herrmannsfeldt on 22 Apr 2010 03:24 Ron Shepard <ron-shepard(a)nospam.comcast.net> wrote: (snip) > Perhaps I wasn't as clear as I should have been. Yes, I did mean > that you would use some general library routine to solve the > eigenvalue problem (probably fortran code from netlib, or LAPACK, or > EISPAC, or wherever). I wasn't talking about writing the eigenvalue > routine from scratch. What I meant is that if you had a specific > problem to solve then you would dimension the matrices with > constants, assign the matrix elements to the matrix with regular > assignment statements, call the eigenvalue routine, and print out > the results (or use the results in some subsequent step). You might > not go to the extra effort to make the matrix dimensions general, or > read in the matrix elements from a file, or do the other things that > you might do for a more general situation. And you would not > rewrite the fortran routine in some other language (VBA, or perl, or > whatever) because that would be too much effort for a one-of-a-kind > type of problem. I hadn't actually thought of any one-of-a-kind eigenvalue problem, but yes, if you had one. > On the other hand, if excel had eigenvalue routines built in along > with the other math and statistical routines, this is the kind of > problem that you might instead solve that way. But excel doesn't > have those kinds of routines. Mathematica and Matlab and some of > the other options are good alternatives for this kind of thing, but > those packages are very expensive, not as commonly available as > excel, and, interestingly enough, not really any easier to use than > fortran for a one-of-a-kind solution to a general problem like this. But R (which I have used) and Octave (which I haven't) are free. > Other possibilities include using perl libraries or python packages. > I would say that if you already have the libraries or packages > installed, and you are familiar with using them, then that would be > another option that would require about the same amount of effort on > the programmers part as the fortran approach (and for small matrix > dimensions, the efficiency advantages of fortran over these other > approaches would not be significant). But if you don't have those > libraries already installed, and you have to go to the effort to > install the software and figure out how to use it, then the fortran > approach is probably easier in the end. If you had a large number of such problems to do, and also had to interface with previously written programs in one of those langauges, then it might be worth adapting a library or package. -- glen
From: Uno on 22 Apr 2010 05:46 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) , in particular that there isn't much difference between 42 the integer and 42 the real. So I can have lines like the very readable sqft = 144 My answer is a real, and the promotions are accurate. -- Uno
From: Simon Geard on 22 Apr 2010 06:37
On 22/04/2010 10:46, Uno 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) > > , in particular that there isn't much difference between 42 the integer > and 42 the real. So I can have lines like the very readable > > sqft = 144 > > My answer is a real, and the promotions are accurate. True. But there is a difference for division: real :: sqft sqft = 144 print *,sqft/13 is different from integer :: sqft sqft = 144 print *,sqft/13 Simon |