(x + y)(1)
PGK
integer :: a
a = (x + y)(1)
Would it be so bad?
Gib Bogle
Would it be so useful?
glen herrmannsfeldt
What does it mean?
Add the two arrays and select element 1 of the sum?
In C, subscripting is an operator, along with function call,
and can be applied to any expression of the appropriate type.
Not in Fortran. You also can't subscript or substring
the return value of a function returning an array or string.
Though give the expression above, the compiler might add the
two arrays, storing the result in a temporary array, then
giving element (1) of the sum. The ability to do substrings
of string expressions is likely needed more often, though.
-- glen
Richard Maine
> PGK <graha...@gmail.com> wrote:
> > integer, dimension(:) :: x,y
> > integer :: a
>
> > a = (x + y)(1)
>
> > Would it be so bad?
>
> What does it mean?
>
> Add the two arrays and select element 1 of the sum?
For "extra credit", define all the non-trivial cases that would
inherently come along with such a feature. In particular, a feature like
this would force you to be a lot more aware of the rules that define the
bounds for array expressions. Those rules are *NOT* intuitively obvious.
They are at least simple, but neither intuitive nor obvious. The only
reason that they aren't the subject of even more debate than already
happens about them is that they almost never matter. If you defined a
construct like this, then they would matter a lot.
In particular, the question would be which element was the one with
index value 1. If all you ever think about is the most trivial cases,
then the answer will seem trivial to you. Yes, it turns out that it will
always be the first element. That answer might not be so obvious to you,
however, if x and y were dimensioned as, perhaps
integer :: x(0:n-1),y(0:n-1)
In that case, x(1) and y(1) would be the second elements because of the
lower bounds of 0. But as soon as you write x+y, that expression has a
lower bound of 1 instead of 0. Thus, if indexing that sum were allowed,
the index value of 1 for the sum would correspond to that of 0 for x and
y, which pretty much wouldn't make anyone happy; but then neither would
any of the alternatives. Note that lower bounds of 0 is still a simple
case. It gets more complicated (and less intuitive) if the lower bounds
of x and y are different, as in
integer :: x(1:n), y(0:n-1)
It gets further "interesting" if your expression becomes more
complicated, for example, if it includes array slices such as
x(2:10:3) + y(10:2:-3)
As a relatively minor point, I think there might be a syntactic
ambiguity somewhere if you allow indexing of expressions. But I'm not
inclined to take the time to check for sure.
And as Glen says, the "obvious" implementation would involve generating
a temporary array and indexing into it anyway, which would likely be
pretty inefficient.
--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
PGK
selecting element 1 of the sum was the intention of the
snippet.
Richard, thanks for the considered thought. You're
right, the definition of lower bounds would soon make
the syntax unwieldy; but I imagine ugly array section
expressions would be no more ugly than before (well Ok,
maybe just a little). I also think we can hope that a
compiler would avoid calculating the entire array.
If sections of sections were allowed you'd likely have
to set an arbitrary indexing limit too.
a = (x + y)(1:100)(1:10)(1:5)(1:5) ! I know
So I'll retreat to a position of imagining an alternate
universe where Fortran array indices must begin at 1.
Regards,
Paul
Larry Gates
> So I'll retreat to a position of imagining an alternate
> universe where Fortran array indices must begin at 1.
>
> Regards,
> Paul
That's not such a fantastic-sounding thing. The arrays I build in C begin
with the zeroeth entry, and the arrays I build in fortran begin with the
first. Then again, I might live in an alternate universe.
That would explain a lot.
Have you looked at co-arrays?
--
larry gates
There are still some other things to do, so don't think if I didn't fix
your favorite bug that your bug report is in the bit bucket. (It may be,
but don't think it. :-) Larry Wall in <72...@jpl-devvax.JPL.NASA.GOV>
jwm
I guess you can get some similar functionality with the ASSOCIATE
construct, say:
ASSOCIATE (z => x + y)
...
a = z(1) + ...
...
END ASSOCIATE
I still don't understand very well the constraints for the ASSOCIATE
construct, so maybe I'm wrong.
PGK
and it has an example using an array section. Indexing array
sections is usually banned, so it looks like ASSOCIATE has the
(x+y)(1) nature.
> ASSOCIATE (z => x + y)
> ...
> a = z(1) + ...
> ...
> END ASSOCIATE
One little thing: would z be declared already; I guess not;
like USE's rename.
Paul
jwm
z is declared in the association list:
ASSOCIATE (z => x + y[, ...])
and is defined only within the scope of the ASSOCIATE construct, so
the following would be invalid:
ASSOCIATE (z => x + y)
...
a = z(1) + ...
...
END ASSOCIATE
print *, z
Besides, there are restrictions about where the associate-name (which
in this case is z) can be used, and those are the ones I still don't
understand very well.
PGK
integer, dimension(:) :: x,y
integer, dimension(size(a)) :: temp
integer :: a
temp = (x + y)
a = temp(1)
(Apart from the limited scope of the name)
Tobias Burnus
> Is ASSOCIATE so different than a temporary?
Yes and no. That depends on the compiler implementation and optimization.
I would guess that in the case of
a = z(1) ! = (x+y)(1)
it could be either end up as
do i=1,n
tmp(i) = x(i)+y(i)
end do
a = tmp(1)
or as
a = x(1) + y(1)
The first one version is of cause much slower. I would not be surprised
if several compiler created a temporary.
Tobias
robin
news:c6388e22-026c-4e28...@l33g2000pri.googlegroups.com...
> Thanks for the comments. Yes, adding the two arrays and
> selecting element 1 of the sum was the intention of the
> snippet.
That would be fairly useless.
Why bother to compute the sum of arrays, and then discard all elements
of the sum except for the first?