Home > Archive > Fortran > February 2008 > Good way to fill integer array with successive indices?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Good way to fill integer array with successive indices?
|
|
| Mirko.Vukovic@gmail.com 2008-02-21, 7:14 pm |
| Hi,
is there a way to accomplish the following by using an implied do loop
or some of the intrinsic array functions? I do not know the size of
the array at compile time.
! cX is not known at compile time
integer,dimension(1:cX),allocatable::viX
integer::i,cX
....
do i=1,cX
viX(i)=i
end do
....
Thanks,
Mirko
| |
| Michael Metcalf 2008-02-21, 7:14 pm |
|
<Mirko.Vukovic@gmail.com> wrote in message
news:429898d4-b1fd-40f3-abc2-20b473aebfc8@41g2000hsc.googlegroups.com...
> Hi,
>
> is there a way to accomplish the following by using an implied do loop
> or some of the intrinsic array functions? I do not know the size of
> the array at compile time.
>
First, get the array declaration correct:
integer, dimension(:), allocatable :: viX
then allocate it once you know cx:
allocate (vix(cx))
then use an array constructor ("Fortran 95/2003 Explained", Section 2.10):
vix = (/ (i, i = 1, cx) /)
Regards,
Mike Metcalf
| |
| Mirko.Vukovic@gmail.com 2008-02-22, 10:27 pm |
| On Feb 21, 12:42 pm, Craig Powers <eni...@hal-pc.org> wrote:
> Jan Gerrit Kootstra wrote:
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> If vix is local, the deallocate statement is superfluous; the compiler
> will insert it anyway. If it's not local, it should be deallocated only
> if it really has reached the end of its life.
Thanks to everyone. One of the positive aspects of this group is that
every discussion comes with extra toppings free of charge.
Mirko
| |
| Lorenzo `paulatz' Paulatto 2008-02-24, 7:29 pm |
| Mirko.Vukovic@gmail.com ha scritto:
> do i=1,cX
> viX(i)=i
> end do
In Fortran95 and 2003 you can do:
forall(i=1:cX) viX(i) = i
--
Lorenzo `paulatz' Paulatto
Trieste
``Grandissima mi par l'inezia di coloro che vorrebbero che Iddio avesse
fatto l'universo pił proporzionato alla piccola capacitą del lor discorso.''
--Galileo Galilei (Opere VII)
| |
| Dick Hendrickson 2008-02-25, 7:17 pm |
| Lorenzo `paulatz' Paulatto wrote:
> Mirko.Vukovic@gmail.com ha scritto:
>
> In Fortran95 and 2003 you can do:
> forall(i=1:cX) viX(i) = i
>
>
That's not really a "good way" to do it. FORALL was really
intended as a parallel processing aid. Unless you know
that your compiler/hardware can do parallel processing
efficiently, you should not replace simple DO loops with
forall constructs. Compilers have been trained to
optimize DO loops very very well. They can't do better
on a forall and might do worse (unless they can go parallel
or the forall expresses something that's hard to express
in a do loop).
Dick Hendrickson
| |
| Richard Maine 2008-02-25, 7:17 pm |
| Dick Hendrickson <dick.hendrickson@att.net> wrote:
> Lorenzo `paulatz' Paulatto wrote:
> That's not really a "good way" to do it. FORALL was really
> intended as a parallel processing aid.
I was tempted to say something along these lines, but Dick explained it
better than I would have. I'd say that a simillar comment applies to the
other forms shown, although perhaps not quite as much so as to FORALL.
Yes, you can use an implied DO instead of an "ordinary" DO, but why?
What is this suppose to gain? An implied DO sure doesn't gain anything
in clarity; rather the opposite in that there are extra scoping
subtleties to implied DO (not to speak of the somewhat confusing
(/(..)/) delimitters if you stick to the f95 form). It won't gain
anything in speed either, and might even be slower. I suppose it is
slightly shorter, but not really by that much.
I suppose that if you use the implied DO in conjunction with an
allocatable array and the f2003 feature of allocation on assignment,
clarity might be improved by the brevity. I can see
viX = [(i, i=1,cX)]
as being an improvement over
allocate(viX(cx))
do i = 1 , cX
viX(i) = 1
end do
But that uses two f2003 features. Once you change the form using implied
DO to
allocate(viX(cx))
viX = (/(i,i=1,cx)/)
then I think one might as well go with the original ordinary DO loop
form as the "best" solution in terms of both clarity and speed.
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
| |
| Sebastian Hanigk 2008-02-25, 7:17 pm |
| nospam@see.signature (Richard Maine) writes:
>
> I was tempted to say something along these lines, but Dick explained it
> better than I would have. I'd say that a simillar comment applies to the
> other forms shown, although perhaps not quite as much so as to FORALL.
Interesting, I would have chosen a FORALL block or statement because it
is concise and conveys the notion of (semantic) parallelism; think of it
more as a hint to the reader than the compiler.
Sebastian
| |
| Lorenzo `paulatz' Paulatto 2008-02-25, 7:17 pm |
| Richard Maine ha scritto:
> I was tempted to say something along these lines, but Dick explained it
> better than I would have. I'd say that a simillar comment applies to the
> other forms shown, although perhaps not quite as much so as to FORALL.
Thank to both of you for pointing it out.
--
Lorenzo `paulatz' Paulatto
Trieste
``Grandissima mi par l'inezia di coloro che vorrebbero che Iddio avesse
fatto l'universo pił proporzionato alla piccola capacitą del lor discorso.''
--Galileo Galilei (Opere VII)
| |
| Dick Hendrickson 2008-02-25, 7:17 pm |
| Sebastian Hanigk wrote:
> nospam@see.signature (Richard Maine) writes:
>
>
> Interesting, I would have chosen a FORALL block or statement because it
> is concise and conveys the notion of (semantic) parallelism; think of it
> more as a hint to the reader than the compiler.
>
>
> Sebastian
That's an interesting answer. Mostly, a program is communication
from one programmer to another (forget about the machine), where
the "other" programmer is likely to be myself next w , and using
the clearest coding style is usually the best. But, FORALL
is pretty new (1995) and I think people think it has more properties
than it really has. But, as you say, it's wonderfully expressive for
many things, as long as it doesn't confuse people.
The problem I have is that DO loops are clear and forall is
potentially harmful either in performance or surprising effects.
Something like
DO I = 2,N
A(I) = A(I-1) + 1
ENDDO
isn't the same as
Forall (I = 2,N) A(I) = A(I-1) + 1
(even worse, when I first typed that in, I used I+1!)
Dick Hendrickson
| |
| Gerry Ford 2008-02-25, 10:14 pm |
|
"Dick Hendrickson" <dick.hendrickson@att.net> wrote in message
news:NhJwj.662323$kj1.109226@bgtnsc04-news.ops.worldnet.att.net...
> Sebastian Hanigk wrote:
Bitte schoen?
[color=darkred]
> That's an interesting answer. Mostly, a program is communication
> from one programmer to another (forget about the machine), where
> the "other" programmer is likely to be myself next w, and using
> the clearest coding style is usually the best. But, FORALL
> is pretty new (1995) and I think people think it has more properties
> than it really has. But, as you say, it's wonderfully expressive for
> many things, as long as it doesn't confuse people.
>
> The problem I have is that DO loops are clear and forall is
> potentially harmful either in performance or surprising effects.
> Something like
> DO I = 2,N
> A(I) = A(I-1) + 1
> ENDDO
> isn't the same as
> Forall (I = 2,N) A(I) = A(I-1) + 1
> (even worse, when I first typed that in, I used I+1!)
My notion is that purity does less for you than forall promises.
--
Gerry Ford
"Er hat sich georgiert." Der Spiegel, 2008, sich auf Chimpy Eins komma null
beziehend.
| |
| James Van Buskirk 2008-02-25, 10:14 pm |
| "Dick Hendrickson" <dick.hendrickson@att.net> wrote in message
news:NhJwj.662323$kj1.109226@bgtnsc04-news.ops.worldnet.att.net...
> Forall (I = 2,N) A(I) = A(I-1) + 1
> (even worse, when I first typed that in, I used I+1!)
Even worse than that is that the above is a syntax error.
That aside, my belief is that the upper bound should more typically
be obtained through an inquiry function as this avoids overrunning
array bounds:
do i = 2, size(A)
A(i) = A(i-1)+1
end do
Of course this is useless if the array is assumed size.
--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end
| |
| Sebastian Hanigk 2008-02-26, 4:49 am |
| Dick Hendrickson <dick.hendrickson@att.net> writes:
> But, FORALL is pretty new (1995) and I think people think it has more
> properties than it really has. But, as you say, it's wonderfully
> expressive for many things, as long as it doesn't confuse people.
Of course you have to keep in mind who will most likely read your code;
I'm having difficulties here to tell some of the older programmers the
merits of using blocks with matching ENDs and not only labels and
CONTINUE ... :-(
> The problem I have is that DO loops are clear and forall is
> potentially harmful either in performance or surprising effects.
> Something like
> DO I = 2,N
> A(I) = A(I-1) + 1
> ENDDO
> isn't the same as
> Forall (I = 2,N) A(I) = A(I-1) + 1
> (even worse, when I first typed that in, I used I+1!)
Is this FORALL statement even legal? I had the notion that you must have
pairwise independence between every index' operation.
Regarding the performance of a DO loop vs. FORALL, I still emphasise to
write the code in the most legible (depending on your audience of
course) manner and do some profiling first. As I was doing a practical
at my university, we had to write a small CFD solver and while the C
guys had to write tons of horrendous loops, I could write the Jacobi
iteration in one line due to the FORALL statement. Performance
difference between that and a DO loop was in this case a few percent,
almost insignificant.
Sebastian
| |
| glen herrmannsfeldt 2008-02-26, 8:33 am |
| Sebastian Hanigk wrote:
> Dick Hendrickson <dick.hendrickson@att.net> writes:
(snip)
[color=darkred]
> Is this FORALL statement even legal? I had the notion that you must have
> pairwise independence between every index' operation.
As far as I know, it is legal, which is one problem with FORALL.
It is defined such that all the elements on the right side are
evaluated (in any order) before all the assignments are done
(in any order). It might require a temporary array to do it.
The ordinary DO loop should never require a temporary array.
> Regarding the performance of a DO loop vs. FORALL, I still emphasise to
> write the code in the most legible (depending on your audience of
> course) manner and do some profiling first. As I was doing a practical
> at my university, we had to write a small CFD solver and while the C
> guys had to write tons of horrendous loops, I could write the Jacobi
> iteration in one line due to the FORALL statement. Performance
> difference between that and a DO loop was in this case a few percent,
> almost insignificant.
In the case of a temporary array the performance is likely
more than a few percent worse.
-- glen
| |
| Dick Hendrickson 2008-02-26, 7:23 pm |
| glen herrmannsfeldt wrote:
> Sebastian Hanigk wrote:
> (snip)
>
>
>
> As far as I know, it is legal, which is one problem with FORALL.
>
> It is defined such that all the elements on the right side are
> evaluated (in any order) before all the assignments are done
> (in any order). It might require a temporary array to do it.
>
> The ordinary DO loop should never require a temporary array.
Yes, a forall does require evaluation of the complete right
hand side before any stores happen (at least in the "as if"
sense before optimization). Forall was intended as an efficient
syntax for parallel processors. Unfortunately, the semantics are
loose enough that the compiler generally has to do a lot of
analysis before it can efficiently use parallelism. And, in
general, it is no easier to parallelize a forall block than it is
to parallelize an equivalent DO nest, and sometimes it's harder.
The safe implementation for a forall requires temporary storage
for the right hand side (assuming the same variable appears
on the right and left).
Fortran 2008 has a DO CONCURRENT block which is easier to
parallelize--basically, the programmer is not allowed to
put a non-parallelizable thing inside a DO CONCURRENT.
On vector machines DO loops can sometimes be vctorized by
using temporary arrays. It's about the same set of trade-offs
and analysis as needed for forall blocks.
Dick Hendrickson
>
>
> In the case of a temporary array the performance is likely
> more than a few percent worse.
>
> -- glen
>
| |
| James Van Buskirk 2008-02-26, 7:23 pm |
| "Dick Hendrickson" <dick.hendrickson@att.net> wrote in message
news:wp%wj.259106$MJ6.201756@bgtnsc05-news.ops.worldnet.att.net...
[color=darkred]
[color=darkred]
C'mon, it's still illegal. Try compiling it, don't just look at it.
--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end
| |
| Richard Maine 2008-02-26, 7:23 pm |
| James Van Buskirk <not_valid@comcast.net> wrote:
> "Dick Hendrickson" <dick.hendrickson@att.net> wrote in message
> news:wp%wj.259106$MJ6.201756@bgtnsc05-news.ops.worldnet.att.net...
>
>
>
> C'mon, it's still illegal. Try compiling it, don't just look at it.
Yes, but that's not the point that was being discussed. It is illegal,
but *NOT* for anything even vaguely related to the issue of this
subthread. The problem is purely syntactic - not related to any issue of
independence between elements.
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
| |
| James Van Buskirk 2008-02-26, 7:23 pm |
| "Richard Maine" <nospam@see.signature> wrote in message
news:1icxcot.1ni72h318g6gi0N%nospam@see.signature...
[color=darkred]
> Yes, but that's not the point that was being discussed. It is illegal,
> but *NOT* for anything even vaguely related to the issue of this
> subthread. The problem is purely syntactic - not related to any issue of
> independence between elements.
I thought that clarity was one of the issues of this subthread. If
it's not obvious at a glance that there is a syntax error, surely
clarity is suffering in some sense?
--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end
| |
| Dick Hendrickson 2008-02-27, 7:12 pm |
| James Van Buskirk wrote:
> "Richard Maine" <nospam@see.signature> wrote in message
> news:1icxcot.1ni72h318g6gi0N%nospam@see.signature...
>
>
>
> I thought that clarity was one of the issues of this subthread. If
> it's not obvious at a glance that there is a syntax error, surely
> clarity is suffering in some sense?
>
Sorry for all the confusion, I don't use FORALL much and
obviously messed up. I suppose there's an irony there, I was
head of the sub-group that imported FORALL into F95; you'd
have thought I'd have read the syntax then.
It's a pity that the forall "implied do" is different from the
other Fortran implied do's. The reason is that it's ambiguous
if a comma, instead of the semi-colon, is used. Something like
forall (I = 1,N,I<J) A(I) = 0
is, I think, always clear to the compiler, but it's a terrible
thing for a human to parse.
Dick Hendrickson
| |
| glen herrmannsfeldt 2008-02-27, 7:12 pm |
| Dick Hendrickson wrote:
(snip)
> It's a pity that the forall "implied do" is different from the
> other Fortran implied do's.
Maybe, but it is also a reminder that it isn't a loop construct.
(Though I also didn't notice the mistake.)
As we have been reminded, it is part of the assignment section
of the standard, not the execution control section.
> The reason is that it's ambiguous
> if a comma, instead of the semi-colon, is used. Something like
> forall (I = 1,N,I<J) A(I) = 0
> is, I think, always clear to the compiler, but it's a terrible
> thing for a human to parse.
It is not clear to compilers that allow mixing of integer and logical.
It is consistent with array assignment:
A(1:N)=0
-- glen
| |
| Toon Moene 2008-02-29, 7:17 pm |
| Dick Hendrickson wrote:
> Sorry for all the confusion, I don't use FORALL much and
> obviously messed up. I suppose there's an irony there, I was
> head of the sub-group that imported FORALL into F95; you'd
> have thought I'd have read the syntax then.
I hope you do realise that the example of FORALL is now used within the
J3 Standardisation Committee to disparage coarrays, using the (flawed,
in my opinion) "We got it wrong once, we might get it wrong again" -
with "it" being: introducing parallel concepts into the Fortran Standard.
Thanks, but no thanks.
--
Toon Moene - e-mail: toon@moene.indiv.nluug.nl - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
At home: http://moene.indiv.nluug.nl/~toon/
Progress of GNU Fortran: http://gcc.gnu.org/ml/gcc/2008-01/msg00009.html
|
|
|
|
|