From: Luka Djigas on
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

"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

"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
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
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