f2003 compilers?
in [Fortran]
|
From: John on 13 Jan 2010 00:09 On Jan 12, 2:02 am, glen herrmannsfeldt <g...(a)ugcs.caltech.edu> wrote: > Steve Lionel <steve.lio...(a)intel.invalid> wrote: > > (snip) > > > While on the subject of allocatable characters, I've run across more > > than one customer who thought that automatic allocation should happen on > > a READ. Nice idea, but that's not the way it's written in the standard. > > Nice idea, and most interpreted languages do it. Most compiled > languages don't, as you don't know the length until you have > actually read it, at least into a buffer. > > Maybe not so bad for characters if there is a reasonable length > limit, but then someone will want automatic allocation for > reading in arrays. > > read(*,*) A > > to read in an entire file into an appropriately allocated A. > > Even more, into a two-dimensional array with the appropriate > number of rows and columns. > > -- glen Wow. Not only would I like those features on a READ, but I've used various methods to do something similar that I was never satisfied with ( eg. getting size of file and then creating a character array of that size and reading file into memory; creating linked lists; reading file sections twice (once to get sizes, then allocate, then go back and read, etc. ...); but I avoid processing all data simultaneously if I can (that is, read some, do some, read some, do some if possible). So asynchronous I/O is high on my list of desired features (We use async I/O now, but by calling C from a Fortran library of user routines). Saying this makes me feel somewhat selfish as I feel that only those with very large problem sizes get excited about async I/O and parallel processing being standardized, both of which we are really excited about (but that "big problem" criteria also defines a good chunk of those developing in Fortran). That said, we need the afore-mentioned character variable functions too. Unfortunately, we used a VERY slow library to get similar functionality a while back that simulated the ISO_VARYING_STRING functionality because we were assuming ISO_VARYING_STRING would be implemented as part of the base standard and become much more efficient (meaning we would scrub the use of the library) before too long. THAT did not go according to plan. But the way the functionality actually evolved seems preferable anyway. We could eliminate a good amount of "mixed language" use if all the new CHARACTER-related functionality was implimented in all our compilers. We end up having to make mixed-language programs or use scripts as wrappers around filters and our programs to get some of the input functionality we desire easily; and we'd really like to be able to readily do everything in Fortran instead of only the number crunching. However, what spurred me to send this is it is occuring to me that a much more obtainable way of allowing for allocation on READs would be to implement it only for a subset of I/O -- namely, NAMELIST input. My first thoughts are that it would be (relatively) easy to implement allocation at READ time for that subset of I/O functionality. But, back in the real world, I can't wait for the day when our favorite compilers are labeled "F2003 compliant". Partial implementation is the biggest complaint from my user community; not just a desire for one particular feature. And adding a set of standard libraries to Fortran for simple graphics, SQL interfacing, regular expressions, XML interfacing, and so on would go a long ways towards keeping Fortran as our primary programming language. Maybe in Fortran3xxx?
From: John on 13 Jan 2010 01:22 On Jan 13, 12:09 am, John <urbanj...(a)comcast.net> wrote: > On Jan 12, 2:02 am, glen herrmannsfeldt <g...(a)ugcs.caltech.edu> wrote: > > > > > > > Steve Lionel <steve.lio...(a)intel.invalid> wrote: > > > (snip) > > > > While on the subject of allocatable characters, I've run across more > > > than one customer who thought that automatic allocation should happen on > > > a READ. Nice idea, but that's not the way it's written in the standard. > > > Nice idea, and most interpreted languages do it. Most compiled > > languages don't, as you don't know the length until you have > > actually read it, at least into a buffer. > > > Maybe not so bad for characters if there is a reasonable length > > limit, but then someone will want automatic allocation for > > reading in arrays. > > > read(*,*) A > > > to read in an entire file into an appropriately allocated A. > > > Even more, into a two-dimensional array with the appropriate > > number of rows and columns. > > > -- glen > > Wow. Not only would I like those features on a READ, but I've used > various methods to do something similar that I was never satisfied > with > ( eg. getting size of file and then creating a character array of that > size and reading file into memory; creating linked lists; reading file > sections twice (once to get sizes, then allocate, then go back and > read, etc. ...); but I avoid processing all data simultaneously if I > can (that is, read some, do some, read some, do some if possible). So > asynchronous I/O is high on my list of desired features (We use async > I/O now, but by calling C from a Fortran library of user routines). > Saying this makes me feel somewhat selfish as I feel that only those > with very large problem sizes get excited about async I/O and parallel > processing being standardized, both of which we are really excited > about > (but that "big problem" criteria also defines a good chunk of those > developing in Fortran). > > That said, we need the afore-mentioned character variable functions > too. Unfortunately, we used a VERY slow library to get similar > functionality > a while back that > simulated the ISO_VARYING_STRING functionality because we were > assuming > ISO_VARYING_STRING would be implemented as part of the base standard > and become much more efficient (meaning we would scrub the use of the > library) before too long. THAT did not go according to plan. But the > way the functionality actually evolved seems preferable anyway. We > could eliminate a good amount of "mixed language" use if all the new > CHARACTER-related functionality was implimented in all our compilers. > We > end up having to make mixed-language programs or use scripts as > wrappers > around filters and our programs to get some of the input functionality > we > desire easily; and we'd really like to be able to readily do > everything > in Fortran instead of only the number crunching. > > However, what spurred me to send this is it is occuring to me that a > much more > obtainable way of allowing for allocation on READs would be to > implement > it only for a subset of I/O -- namely, NAMELIST input. My first > thoughts > are that it would be (relatively) easy to implement allocation at READ > time for that subset of I/O functionality. > > But, back in the real world, I can't wait for the day when our > favorite > compilers are labeled "F2003 compliant". Partial implementation is > the biggest complaint from my user community; not just a desire for > one > particular feature. > > And adding a set of standard libraries to Fortran for simple graphics, > SQL interfacing, regular expressions, XML interfacing, and so on would > go a long ways towards keeping Fortran as our primary programming > language. Maybe in Fortran3xxx? I should describe the real-world problem that would benefit from the "allocation on READ" from a NAMELIST; as I think others may face similar needs. A number of non-Fortran applications developed that were using XML for their data exchange. There developed a need for a number of Fortran programs to be able to read and write this data. A number of XML parsing libraries were evaluated and looked very promising; but would have required extensive changes to the Fortran programs, which we could not justify. But we found something surprising. It was easier to make a single program (using an existing XML parsing library) that read in the XML files and wrote them out as NAMELIST input files. Both XML and NAMELIST can easily handle multiple data sets in a file; contain blocks of data that is often skipped by some applications and not others; are self describing (label the values) and are not bssed on formatting data by columns and so on. At least in our case, we got the "best of both worlds" out of the solution. The most surprising result was that we found some users not even involved in using the Fortran programs would use the filter to convert to "NAMELIST" format for hand-editing the data; as they found the NAMELIST format easier to read and change with a text editor. Then they would use the filter to go from NAMELIST to XML and could use the XML files with their browsers and style sheets and spread sheets and XML-based applications. One issue we had was how best to handle the somewhat arbitrarily sized arrays and strings we read; so thinking about a READ that could allocate for us caught my eye. The hardest part for us was making the filters "lossless" (which was not originally specifically supposed to not be a requirement) .. How can your program, which might only read a few specific values, keep all the data in the XML element if it writes it back out? We toyed with our filter writing out duplicate data; what you would expect but another uuencoded giant string with all the original data. That was read in and written out by any application that needed to "keep everything"; you can see where an automatically allocated character variable of potentially large size would be handy here. Then the filter had to take this string, merge it with the new normal output lines and make a new "clean" XML that had all the original keywords. It worked but made for some ugly files twice as big as originals and basically just made us go "UGH". So we ended up making a "post-processor" that took the original XML file and your NAMELIST file and merged them into an "updated" XML file. The drawback is that you have to be careful to reduce the risk that the wrong two files get merged if you don't do it immediately after the NAMELIST output file is generated. So we had to add a requirement that you have a unique Id in the original XML file (which ends up being useful for tracking the XML files anyway). It was worth it and easier to implement than the alternatives, given our resources. Some Fortran codes not required to exchange data with the XML applications started using NAMELIST output as an option so they could easily change the data to XML for use with CSS style sheets and XML-based tools. So, that's why a want NAMELIST to handle dynamic allocation of arrays and strings, and read and write at least a subset of XML; which isn't as far as a stretch as you might initially think. But the real surprise to people that don't know me is that the filters are written in Fortran, And to people that do is that I got to like XML (sort of).
From: Kay Diederichs on 13 Jan 2010 08:11 Tim Prince schrieb: > steve wrote: >> On Jan 12, 1:38 pm, jfh <john.har...(a)vuw.ac.nz> wrote: >>> On Jan 11, 10:27 pm, Tobias Burnus <bur...(a)net-b.de> wrote: > >>> >>> It may be that my gfortran has been superseded: unfortunately our >>> systems people don't think updating it is their highest priority. My >>> compile-time experience is below: >> >> Works fine with 4.4.3 and 4.5.0 (aka trunk). >> At least with gfortran, it appears to be a failure >> of your systems people to adequately support >> their users. >> > > Even current RHEL/CentOS provide the hopelessly old versions of > gfortran, g++, and binutils. So there will be many installations with a > policy against putting useful versions on the default PATH. But current RHEL/CentOS also provides gfortran 4.4 as a Technology Preview (see e.g. http://rhn.redhat.com/errata/RHBA-2009-1375.html), and the example does work with that. So tell your IT people to just yum install gcc44-gfortran which will pull in all those packages that this one depends on. Then run "gfortran44". HTH, Kay
First
|
Prev
|
Pages: 1 2 3 4 5 Prev: How you can save fuel and the environment Next: gfortran and C interoperability problem |