It Hurts When I Do This
in [Fortran]
|
Prev: compile errors, please help.
Next: A digression
From: glen herrmannsfeldt on 21 Apr 2008 15:52 Richard Maine wrote: (snip) > I think it is much more natural that, if someone writes > X = something > then they probably want X to end up having the same size or length as > the something. I think that the resistance to this reflects being > trained in prior Fortran practice, as distinguished from ab initio > reevaluations of natural useability. Alternatively, maybe it's just that > my intuition is different. Maybe true, but until now that was common only for interpreted languages or scripting languages (which are also usually interpreted). It is sort of true for Java, mostly because of the garbage collector. PL/I varying length string variables are allocated to the maximum length (specified) and a length field indicates the current length. Java string concatenation: A=B+C; Will allocate a new string of the appropriate length, copy the concatenated string into the new string. A=A+B; or A += B; Generate the concatenated string and leave the previous string referenced by the Object reference A to be garbage collected (if there are no other references to it). In R you can assign to a subset of an array with subscripts on the left side of the =, or, if needed reallocate the array. Other than string concatenation, Java uses the new operator to request that a new Object be allocated and initialized. So, it does seem a little unusual to do reallocation without any indication requesting it for a compiled language emphasizing performance. -- glen
From: Beliavsky on 21 Apr 2008 15:53 On Apr 21, 3:13 pm, nos...(a)see.signature (Richard Maine) wrote: <snip> > I repeat my unanswered question to... (I forget who; someone else in > this thread): what about allocatable strings? It has been my observation > that the rather large majority of people intuitively expect strings to > act like the new allocatable ones will. They expect that > > string = 'hello' > > will end up with string being 4 characters in length. They have to be > carefully trained to understand how Fortran fixed-length strings work. You mean 5 characters in length :) ? Thanks for the rest of your message.
From: Beliavsky on 21 Apr 2008 16:05 On Apr 21, 3:45 pm, Arjen Markus <arjen.mar...(a)wldelft.nl> wrote: > On 21 apr, 21:13, nos...(a)see.signature (Richard Maine) wrote: > > > I think it is much more natural that, if someone writes > > > X = something > > > then they probably want X to end up having the same size or length as > > the something. I think that the resistance to this reflects being > > trained in prior Fortran practice, as distinguished from ab initio > > reevaluations of natural useability. Alternatively, maybe it's just that > > my intuition is different. > > I was rather delighted to see this feature in Fortran 2003: > It makes working with array-valued functions a lot easier and > it is something that comes very natural in dynamic (or scripting) > languages > (allocation and deallocation is hidden from the user in most if not > all of them). > > Regards, > > Arjen I currently follow the F95 standard, with a few exceptions such as [] for array constructors, so if I write A = B and array A is allocatable, array A will not need to be reallocated. Will a Fortran 2003 compiler necessarily be slower because of the extra flexibility allowed? It seems that so far this is the case. Steve Lionel wrote at http://softwareblogs.intel.com/2008/03/31/doctor-it-hurts-when-i-do-this/ "Fortran 2003, however, added a new twist. In F2003, if the allocatable array on the left of the assignment is not currently allocated with a shape matching the right-side, it is automatically deallocated (if needed) and then allocated with the correct shape. This can make code a lot cleaner as you don't have to worry about knowing the shape in advance. The downside, though, is that the checking required to support this is a lot of extra code, and applications where it is known that the array is already allocated to the correct shape don't need this check which would just slow them down. This is why Intel Fortran does not support this F2003 feature by default - you have to ask for it with the option /assume:realloc_lhs, or for Linux and Mac users, -assume realloc_lhs. ("lhs" here means "left hand side".)" For now, I plan to write code that works with the Intel default settings.
From: Dan Nagle on 21 Apr 2008 16:25 Hello, On 2008-04-21 15:13:11 -0400, nospam(a)see.signature (Richard Maine) said: > I think it is much more natural that, if someone writes > > X = something > > then they probably want X to end up having the same size or length as > the something. Try allocate( <something>, source= <something-else> ) With f08, one may use mold= in place of source= . Both of these copy length and a bunch of other stuff, such as dynamic type. -- Cheers! Dan Nagle
From: Richard Maine on 21 Apr 2008 18:25
Beliavsky <beliavsky(a)aol.com> wrote: > if I write > > A = B > > and array A is allocatable, array A will not need to be reallocated. > Will a Fortran 2003 compiler necessarily be slower because of the > extra flexibility allowed? It seems that so far this is the case. > Steve Lionel wrote... > The downside, though, is that the checking required to support this is > a lot of extra code, and applications where it is known that the array > is already allocated to the correct shape don't need this check which > would just slow them down. Steve is plenty bright... and he actually writes compilers, which I don't. So I'll assume that either there is something going on that I don't understand, or perhaps there is just a missing qualifier above about how much the slowdown would likely be. Certainly there is a test, which will presumably take a finite time. But I don't see why the amount of time should be significant. Seems like it ought to be a relatively fast test. I find it hard to image that being very significant in the compared to an array assignment of even a modest-sized array, much less a large one as might be most likely to use allocatable. Seems to me that the string case is perhaps most likely to be a significant fraction increase because short strings are common and still might "want" to be allocatable. But then, string processing isn't usually a big fraction of the time of a typical Fortran program. Of course, any compiler that does even a token job of run-time diagnostic help is presumably going to check anyway, as trying to assign to an array of the wrong size is one of those things that you'd really like a helpful compiler to be able to diagnose instead of just trashing memory. That might concievably be done only when diagnostic options are turned on, though. -- Richard Maine | Good judgement comes from experience; email: last name at domain . net | experience comes from bad judgement. domain: summertriangle | -- Mark Twain |