Re: Reading complex multidimensionalarrays from C


"Richard Maine" <nospam@xxxxxxxxxxxxx> wrote in message
news:1hxa5eb.hwhr9n15mjp7sN%nospam@xxxxxxxxxxxxxxxx
glen herrmannsfeldt <gah@xxxxxxxxxxxxxxxx> wrote:

Richard Maine wrote:

In fact, the f90 standard requires that *EVERY* real kind have a
corresponding complex kind. I have seen vendors try to rationalize that
they can support a quad precision real without also supporting a quad
precision complex, but I don't think that the rationalizations hold
up...

If one implemented REAL*16, but not SELECTED_REAL_KIND(30)
would that qualify as an extension not requiring a corresponding
COMPLEX*32?
See below.

Potentially. But I can't make a judgement about the standard conformance
of a compiler based on a hypothetical situation described in a single
sentence. I also doubt (though I'm not sure) that there is a single f90
compiler that does this, which makes the question a bit academic.

Types are pretty fundamental things and show up all over the place in
the language. I can't even come up with a list of all the potentially
relevant things. The selected_real_kind issue was just the first thing
that came to mind, not the final arbiter of whether an implementation
was standard conforming.

The real*16 syntax is nonstandard and thus a compiler can do anything
with it (as long as it has the capability to diagnose the use of the
nonstandard syntax). But supporting a particular real precision involves
a whole lot more than that one bit of syntax. Saying that a hypothetical
compiler does the syntax that way doesn't tell me anything about all the
other issues, which might come up in code not using the nonstandard
syntax.
I specifically recall what the C standard has to say about Glen's question,
if it were posed of the C language. My guess is that the wording is very
much the same in fortran. I think the spirit of it says "yes" to his
question.
--
WW


.

Relevant Pages

  • Re: Reading complex multidimensionalarrays from C
    ... precision complex, but I don't think that the rationalizations hold up... ... compiler that does this, which makes the question a bit academic. ... The real*16 syntax is nonstandard and thus a compiler can do anything ... But supporting a particular real precision involves ...
    (comp.lang.fortran)
  • Re: example of KIND to replace DOUBLE PRECISION
    ... No explicit kind numbers are specified by the standard, ... isn't even the most common choice for double precision. ... the first one - I was curious why the compiler didn't support it. ... All the syntax is unchanged; ...
    (comp.lang.fortran)
  • Re: VECTOR data types and intrinsic functions
    ... an intrinsic compiler module (so that the compiler can take care of ... Why not simply add compiler-specific support for the hardware ... The proposed new syntax has significant limitations, ... supporting auto-vectorization. ...
    (comp.lang.fortran)
  • Re: A newbie question
    ... I recommend against using such a rule. ... What I recommend is that you think about what precision is appropriate ... If you think of it as being part of the syntax ... In your case the meaning is the precision. ...
    (comp.lang.fortran)
  • Re: Conformance
    ... Note that "long double" (extended precision) is a relatively ... that FRAMEWORK and not the individual applications. ... Do you then have a syntax for specifying syntax extensions for constant ... implementation were open source. ...
    (comp.std.c)