It Hurts When I Do This
in [Fortran]
|
Prev: compile errors, please help.
Next: A digression
From: Richard Maine on 18 Apr 2008 17:43 glen herrmannsfeldt <gah(a)ugcs.caltech.edu> wrote: > I believe it is slightly more obvious that a derived type assignment > apply to the whole structure than an array name for array assignment. I just don't understand that at all. To me, they are very simillar in being data aggregates. An array is a data aggregate with homogeneous type, indexed numerically. A derived type object is a data aggregate with inhomogeneous type, indexed by name. While those differences are important, I think they are at a lower level of detail compared to the shared higher-level concept of being data aggregates. Perhaps the difference might be in whether one looks at it top-down versus bottom-up. I start out with the higher-level concept of data aggregation, where these two things look simillar. I've noticed that you describe things at an implementation level more often than I do. If one starts by looking at the implementation of these two things, then perhaps I can see that they wouldn't look as simillar as they do to me. Of course, the question of what it "obvious" is inherently subjective and perhaps hard to communicate in an objective manner. Maybe there is no better answer here than just "because". -- Richard Maine | Good judgement comes from experience; email: last name at domain . net | experience comes from bad judgement. domain: summertriangle | -- Mark Twain
From: glen herrmannsfeldt on 18 Apr 2008 18:24 Richard Maine wrote: > glen herrmannsfeldt <gah(a)ugcs.caltech.edu> wrote: >>I believe it is slightly more obvious that a derived type assignment >>apply to the whole structure than an array name for array assignment. > I just don't understand that at all. To me, they are very simillar in > being data aggregates. An array is a data aggregate with homogeneous > type, indexed numerically. A derived type object is a data aggregate > with inhomogeneous type, indexed by name. While those differences are > important, I think they are at a lower level of detail compared to the > shared higher-level concept of being data aggregates. I did say slightly. One could, for example, use a structure to represent a complex number (in C89 that would be the usual way). They could be different attributes for the same object, maybe the RGB components of color or the color of a single pixel in an image. Maybe the name, SSN, hours, and salary of an employee. (Structures seem more fundamental to COBOL than other languages.) In those cases the structure components seem more closely related than elements of an array. The attributes of one person, vs. those of a collection of different people. > Perhaps the difference might be in whether one looks at it top-down > versus bottom-up. I start out with the higher-level concept of data > aggregation, where these two things look simillar. I've noticed that you > describe things at an implementation level more often than I do. If one > starts by looking at the implementation of these two things, then > perhaps I can see that they wouldn't look as simillar as they do to me. It does seem that arrays of structures are more common that structures of arrays, but either way works. > Of course, the question of what it "obvious" is inherently subjective > and perhaps hard to communicate in an objective manner. Maybe there is > no better answer here than just "because". That might just be the one. -- glen
From: fj on 19 Apr 2008 06:47 On 18 avr, 20:32, Clive Page <j...(a)main.machine> wrote: > In message > <9bfddca3-b45a-4649-ab77-1f894baec...(a)b64g2000hsa.googlegroups.com>, > GaryScott <garylsc...(a)sbcglobal.net> writes > > >It doesn't logically follow that to ask for a syntax for arrayness > >requires a syntax for any other attributes. The article makes it > >quite clear that it is a common thought process among programmers and > >a common pitfall. > > I for one don't agree. It may be a common pitfall among programmers > used to inferior languages such as C, C++, and Java which really don't > support much beyond simple scalar operations, but surely Fortran > programmers are used to being able to use the name of an array and have > it mean the entire array. This has been standard practice in many > statements (READ, WRITE, PRINT, CALL, DATA, SUBROUTINE, FUNCTION, etc) > since Fortran-II (I think), certainly since Fortran-IV/Fortran 66. > > The main change since then is that the whole-array notation was extended > to every other appropriate context, and especially to expressions and > assignments. Of course this change came in as recently as 1990. > > I really don't think that a new notation is required just because some > programmers are a bit slow to catch on to the new thought processes > required. Of course it doesn't help that so many other languages are > still stuck in the scalar era. Perhaps it's these that need a change of > syntax? OK, so I suppose that I belong to the family of programmers who are a little bit slow ... I like to use the notation (:) to distinguish arrays to scalars and I don't agree with all the critics just because using a(:) is standard conforming. I was also very surprised about the problem of optimization met by compilers. I think that replacing "a(:)" (or "a(:,: ...)") by "a" just before parsing really the instruction is not a hard task ! Finally, using (:) or not is just a programming style and I observe again an opposition between two families of programmers (a new war similar to the famous one between programmers preferring indention with two spaces or three spaces). But I am a little bit disappointed by the new F2003 feature about automatic reallocation of allocatable arrays. I think that doing reallocation silently, just with A=B is dangerous. Why dangerous ? I don't know ... just a feeling. And I like the proposal of Glen to use the operator => for that specific subject. F. Jacq > If they supported whole-array operations, as a modern language surely > should, the problem wouldn't arise. :-) > > -- > Clive Page
From: Richard Maine on 19 Apr 2008 11:28 fj <francois.jacq(a)irsn.fr> wrote: > Finally, using (:) or not is just a programming style Mostly a style, but not always. See Steve's writeup that was linked to. It doesn't quite mean the same thing. X means the array, while X(:) means a slice of the array. The slice happens to contain all of the elements, but it is still a slice. In most contexts, the slice gives the same result as the whole array, but there are a few exceptions, and there could concievably be more in the future. One exception is that the slice is never allocatable. This effects things such as the reallocation on assignment that you mentioned. It also affects any other context where being allocatable maters. For example, if you pass X(:) as an actual argument, then the dummy better not be allocatable. Likewise, the slice is never a pointer. Another exception is in the LBOUND and UBOUND intrinsics. The lower bound of X(:) is always 1, by definition, even if the lower bound of X is something else. These are not just matters of style. They are differences in meaning. They don't come up very often (though I suspect that the allocatable one will start comming up a bit more in f2003), so one can certainly do the X(:) thing in most contexts and just be on the watchout for the cases where it doesn't work. That is a matter of programming style, I agree. > I think that replacing "a(:)" (or "a(:,: ...)") by "a" just > before parsing really the instruction is not a hard task ! It certainly cannot be done "just before parsing" because, as noted above, they don't mean the same thing. Doing a "blind" replacement wihout sufficient analysis of the context would result in incorrect compilation. -- 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 19 Apr 2008 11:52
In article <9d3c2556-3ba7-4739-b71b-baca6d483e0f(a)a22g2000hsc.googlegroups.com>, fj <francois.jacq(a)irsn.fr> wrote: > I like to use the notation (:) to distinguish arrays to scalars and I > don't agree with all the critics just because using a(:) is standard > conforming. I also like to be able to do this. Particularly if the array was not declared in the local routine (say it is in module scope, or is accessed through a USEd module). One way to achieve this is with a comment. A = B ! (:,:) This keeps the semantics that you want, it does not inhibit optimization, and it tells the human reader of the routine that an array operation is occurring. However, the compiler does not verify at runtime that the comment is correct. For example, if at some later time those arrays were changed to 1D or 3D, then your comment would be out of date but the compiler would not tell you, in contrast to the statement A(:,:)=B(:,:) where the compiler would tell you if there is an inconsistency. > I was also very surprised about the problem of optimization met by > compilers. I think that replacing "a(:)" (or "a(:,: ...)") by "a" just > before parsing really the instruction is not a hard task ! In hindsight, I think there are several problems with the array notation introduced in f90. In a perfect world, array notation would have been introduced in small pieces throughout the decade of the 80's, and these things could have been done correctly from the beginning as they were introduced to the language. But that simply did not happen, so this was never really an option. One example is that allocatable arrays play a larger and more useful role in the language than pointer arrays, but they seem to have been introduced with the opposite emphasis. In fact, the main problems with allocatable arrays were not really fixed until f2003 (or the post-f95 TR, if you count that), and there are no fully conforming f2003 compilers at present. The "problem" is that this feature was based more or less on pointer arrays in the C language, and the C language does not have allocatable arrays. Another example is that you cannot specify the array bounds with a pointer assignment such as A(-n:) => B(-n:n) There is a work around to accomplish the same thing, but this is clearly something that should have been allowed from the very beginning. It is allowed for allocatable arrays during allocation, but not pointer arrays. Fortran has allowed very flexible indexing of arrays since f77, and the introduction of pointer assignments to the language in such a way that did not allow this was very, ummm, C-like, not fortran-like. Another example is that general array expressions should have been designed in the beginning so that the array on the lhs of the expression was not allowed to appear on the rhs. A = expression involving arrays B, C, D, etc., but not A This would have allowed early compilers to replace the statement with the equivalent do-loop structure, and there would have been no penalty at all for using array notation rather than explict do-loops on any machine and for any compiler. This should have occurred in the early 80's with the first language update after f77. Then, after the optimization of these statements was mature, the restriction to allow A on the rhs could have been eliminated. As it was done, even today 18+ years after f90 was designed, there are still many compilers that cannot optimize simple array expressions as well as they do the equivalent do-loops. > Finally, using (:) or not is just a programming style and I observe > again an opposition between two families of programmers (a new war > similar to the famous one between programmers preferring indention > with two spaces or three spaces). The "problem" is that (:) is a special case of triplet/array-section notation, and triplet notation often requires special treatment. Others have already explained this pretty well, and it is clear how, once triplet notation is used in a statement, it requires extra effort to determine when array elements are contiguous, or when they are equivalent to whole-array operations, or when local copies are required, etc. > But I am a little bit disappointed by the new F2003 feature about > automatic reallocation of allocatable arrays. I think that doing > reallocation silently, just with A=B is dangerous. Why dangerous ? I > don't know ... just a feeling. > > And I like the proposal of Glen to use the operator => for that > specific subject. I also am wary that the simple A=B might cause problems. I sometimes want the compiler to tell me when there is a size mismatch because this is really an error in my code. However, I would not like the A=>B notation. To me, that means something very different than "reallocate and copy". I would have been satisfied with a more verbose notation to do this kind of reallocation and assignment. Something like REALLOCATE(A=[expression]) would have been fine with me. I don't think I will do this often enough for the extra typing to be an issue, and this would allow A=B to be reserved for simple assignments with matching sizes (and with possible warnings otherwise). $.02 -Ron Shepard |