|
Prev: Call Array valued Fortran function from C
Next: Advice on how to keep track of allocated memory
From: Luka Djigas on 20 Apr 2008 22:01 On Sun, 20 Apr 2008 18:59:37 -0500, dpb <none(a)non.net> wrote: >When learning a new language, one thing to do is to gradually simply >read the entire LRF from cover to cover so you at least see all the >features. You obviously won't learn them all from that single perusal, >but you will have the experience of having seen it so there's a least a >reasonable chance of recalling of "I remember something about...". True, I agree. That is one way. To start learning a language knowing it will help you solve some problems in the future. The other, also not so uncommon (my case), is when you're introduced to a language by somebody who's been with it for a long time ... who started to use it only to solve problems, but with no regards for the language itself, if you understand what I'm trying to say ... so I got the basics of it (f77), read an old ibm 1130 manual (a masterpiece, if I may say so) and gradually found a way to deal with basically every situation which came to me. In one way or the other. That way nice about f77, if you learned 20 keywords, you practically had a tool for solving every problem which can occur in engineering calculations. And you don't have to think about the language too much, so you can concentrate on the problem itself. Since I'm not a programmer by trade, and since it's much more important for me to get the result, rather than nice code, I often find myself doing something in a way for which I know there is a better way, but due to the more important problems at that moment I just ignore the chance to learn a better method to do it. Then, from time to time, something starts to bother me, ... I pick around the LRF, stumble upon something, don't knowing how to use it, search the group archives, ask you guys, and find that out and several other things along the way :-), and start to use it from that point on. > >Also, as Richard Maine noted in an response in the last day or so, to >learn really requires more than simply a language reference manual. >There are regular threads here about recommendations for books for >various purposes. > Yes, I saw it. Very nice and useful post (I noticed it comes around every 2 months or so). I did find a nice book a while ago, f90 handbook by Adams and several other fellows, but looking from the size of it, it's more probable that I will use it for the purpose of self defense should a grizzly bear attack me, than that I will manage to read it even partially in the near future :-) (I also noticed it is very similar, example wise, to compiler's LRF. regards Luka
From: Gerry Ford on 21 Apr 2008 02:25 "Ron Shepard" <ron-shepard(a)NOSPAM.comcast.net> wrote in message news:ron-shepard-76B796.09441520042008(a)comcast.dca.giganews.com... > In article <u0jm049f123f0c3ntnvi9dqbgo162dtvac(a)4ax.com>, > Luka Djigas <ldigas@@gmail.com> wrote: > >> Anyway, I read the help. But didn't manage to figure it out. >> As far as I can see, sum can be used to summ an entire array in one or >> more dimensions. How can one sum just some elements from, for example >> one dimensional array ? > > Here is a description with examples: > > http://gcc.gnu.org/onlinedocs/gfortran/SUM.html > > If you want a subset of an array, or you want a nonunit stride, then > use the colon notation. > > $.02 -Ron Shepard My compiler spits out an error here, Ron, and leaves me with warning 179 - Comparing floating point quantities for equality may give misleading results. mod has to have both types the same. Mine were reals. Yours were ints, so it matters whether you compare to 2 or 2.0. I think I get reliable output for these data as real. real :: a(50) do j=1, 50 a(j) = real(j) end do s=0. do 1 i=5,50 s=s+a(i) 1 continue print *, SUM(a, MASK=MOD(a, 2.0)==1.0) print *, s end output: 625.000 1265.00 , about half an dodd. -- "A belief in a supernatural source of evil is not necessary; men alone are quite capable of every wickedness." ~~ Joseph Conrad (1857-1924), novelist
From: Gerry Ford on 21 Apr 2008 02:40 "dpb" <none(a)non.net> wrote in message news:fufn4b$gcg$1(a)aioe.org... > David Frank wrote: >> "Luka Djigas" <ldigas@@gmail.com> wrote in message >> news:pu4l04dnt3apg1hf1a1jvesp0gf3jttiol(a)4ax.com... >>> What would be the shortest way to sum some elements of an array? For >>> example from 5 to 50. >>> >> >> Gee whiz, all these replies and no-one shows him what he asked for. >> >> asum = SUM(a(5:50)) >> > I missed that... :) > > I saw a response that used 5,50 in a loop but didn't realize it was the > actual question. > > The reply to look at array sections was spot on, though, wasn't it?? :) Yup. real :: a(50) real asum do j=1, 50 a(j) = real(j) end do s=0. do 1 i=5,50 s=s+a(i) 1 continue asum = SUM(a(5:50)) print *, asum print *, SUM(a, MASK= a > 42.3) print *, s end -- "A belief in a supernatural source of evil is not necessary; men alone are quite capable of every wickedness." ~~ Joseph Conrad (1857-1924), novelist
From: Richard Maine on 21 Apr 2008 10:58 Gerry Ford <gerry(a)nowhere.ford> wrote: > My compiler spits out an error here, Ron, and leaves me with warning 179 - > Comparing floating point quantities for equality may give misleading > results. No, that is not an error. It is a warning. Error/=warning. -- Richard Maine | Good judgement comes from experience; email: last name at domain . net | experience comes from bad judgement. domain: summertriangle | -- Mark Twain
From: Ron Shepard on 21 Apr 2008 12:25
In article <1ifqm0o.di6px0khbs3kN%nospam(a)see.signature>, nospam(a)see.signature (Richard Maine) wrote: > Gerry Ford <gerry(a)nowhere.ford> wrote: > > > > My compiler spits out an error here, Ron, and leaves me with warning 179 - > > Comparing floating point quantities for equality may give misleading > > results. > > No, that is not an error. It is a warning. Error/=warning. The gfortran page that I linked to was a general description of the sum() intrinsic function. It contained one example that used a mask argument, but the original problem proposed does not require a mask. It can be achieved simply with the expression sum(a(5:50)). In my personal opinion, that is simpler and easier to understand than the original do loop, but of course opinions on programming style vary from person to person. However, if you want to solve a different problem that does require a mask argument, then it is generally unwise to use a floating point comparison for equality in that mask. The same thing applies if you write out the do loop and perform a test on each element, so this is not something unique to mask arguments in general or to the sum() intrinsic function in particular. In the latest example given, I don't think that I would ever use a floating point mod() to try to extract odd integer values, that seems like a long, round-about, and error-prone way to do a simple operation. For example, once you get up somewhere over a million, roundoff causes all floating point representations of integers to be incorrect, whereas the integer values themselves are still exact for three more orders of magnitude. I would have to get the standard to even know what a floating point mod() function is supposed to do in these cases, and even after that, I would have to test my compilers to make sure they did the right thing in these edge cases. $.02 -Ron Shepard |