Prev: Cannot mex with gfortran on Snow Leopard (64bit)
Next: fortran sensibility at specification order
From: glen herrmannsfeldt on 18 Oct 2009 13:12
Dan Nagle <dannagle(a)verizon.net> wrote:
(snip)

> How many folks won't use type complex, preferring to role-their-own
> complex math from two real variables, because an *initial*
> implementation of type complex, in the '70s, before compilers
> were good at inlining, went slow?

Without agreeing or disagreeing with the rest of the discussion,
sometimes it works better that way. One of the more common uses
for COMPLEX is the FFT, which much of the time is easier treating
the real and imaginary separately. (In addition to the fact that
many now might be in C89 without a complex type.)

> How many folks won't use array syntax, preferring to use
> explicit loops and index calculations, because an *initial*
> implementation of array operations went slow?

They might be getting better, but some of the things people
try to write using array operations are much harder to process
than the way they would be written with loops.

-- glen
From: Dan Nagle on 18 Oct 2009 14:48
Hello,

On 2009-10-18 13:12:13 -0400, glen herrmannsfeldt <gah(a)ugcs.caltech.edu> said:

> One of the more common uses
> for COMPLEX is the FFT, which much of the time is easier treating
> the real and imaginary separately. (In addition to the fact that
> many now might be in C89 without a complex type.)

I agree. But what changes would you make to f77 complex
as a result of these factors?

> They might be getting better, but some of the things people
> try to write using array operations are much harder to process
> than the way they would be written with loops.

Again, I agree. But the question remains, what
changes would you make as a result of these experiences?

If none, what does that say of the "we need experience with f03
before publishing f08" argument?

--
Cheers!

Dan Nagle

From: glen herrmannsfeldt on 19 Oct 2009 13:32
David Muxworthy <d.muxworthy(a)bcs.org.uk> wrote:
(snip)

> The prime reason for having a standard is, as the document itself
> says, 'to promote portability, reliability, maintainability, and
> efficient execution of Fortran programs for use on a variety of
> computing systems', including different compilers on a single
> installation. Now we have the situation that vendors are giving
> low priority to some features in f03 while already implementing
> some features from f08, so that for some years potentially every
> vendor will have its own subset of f08. What value is that for
> people wanting to write portable programs? Delaying f08 would
> make time for more uniform implementations across vendors.

It would seem not much help to those wanting portable programs
using all the features, but maybe for specific features.

There has been discussion before about standardizing extensions
to the standard. Standardizing might be the wrong word, but
the idea that different vendors generating extensions with the
same purpose should do it the same way. I would think, though,
that a draft standard might be good enough for that.

-- glen
From: Tobias Burnus on 19 Oct 2009 15:15
Am 19.10.2009 19:08, schrieb David Muxworthy:
> On 18 Oct, 13:00, Dan Nagle <danna...(a)verizon.net> wrote:
>> Again, you have not addressed *how* delaying f08
>> helps f03 at all. I doubt that you, Richard, or anyone else
>> can do so.

I think if there is no new Fortran standard (or a relatively stable
draft of it), more work is done on the last published standard (here:
Fortran 2003).

On the other hand, delaying an almost finished standard won't prevent
the (experimental) implementation of new features. I think the Fortran
2003 commandline intrinsics were implemented in several compilers before
F2003 became an official standard in 2004. And gfortran has already
added in 4.4.0 support for F2008's (LOG_)GAMMA, BESSEL_*, ... (which was
not particularly difficult since (L)GAMMA and BESJ1 etc. were available
before as vendor extension). While g95 supports coarrays.


> Now we have the situation that vendors are giving
> low priority to some features in f03 while already implementing
> some features from f08

I see this as a problem. Currently, one can already do quite a lot of
Fortran 2003 programming. As long as one restricts oneself to one
compiler, one can live with its restrictions. However, if one wants to
use several compilers ...

For instance, the IEEE modules - they work with ifort and (with
restrictions) with g95, but not with gfortran. While using type-bound
procedures works with gfortran and with ifort, but not with g95 -- and
also not all features are fully working in ifort/gfortran. (For
instance, gfortran 4.4 did not support CLASS [and used TYPE as
non-standard workaround]; ifort 11.1 does not support
"ALLOCATE(*,source=class_var)" - gfortran 4.5 does*.)

Thus, I see the advantage of having first a complete Fortran 2003
compiler before moving on. On the other hand, some Fortran 2008 features
are really useful, there is demand and especially if such a feature is a
low-hanging fruit...

At least, I slowly see Fortran 2003 to become useful as a couple of
vendors move steadily forward; thus if one restricts one to IBM, Cray;
NAG; ifort; gfortran - one can do already a lot.

My impression - which might be wrong - is that we will see in a couple
of compilers a reasonably complete coverage of both Fortran 2003 and
2008 before the work on Fortran 2013 is started.
(The reasons are that Fortran 2008 does not add so much more except of
submodules and coarrays, that F2013 work will not start soon, and that
finally the Fortran 2003 coverage is relatively large.)

Tobias

* GCC 4.5 will bring the following changes:
http://gcc.gnu.org/gcc-4.5/changes.html
Thus: A bit F2008, much F2003 (with experimental OOP support as
highlight), some diagnostic improvements, some legacy support, and work
on the performance (I/O, cross-file/-language link-time optimization, ...).


PS: Current multi-vendor status regarding F2003 and F2008:
http://doi.acm.org/10.1145/1570522.1570525
Slightly older version (F2003 only):
http://www.fortranplus.co.uk/resources/fortran_2003_compiler_support.pdf
Up to date lists for gfortran:
http://gcc.gnu.org/wiki/Fortran2003Status
http://gcc.gnu.org/wiki/Fortran2008Status
From: glen herrmannsfeldt on 20 Oct 2009 04:04
nmm1(a)cam.ac.uk wrote:
> In article <hbifa1$gv9$1(a)news.eternal-september.org>,
> Dan Nagle <dannagle(a)verizon.net> wrote:
(snip)

>>This misses the point that *the* feature most wanted
>>from f08 is coarrays.

> As I have posted several times, that is a very debatable statement.
> It may be your experience, but it isn't mine. Can you justify your
> claim that it is a general fact?

I wonder if it isn't that they are loud, but not so numerous.
That seems to occur often in political discussions.

>>Until recently, some of those now advocating delay of f08
>>were advocating separation of coarrays into an optional part 4.
>>Some claims of f08 compliance would include coarrays, some wouldn't.
>>Thus, it's mighty peculiar that, suddenly, uniformity is such
>>a high goal in the view of those favoring a delay of f08.

> There is one hell of a lot of difference between messy little
> variations with no apparent (to the user) logic to them, and a
> clean optionality based on the very obvious criterion of whether
> parallelism is available. I.e. the two variants would be Serial
> Fortran and Full Fortran.

Personally, I would rather use a language designed for parallel
programming when I needed to do parallel programming. The structure
of the programs is somewhat different. Now, one might design such
a language with the look and feel of Fortran.

I would suggest anyone interested in such look at ZPL. For some
reason ZPL looks to me a little like Pascal, and that does seem
strange, but it is fundamentally designed as a parallel language.

This reminds me of the people who want to make hardware description
languages (currently verilog and VHDL) look like serial programming
languages like C. It might be convenient to people not used to
thinking about parallel operations, but it doesn't quite work.

> In particular, note that a general, conforming, correct Fortran
> coarray program written to use multiple images will compile on a
> serial system, but will not necessarily work. I.e. even in the
> best implementations, it may well livelock, and the standard
> quite rightly leaves that unspecified. So programmers HAVE to
> know which variant they are using.

Well, that doesn't sound right. So even on a parallel machine
with N=1 it will fail?

-- glen
 |  Next  |  Last
Pages: 1 2 3
Prev: Cannot mex with gfortran on Snow Leopard (64bit)
Next: fortran sensibility at specification order