Hi there,

In many code written in Fortran 77, real*8 or real*4 were commonly used 
type declaration. similar, there are many integer*2, integer*4 type 
declaration.

I hope to know whether it is a standard declaration, and whether have 
problem when compiled using different compiler.

Any suggestion or comments will be really appreciated.

Regards,
Jinsong

On 10/29/2011 8:14 AM, Jinsong Zhao wrote:

> In many code written in Fortran 77, real*8 or real*4 were commonly used
> type declaration. similar, there are many integer*2, integer*4 type
> declaration.
>
> I hope to know whether it is a standard declaration, and whether have
> problem when compiled using different compiler.
>
> Any suggestion or comments will be really appreciated.

By no means did all f77 compilers support the real* or integer* 
extensions, which I remember as first appearing in certain IBM f66 
variants.  Past compilers for 24- and 60-bit architectures did not. The 
compiler for 36-bit architectures which I used last treated real*8 as a 
synonym for double precision.
I'm sure you already found out it's not defined in any Fortran language 
standard, and I hope you're not aiming to start a flame war.
Practically all current Fortran compilers for 32- and 64-bit 
architectures support these ancient extensions, even though the f90 
standard facilities were meant to replace them.  I don't think you can 
call it "standard" in the sense that any compiler vendor advocates it in 
preference to ANSI/ISO Fortran defined alternatives.
Lately, I've only seen the terminology "standard" applied to mean a 
particular vendor's implementation in the case of web browsers.

-- 
Tim Prince

On 2011-10-29 20:42, Tim Prince wrote:
> On 10/29/2011 8:14 AM, Jinsong Zhao wrote:
>
>> In many code written in Fortran 77, real*8 or real*4 were commonly used
>> type declaration. similar, there are many integer*2, integer*4 type
>> declaration.
>>
>> I hope to know whether it is a standard declaration, and whether have
>> problem when compiled using different compiler.
>>
>> Any suggestion or comments will be really appreciated.
>
> By no means did all f77 compilers support the real* or integer*
> extensions, which I remember as first appearing in certain IBM f66
> variants. Past compilers for 24- and 60-bit architectures did not. The
> compiler for 36-bit architectures which I used last treated real*8 as a
> synonym for double precision.
> I'm sure you already found out it's not defined in any Fortran language
> standard, and I hope you're not aiming to start a flame war.

Yes, I did not found it's defined in any Fortran language. However, it's 
in fact widely used in the past code... why I post this question here is 
I hope to be confirmed.

> Practically all current Fortran compilers for 32- and 64-bit
> architectures support these ancient extensions, even though the f90
> standard facilities were meant to replace them. I don't think you can
> call it "standard" in the sense that any compiler vendor advocates it in
> preference to ANSI/ISO Fortran defined alternatives.
> Lately, I've only seen the terminology "standard" applied to mean a
> particular vendor's implementation in the case of web browsers.

Well, "standard" is not a proper word in my question.

Thanks a lot.

Regards,
Jinsong

On 10/29/2011 02:14 PM, Jinsong Zhao wrote:
> In many code written in Fortran 77, real*8 or real*4 were commonly used
> type declaration. similar, there are many integer*2, integer*4 type
> declaration.
>
> I hope to know whether it is a standard declaration, and whether have
> problem when compiled using different compiler.
>
> Any suggestion or comments will be really appreciated.


It is not standard. It is an extension to Fortran 77 which happened to 
be adopted fairly universally, but not consistently. In other words, 
"REAL*8" is can mean different things in different compilers.

With modern Fortran you should use the "KIND" parameter, and the 
selected_real_kind() variable. Like this:


integer, parameter :: double = selected_real_kind(12)

This will give you a REAL kind with at least 12 digits of precision. You 
can then use it in your program with:

real(kind=double) :: foo

The "kind" parameter can be omitted, so if you prefer you can write:

real(double) :: foo


In some compilers, "double" will be 8, and in other compilers it will be 
something else, but in all compilers, the code will work correctly. The 
selected_real_kind() can take additional parameters to specify, for 
example, the exponent range. If the compiler cannot fulfil your request, 
the function returns a negative value:

http://gcc.gnu.org/onlinedocs/gfortran/SELECTED_005fREAL_005fKIND.html#SELECTED_005fREAL_005fKIND


Here are other kinds that might be useful to you:

! Single precision.
integer, parameter :: sing = kind(1.0)

! Double precision.
integer, parameter :: doub = selected_real_kind(12)

! Extended precision (80 format for for Intel CPUs).
integer, parameter :: extn = selected_real_kind(18)

! Quad precision (for 64-bit architectures, or with library support).
integer, parameter :: quad = selected_real_kind(24)


For my own programs, I often have another variable that chooses the 
highest available precision up to some value. For example:

integer, parameter :: wp = max(sing, doub, extn)


Then all my variable declarations say "real(wp)".

Cheers,
Daniel.

Tim Prince <tprince@computer.org> wrote:
> On 10/29/2011 8:14 AM, Jinsong Zhao wrote:

>> In many code written in Fortran 77, real*8 or real*4 were 
>> commonly used type declaration. similar, there are many 
>> integer*2, integer*4 type declaration.

No, they are not standard.  Also, even as an extension the
available sizes are system dependent.

>> I hope to know whether it is a standard declaration, and whether have
>> problem when compiled using different compiler.

>> Any suggestion or comments will be really appreciated.

> By no means did all f77 compilers support the real* or integer* 
> extensions, which I remember as first appearing in certain IBM f66 
> variants.  

As far as I know, first in the OS/360 Fortran IV compilers.
The predecessors on the word addresses 7090 likely would not
have had them, except to make porting easier.  Much of the
development of OS/360 was done on the 7090, including software
emulation.  

The OS/360 compilers support LOGICAL*1 and *4, INTEGER*2 and *4,
REAL*4, *8 and, for some compilers *16, COMPLEX*8, *16 and,
for some *32.  The only one byte type, LOGICAL*1, can't be used
with relational operators.

> Past compilers for 24- and 60-bit architectures did not. The 
> compiler for 36-bit architectures which I used last treated 
> real*8 as a  synonym for double precision.

Specifically, at least the one I remember, Fortran-10 for the PDP-10.

> I'm sure you already found out it's not defined in any Fortran language 
> standard, and I hope you're not aiming to start a flame war.
> Practically all current Fortran compilers for 32- and 64-bit 
> architectures support these ancient extensions, even though the f90 
> standard facilities were meant to replace them.  I don't think you can 
> call it "standard" in the sense that any compiler vendor advocates it in 
> preference to ANSI/ISO Fortran defined alternatives.
> Lately, I've only seen the terminology "standard" applied to mean a 
> particular vendor's implementation in the case of web browsers.

The newer ones I know of support REAL*8 but not REAL*4, presumably
the assumption is that there is no need to declare the default *4.

-- glen

On 10/29/2011 8:59 AM, glen herrmannsfeldt wrote:
> Tim Prince<tprince@computer.org>  wrote:

>
>> By no means did all f77 compilers support the real* or integer*
>> extensions, which I remember as first appearing in certain IBM f66
>> variants.
>
> As far as I know, first in the OS/360 Fortran IV compilers.
> The predecessors on the word addresses 7090 likely would not
> have had them, except to make porting easier.  Much of the
> development of OS/360 was done on the 7090, including software
> emulation.
>
> The OS/360 compilers support LOGICAL*1 and *4, INTEGER*2 and *4,
> REAL*4, *8 and, for some compilers *16, COMPLEX*8, *16 and,
> for some *32.  The only one byte type, LOGICAL*1, can't be used
> with relational operators.

I suppose other compilers which supported LOGICAL*1 supported at least 
logical relational operators, some even arithmetic operators.

>
> The newer ones I know of support REAL*8 but not REAL*4, presumably
> the assumption is that there is no need to declare the default *4.

Compilers I'm familiar with which do support REAL*4 (as a synonym for 
REAL(KIND=4) differentiate it from default REAL, in the sense that 
compile line options to change the size (and KIND) of default REAL don't 
affect REAL*4.  Note, as often reiterated here, specific KIND values 
aren't the same even among all compilers for the same CPUs.


-- 
Tim Prince

On Oct 29, 11:14=A0pm, Jinsong Zhao <jsz...@yeah.net> wrote:
> Hi there,
>
> In many code written in Fortran 77, real*8 or real*4 were commonly used
> type declaration. similar, there are many integer*2, integer*4 type
> declaration.
>
> I hope to know whether it is a standard declaration, and whether have
> problem when compiled using different compiler.
>
> Any suggestion or comments will be really appreciated.

None of those forms is standard.

Better to use plain REAL for single precision real,
and DOUBLE PRECISION for double precision real.

Even better is to use somethng like
REAL (KIND=3DKIND(1.0d0)) for double precision,
or one of the more general forms.

Other preferred forms include:
integer, parameter :: dp =3D selected_real_kind(kind(1.0d0))
real(kind=3Ddp) :: r

Jinsong Zhao <jszhao@yeah.net> wrote:

> On 2011-10-29 20:42, Tim Prince wrote:
> > On 10/29/2011 8:14 AM, Jinsong Zhao wrote:
> >
> >> In many code written in Fortran 77, real*8 or real*4 were commonly used
> >> type declaration. similar, there are many integer*2, integer*4 type
> >> declaration.
> >>
> >> I hope to know whether it is a standard declaration, and whether have
> >> problem when compiled using different compiler.
....
> > I'm sure you already found out it's not defined in any Fortran language
> > standard, and I hope you're not aiming to start a flame war.
> 
> Yes, I did not found it's defined in any Fortran language. However, it's
> in fact widely used in the past code... why I post this question here is
> I hope to be confirmed.

Did you try your compiler's option to flag non-standard usage? Almost
all current compilers have such an option. While many nonstandard things
do slip by such options, particularly things that can't easily be
detected at compile time, this one certainly should be detected.

-- 
Richard Maine                    | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle           |  -- Mark Twain

In article
<18c89430-7c41-4f27-b40a-6f913ec47d74@u24g2000pru.googlegroups.com>,
Louisa <louisa.hutch@gmail.com> writes: 

> Better to use plain REAL for single precision real,
> and DOUBLE PRECISION for double precision real.
> 
> Even better is to use somethng like
> REAL (KIND=KIND(1.0d0)) for double precision,

Note that this is essentially equivalent to DOUBLE PRECISION.  If what 
one wants is DOUBLE PRECISION, it is clearer to just say so, especially 
if one would otherwise write 

   REAL_DP (KIND=KIND(1.0d0))

where it would be confusing to change the definition but keep the name.

Tim Prince <tprince@nospamcomputer.org> wrote:

(snip, I wrote)
>> The OS/360 compilers support LOGICAL*1 and *4, INTEGER*2 and *4,
>> REAL*4, *8 and, for some compilers *16, COMPLEX*8, *16 and,
>> for some *32.  The only one byte type, LOGICAL*1, can't be used
>> with relational operators.

> I suppose other compilers which supported LOGICAL*1 supported at least 
> logical relational operators, some even arithmetic operators.

Many DEC compilers allowed conversion between LOGICAL and INTEGER.
Ones I remember, gave -1 for .TRUE. (twos complement, all bits set).

I remember a BYTE type for some PDP-11 compilers, and likely
also VAX compilers as a one byte integer type.  I think VAX also
had INTEGER*1, though I don't remember ever using it.

Fortran77 compilers came out not so long after VAX with CHARACTER,
though old Fortran 66 programs stayed around long after the
Fortran77 compiler was available.

-- glen

On 30/10/2011 1:59 a.m., Daniel Carrera wrote:

> It is not standard. It is an extension to Fortran 77 which happened to
> be adopted fairly universally, but not consistently. In other words,
> "REAL*8" is can mean different things in different compilers.
>
> With modern Fortran you should use the "KIND" parameter, and the
> selected_real_kind() variable. Like this:
>
>
> integer, parameter :: double = selected_real_kind(12)
>
> This will give you a REAL kind with at least 12 digits of precision. You
> can then use it in your program with:
>
> real(kind=double) :: foo
>
> The "kind" parameter can be omitted, so if you prefer you can write:
>
> real(double) :: foo
>
>
> In some compilers, "double" will be 8, and in other compilers it will be
> something else,

In my working life I've never met a compiler for which it is something 
else, and I'm pretty confident that in what remains of it I will never 
meet one.

Gib Bogle <g.bogle@auckland.ac.nz> wrote:

> On 30/10/2011 1:59 a.m., Daniel Carrera wrote:
> 

> > integer, parameter :: double = selected_real_kind(12)

> > In some compilers, "double" will be 8, and in other compilers it will be
> > something else,
> 
> In my working life I've never met a compiler for which it is something
> else, and I'm pretty confident that in what remains of it I will never
> meet one.

I've met multiple such compilers and expect to continue to see them. In
fact, there very first f90 compiler gave a value of 2 for double in that
csse, and the subsequent versions of that compiler, which are still
supported and actively developed, continue to do so by default.

-- 
Richard Maine                    | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle           |  -- Mark Twain

On 10/29/2011 11:18 PM, Gib Bogle wrote:
>> In some compilers, "double" will be 8, and in other compilers it will be
>> something else,
>
> In my working life I've never met a compiler for which it is something
> else, and I'm pretty confident that in what remains of it I will never
> meet one.

In the NAG compiler, single and double precision are REAL(1) and REAL(2) 
respectively (by default).

http://www.nag.co.uk/nagware/np/doc/faq.asp#FAQQ4

Cheers,
Daniel.

Gib Bogle <g.bogle@auckland.ac.nz> wrote:

(snip)
>> In some compilers, "double" will be 8, and in other compilers 
>> it will be something else,

> In my working life I've never met a compiler for which it is something 
> else, and I'm pretty confident that in what remains of it I will never 
> meet one.

I believe that was regarding the KIND values.  

I don't know if there are any where REAL*8 is single precision,
but some might want that on the Cray machines with 64 bit word
(and 64 bit single precision).

-- glen

On 30/10/2011 3:11 p.m., glen herrmannsfeldt wrote:
> Gib Bogle<g.bogle@auckland.ac.nz>  wrote:
>
> (snip)
>>> In some compilers, "double" will be 8, and in other compilers
>>> it will be something else,
>
>> In my working life I've never met a compiler for which it is something
>> else, and I'm pretty confident that in what remains of it I will never
>> meet one.
>
> I believe that was regarding the KIND values.
>
> I don't know if there are any where REAL*8 is single precision,
> but some might want that on the Cray machines with 64 bit word
> (and 64 bit single precision).

I'm not questioning the existence of such compilers, they are just not 
part of my world.

On 2011-10-29 23:45, Phillip Helbig---undress to reply wrote:
> In article
> <18c89430-7c41-4f27-b40a-6f913ec47d74@u24g2000pru.googlegroups.com>,
> Louisa<louisa.hutch@gmail.com>  writes:
>
>> Better to use plain REAL for single precision real,
>> and DOUBLE PRECISION for double precision real.
>>
>> Even better is to use somethng like
>> REAL (KIND=KIND(1.0d0)) for double precision,
>
> Note that this is essentially equivalent to DOUBLE PRECISION.  If what
> one wants is DOUBLE PRECISION, it is clearer to just say so, especially
> if one would otherwise write
>
>     REAL_DP (KIND=KIND(1.0d0))
       ~~~~~~what's it?
>
> where it would be confusing to change the definition but keep the name.
>

Gib Bogle <g.bogle@auckland.ac.nz> wrote:

> On 30/10/2011 3:11 p.m., glen herrmannsfeldt wrote:
> > Gib Bogle<g.bogle@auckland.ac.nz>  wrote:
> >
> > (snip)
> >>> In some compilers, "double" will be 8, and in other compilers
> >>> it will be something else,
> >
> >> In my working life I've never met a compiler for which it is something
> >> else, and I'm pretty confident that in what remains of it I will never
> >> meet one.
> >
> > I believe that was regarding the KIND values.
> >
> > I don't know if there are any where REAL*8 is single precision,
> > but some might want that on the Cray machines with 64 bit word
> > (and 64 bit single precision).
> 
> I'm not questioning the existence of such compilers, they are just not
> part of my world.

Well, I suppose that's fine for your purposes. But a restriction to
"your world" seems of limitted relevance to other people. After all, it
wasn't you that asked the question in this thread. If the subject was
your own code, never to be used by anyone who didn't live in a
simillarly restricted environment, that would be one thing.

But when other people ask whether something is standard and wonder
whether it will cause problems in porting between different compilers,
then I think it a lot more important to address those questions than to
note that there exist people for whom those questions don't matter.

The answers to those questions are: No, the assumption that double has
kind 8 is not standard, and yes, it will cause portability problems if
one makes that assumption. Some of the compilers for which the
assumption is incorrect are not exactly rare. They might not be ones
that you happen to use, but then as far as I'm aware, the advice wasn't
directed at you. I am also *VERY* confident that, say, my mother won't
ever be using any Fortran compilers for which double is not of kind 8
(or any Fortran compilers for which it is of kind 8 either... or
compilers for any other languages either... she's really not computer
people, using one for little more than occasional email and very light
word processing). But my mother's limitted exposure to the world of
Fortran compilers doesn't seem like very good basis for restricting
answers to people with simillar exposure.

-- 
Richard Maine                    | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle           |  -- Mark Twain

On 30/10/2011 7:34 p.m., Richard Maine wrote:

> Well, I suppose that's fine for your purposes. But a restriction to
> "your world" seems of limitted relevance to other people. After all, it
> wasn't you that asked the question in this thread. If the subject was
> your own code, never to be used by anyone who didn't live in a
> simillarly restricted environment, that would be one thing.
>
> But when other people ask whether something is standard and wonder
> whether it will cause problems in porting between different compilers,
> then I think it a lot more important to address those questions than to
> note that there exist people for whom those questions don't matter.
>
> The answers to those questions are: No, the assumption that double has
> kind 8 is not standard, and yes, it will cause portability problems if
> one makes that assumption. Some of the compilers for which the
> assumption is incorrect are not exactly rare. They might not be ones
> that you happen to use, but then as far as I'm aware, the advice wasn't
> directed at you. I am also *VERY* confident that, say, my mother won't
> ever be using any Fortran compilers for which double is not of kind 8
> (or any Fortran compilers for which it is of kind 8 either... or
> compilers for any other languages either... she's really not computer
> people, using one for little more than occasional email and very light
> word processing). But my mother's limitted exposure to the world of
> Fortran compilers doesn't seem like very good basis for restricting
> answers to people with simillar exposure.
>

;-)

On Oct 29, 11:59=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu>
wrote:

> The newer ones I know of support REAL*8 but not REAL*4, presumably
> the assumption is that there is no need to declare the default *4.

Supporting REAL*8 is only to permit ancient non-standard code to
compile.
It doesn't change the fact that the archaic *n notations are
non-standard.
It's easy enough to change REAL*8 to something standard,
such as DOUBLE PRECISION.

On Oct 30, 8:18=A0am, Gib Bogle <g.bo...@auckland.ac.nz> wrote:
> On 30/10/2011 1:59 a.m., Daniel Carrera wrote:

> > In some compilers, "double" will be 8, and in other compilers it will b=
e
> > something else,
>
> In my working life I've never met a compiler for which it is something
> else, and I'm pretty confident that in what remains of it I will never
> meet one.

Certainly Silverfrost compilers use numbers other than 4 and 8.
Those numbers are meaningless.

And even if you never "meet" such a compiler,
those that follow you may "meet" one,
in which case you code won't work (assuming that
you have persisted in writing non-portable code).

Btw, here is my "types" module, which I use in all my programs:

!**********************************************************************
!
!    types.f90  --  A module with portable real number types.
!
!
!    The types in this library are highly portable between platforms
!    and compilers. If a compiler does not support the precision you
!    want, the module gives you the next-best precision.
!
!
!    USAGE:
!
!        real(wp) :: foo = 1.03_wp
!
!    PUBLIC:
!
!        sp   --   Single precision.       (32 bits)
!        dp   --   Double precision.       (64 bits)
!        ep   --   Extended precision.     (80 bits)
!        qp   --   Quadruple precision.   (128 bits)
!        wp   --   Working precision.
!
!======================================================================
module types
     implicit none

     integer, parameter :: sp = kind(1.0)
     integer, parameter :: dp = max(sp, selected_real_kind(12))
     integer, parameter :: ep = max(dp, selected_real_kind(18))
     integer, parameter :: qp = max(ep, selected_real_kind(24))

     ! Working precision
     integer, parameter :: wp = dp

end module



If you use "real(wp)" everywhere, it becomes really easy to change the 
working precision of the entire program by changing just one line. In my 
current project almost everything is in double precision, except for a 
few bits that need to be done in quad.

Cheers,
Daniel.

In article <j8ibpc$30b$1@speranza.aioe.org>,
 glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:

> I don't know if there are any where REAL*8 is single precision,
> but some might want that on the Cray machines with 64 bit word
> (and 64 bit single precision).

That's exactly the way I remember things.  REAL*8 was the same as 
default REAL, and REAL*16 was the same as DOUBLE PRECISION.  The Cray 
was not byte addressable, it was word addressable with 64-bit words, but 
that was the way that this common, but nonstandard, syntax was mapped 
onto the hardware by the compiler.  I don't remember if this was the 
default mapping, or if you needed some compiler options to invoke it, 
but that is indeed the way things worked.

The real problems porting code to Crays was not these declarations, it 
was changing DDOT, DAXPY, DGEMM, and so on to SDOT, SAXPY, SGEMM, etc.  
And, of course, you had to be careful with floating point constants 
(1.E0 vs. 1.D0) in expressions and as actual arguments, otherwise you 
would end up doing 128-bit arithmetic when you did not intend to do so.  
You either had to convert the source code, or you had to carefully use 
PARAMETERS that had correct (e.g. REAL*8) declarations.  But all this 
could be done with some care and effort.  I maintained hundreds of 
thousands of lines of portable code this way in the 1980's.

Modern fortran, with its KIND attribute and initialization expressions, 
solves this problem in a straightforward way.  Now that we have this, 
why would anyone want to go back?  Why would anyone want to hard-code 
KIND values?  Even if you don't intend your code to be used by anyone 
but you, and on any other compiler than the one you are using right now, 
and on any other hardware than what you are using right now, it is so 
easy to write portable code with these modern features, why would anyone 
want to do anything else?

$.02 -Ron Shepard

In article <4EAD2154.8090906@gmail.com>, Daniel Carrera
<daniel@gmail.com> writes: 

>      integer, parameter :: sp = kind(1.0)
>      integer, parameter :: dp = max(sp, selected_real_kind(12))

What bothers me about such schemes is that if I want REAL and DOUBLE 
PRECISION, it is easier and clearer to specify it directly.  If I want 
the flexibility, then calling them "sp" and "dp" is confusing if the 
definition is changed to another precision.

> If you use "real(wp)" everywhere, it becomes really easy to change the 
> working precision of the entire program by changing just one line. 

Right.  However, one sometimes needs a mix of precisions.  Also, 
sometimes RELATIVE precision is important.

> In my 
> current project almost everything is in double precision, except for a 
> few bits that need to be done in quad.

Errmm, shouldn't that be at least 128 bits?  :-)

On 10/30/2011 11:49 AM, Phillip Helbig---undress to reply wrote:
>> If you use "real(wp)" everywhere, it becomes really easy to change the
>> working precision of the entire program by changing just one line.
>
> Right.  However, one sometimes needs a mix of precisions.  Also,
> sometimes RELATIVE precision is important.

What is relative precision?


>> In my
>> current project almost everything is in double precision, except for a
>> few bits that need to be done in quad.
>
> Errmm, shouldn't that be at least 128 bits?  :-)
>

Yes... that's what I mean by quad. I have a few places where I want to 
store numbers too small for a double. I could do it all in double but 
I'd have to use different units and I think I could get confused and I'd 
be more prone to making programming errors.


Cheers,
Daniel.

In article <4EAD3563.9070500@gmail.com>, Daniel Carrera
<daniel@gmail.com> writes: 

> On 10/30/2011 11:49 AM, Phillip Helbig---undress to reply wrote:
> >> If you use "real(wp)" everywhere, it becomes really easy to change the
> >> working precision of the entire program by changing just one line.
> >
> > Right.  However, one sometimes needs a mix of precisions.  Also,
> > sometimes RELATIVE precision is important.
> 
> What is relative precision?

Sometimes it is important that a subroutine uses a higher precision 
internally than the calling program, but the actual values of the 
precision aren't as important.  I've noticed this when using subroutines 
to calculate stuff based on their input values where there were roundoff 
problems (something appeared to be zero or negative when actually, 
analytically, it was positive); converting the input values to higher 
precision (and to lower precision on return) solves this problem.  The 
important thing is not the absolute precision required for the stability 
of an algorithm etc but rather the relative precision.

> >> In my
> >> current project almost everything is in double precision, except for a
> >> few bits that need to be done in quad.
> >
> > Errmm, shouldn't that be at least 128 bits?  :-)
> 
> Yes... that's what I mean by quad. I have a few places where I want to 
> store numbers too small for a double. I could do it all in double but 
> I'd have to use different units and I think I could get confused and I'd 
> be more prone to making programming errors.

Note the smiley; just an attempt at assigning a bad pun to you.  :-|

Phillip Helbig---undress to reply <helbig@astro.multiCLOTHESvax.de>
wrote:

> In article <4EAD2154.8090906@gmail.com>, Daniel Carrera
> <daniel@gmail.com> writes: 
> 
> >      integer, parameter :: sp = kind(1.0)
> >      integer, parameter :: dp = max(sp, selected_real_kind(12))
> 
> What bothers me about such schemes is that if I want REAL and DOUBLE 
> PRECISION, it is easier and clearer to specify it directly.  If I want
> the flexibility, then calling them "sp" and "dp" is confusing if the 
> definition is changed to another precision.

Except that it is a rare case that one wants single and double
precision, without caring what those precisions are. I won't say it can
never happen, but it is rare. In particular, I'd say it is far more rare
than cases where one actually should care what the precisions are, but
fails to realize it.

Needing to specify the precision, on the other kind is very common. I
spent many, many hours, probably amounting to multiple man-months of my
relative youth, in converting code that needed single precision on some
machines and double on others. (Ok, some of the code was written in ways
that made the conversion particularly messy - equivalencing things and
laying out common blocks in ways that depended on the size
relationships).

A scheme would be designed for the common case - not the rare one.
That's particularly so wwhen the common case accomodates the rare one
just fine.

Once one gets used to using the scheme, it becomes natural and I'd argue
that using REAL and DOUBLE PRECISION will not be clearer. Once people
get sufficiently used to using kinds, DOUBLE PRECISION shouldn't even be
familliar to them. And even to those who are sort of familliar with it,
you'll have to go through the whole bit about how it isn't necessarily
double the precision, but is just more precision, with double the space,
even if it might not actually use the space constructively. Also, you
have to explain that it actually is a kind of REAL, even though it
doesn't look like it, and thus that generics can't disambiguate based on
double precision and one of the real kinds. That's easy and clear? And
then, REAL will look like a real that someone forgot to specify the kind
for, perhaps suggesting that it is intended as a generic for any kind.

Much easier to just stick to the general scheme. It is *MUCH* more
flexible. It will rescue you when, for example, it turns out that
precision actually does matter to some application of your code, and
thus that you need to change single/double to double/quad. Or maybe when
you work on a machine that has a precision between single and double
(yes, they exist), which is more suitable for the purpose than going all
the way to double.

-- 
Richard Maine                    | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle           |  -- Mark Twain

In article <1k9xzim.10bqgh8qvdlvwN%nospam@see.signature>,
nospam@see.signature (Richard Maine) writes: 

> > >      integer, parameter :: sp = kind(1.0)
> > >      integer, parameter :: dp = max(sp, selected_real_kind(12))
> > 
> > What bothers me about such schemes is that if I want REAL and DOUBLE 
> > PRECISION, it is easier and clearer to specify it directly.  If I want
> > the flexibility, then calling them "sp" and "dp" is confusing if the 
> > definition is changed to another precision.
> 
> Except that it is a rare case that one wants single and double
> precision, without caring what those precisions are. I won't say it can
> never happen, but it is rare. In particular, I'd say it is far more rare
> than cases where one actually should care what the precisions are, but
> fails to realize it.

I pretty much agree with your position; my main objection is about using 
"sp" and "dp", since they (intentionally) cry out "single precision" and 
"double precision" but are designed so that the definitions can be 
changed.  Something like p_1, p_2, p_3 for various precisions would, I 
think, be better style.

Richard Maine <nospam@see.signature> wrote:

> Once one gets used to using the scheme, it becomes natural and I'd argue
> that using REAL and DOUBLE PRECISION will not be clearer. Once people
> get sufficiently used to using kinds, DOUBLE PRECISION shouldn't even be
> familliar to them. And even to those who are sort of familliar with it,
> you'll have to go through the whole bit about how it isn't necessarily
> double the precision, but is just more precision, with double the space,
> even if it might not actually use the space constructively. Also, you
> have to explain that it actually is a kind of REAL, even though it
> doesn't look like it, and thus that generics can't disambiguate based on
> double precision and one of the real kinds. That's easy and clear? And
> then, REAL will look like a real that someone forgot to specify the kind
> for, perhaps suggesting that it is intended as a generic for any kind.

Oh, and I forgot other ways in which DOUBLE PRECSION is unclear or
otherwise annoying.

There's the fact that it is just plain longish to type. I recall having
to worry about leaving sufficient room on each line so that conversion
by simple text substitution wouldn't make the lines too long. And if you
get people used to DOUBLE PRECISION as a declaration, before long you'll
run into someone who tries

  DOUBLE PRECSION COMPLEX X

which is legal in fixed source form, but doesn't do anything close to
what they undoubtedly expect. If you are lucky, they will also be using
implicit none (though using fixed source form increases the odds that
they aren't).

I just wish I could forget that DOUBLE PRECSION as a declaration ever
existed. It is associated in my mind with too many times of pain and
frustration. I sure don't encourage inflicting it on others.

-- 
Richard Maine                    | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle           |  -- Mark Twain

Phillip Helbig---undress to reply <helbig@astro.multiCLOTHESvax.de>
wrote:

> In article <1k9xzim.10bqgh8qvdlvwN%nospam@see.signature>,
> nospam@see.signature (Richard Maine) writes: 
> 
> > > >      integer, parameter :: sp = kind(1.0)
> > > >      integer, parameter :: dp = max(sp, selected_real_kind(12))
> > > 
> > > What bothers me about such schemes is that if I want REAL and DOUBLE
> > > PRECISION, it is easier and clearer to specify it directly.  If I want
> > > the flexibility, then calling them "sp" and "dp" is confusing if the
> > > definition is changed to another precision.
> > 
> > Except that it is a rare case that one wants single and double
> > precision, without caring what those precisions are. I won't say it can
> > never happen, but it is rare. In particular, I'd say it is far more rare
> > than cases where one actually should care what the precisions are, but
> > fails to realize it.
> 
> I pretty much agree with your position; my main objection is about using
> "sp" and "dp", since they (intentionally) cry out "single precision" and
> "double precision" but are designed so that the definitions can be 
> changed.  Something like p_1, p_2, p_3 for various precisions would, I
> think, be better style.

Ok. Sure. No problem there. I wasn't talking about the particular name
choices.

-- 
Richard Maine                    | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle           |  -- Mark Twain

On 10/30/2011 04:57 PM, Richard Maine wrote:
> Phillip Helbig---undress to reply<helbig@astro.multiCLOTHESvax.de>
>> I pretty much agree with your position; my main objection is about using
>> "sp" and "dp", since they (intentionally) cry out "single precision" and
>> "double precision" but are designed so that the definitions can be
>> changed.  Something like p_1, p_2, p_3 for various precisions would, I
>> think, be better style.
>
> Ok. Sure. No problem there. I wasn't talking about the particular name
> choices.

What naming scheme would you recommend? I have complete control over the 
source code and I'm always happy to make changes to develop better 
habits. Would you use names lik1 "p1", "p2", etc?

This is what I currently have:


module types
     implicit none

     integer, parameter :: sp = kind(1.0)
     integer, parameter :: dp = max(sp, selected_real_kind(12))
     integer, parameter :: ep = max(dp, selected_real_kind(18))
     integer, parameter :: qp = max(ep, selected_real_kind(24))

     ! Working precision
     integer, parameter :: wp = dp

end module



Perhaps an alternative is to do something like:


module types
     implicit none

     integer, parameter :: sp = kind(1.0)
     integer, parameter :: dp = selected_real_kind(12)
     integer, parameter :: ep = selected_real_kind(18)
     integer, parameter :: qp = selected_real_kind(24)

     integer, parameter :: p1 = dp
     integer, parameter :: p2 = max(dp, ep, qp)

end module


I don't particularly like "p1" and "p2". They don't tell me anything.

Cheers,
Daniel.

On Sun, 30 Oct 2011 17:23:30 +0100, Daniel Carrera wrote:
> 
> Perhaps an alternative is to do something like:
> 
> 
> module types
>      implicit none
> 
>      integer, parameter :: sp = kind(1.0)
>      integer, parameter :: dp = selected_real_kind(12) integer,
>      parameter :: ep = selected_real_kind(18) integer, parameter :: qp =
>      selected_real_kind(24)
> 
>      integer, parameter :: p1 = dp
>      integer, parameter :: p2 = max(dp, ep, qp)
> 
> end module
> 
> I don't particularly like "p1" and "p2". They don't tell me anything.

With gfortran on some (most?) architectures, qp is done in software
so it is very slow compared to hardware floating point.

As to names, one could encode the actual precison into the constants

integer, parameter :: p24 = kind(1.e0)  ! IEEE 754 sp
integer, parameter :: p53 = kind(1.d0)  ! IEEE 754 DP
integer, parameter :: p64 = ....
integer, parameter :: p113 = ....

The trick is how to declare an initialization expressions for
p64 and p113 that are portable.
 
-- 
steve

"Daniel Carrera" <daniel@gmail.com> wrote in message 
news:j8jtm3$o0v$1@dont-email.me...

>     integer, parameter :: dp = max(sp, selected_real_kind(12))

Why max instead of min?  There is no guarantee that increasing
precision implies increasing kind numbers.

-- 
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end

In article <j8k3bm$tqj$1@dont-email.me>,
 "James Van Buskirk" <not_valid@comcast.net> wrote:

> "Daniel Carrera" <daniel@gmail.com> wrote in message 
> news:j8jtm3$o0v$1@dont-email.me...
> 
> >     integer, parameter :: dp = max(sp, selected_real_kind(12))
> 
> Why max instead of min?  There is no guarantee that increasing
> precision implies increasing kind numbers.

That is a good point, but this doesn't work anyway since MAX() is not 
allowed in initialization expressions (at least not in the currently 
available supported standards).  Instead, you need to do the SIGN() 
trick, which is verbose and ugly, but it works with every version of 
fortran back to F90.

As far as trying to future-proof your codes when using KIND expressions, 
I think programmers should also allow for the situation in which 
different precisions occupy data types of the same size.  Although it 
was never supported in F90 (as far as I know), the VAX hardware 
supported two different 64-bit floating point types.  If F90 had been 
approved by the ANSI committee in 1984 as it should have been, that 
would have been an excellent example of the flexibility of the KIND 
approach to declare various mixed-precision arithmetic.  However, the 
standards committee drug its feet long enough (ironically DEC was one of 
the reasons for that), and DEC went out of business, so we fortran 
programmers never got the chance to write that kind of code.

Here is an excerpt from one of my precision definition modules:

   integer, parameter :: COLUMBUS_WP            = selected_real_kind(14)
   integer, parameter :: COLUMBUS_EP_REQUESTED  = selected_real_kind(17) 
   integer, parameter :: COLUMBUS_EEP_REQUESTED = selected_real_kind(30) 

   ! the following initialization expressions are equivalent to:
   !  if ( COLUMBUS_EP_REQUESTED < 0 ) then
   !     COLUMBUS_EP = COLUMBUS_WP
   !  else
   !     COLUMBUS_EP = COLUMBUS_EP_REQUESTED
   !  endif
   integer, parameter :: COLUMBUS_EP = 
(1+sign(1,COLUMBUS_EP_REQUESTED))/2 * COLUMBUS_EP_REQUESTED + & 
        &                              
(1-sign(1,COLUMBUS_EP_REQUESTED))/2 * COLUMBUS_WP
   integer, parameter :: COLUMBUS_EEP = 
(1+sign(1,COLUMBUS_EEP_REQUESTED))/2 * COLUMBUS_EEP_REQUESTED + & 
        &                               
(1-sign(1,COLUMBUS_EEP_REQUESTED))/2 * COLUMBUS_EP

Those will probably wrap in an odd way, but you should be able to see 
how it works.  This is intended to be used along with the rename clause 
of the USE statement to map these to shorter names.

   use columbus_precision_defs, only: wp=>columbus_wp, ep=>columbus_ep

On intel hardware, wp is the old real*8 and ep is the old real*10.

I might switch this in the future to a naming convention based on the 
number of mantissa bits.  A previous post shows that approach.  Like the 
above, I would do that with longer names, with the intention of renaming 
them on the use statement as above in the actual application code.

$.02 -Ron Shepard

Daniel Carrera <daniel@gmail.com> wrote:

> On 10/30/2011 04:57 PM, Richard Maine wrote:
> > Phillip Helbig---undress to reply<helbig@astro.multiCLOTHESvax.de>
> >> I pretty much agree with your position; my main objection is about using
> >> "sp" and "dp", since they (intentionally) cry out "single precision" and
> >> "double precision" but are designed so that the definitions can be
> >> changed.  Something like p_1, p_2, p_3 for various precisions would, I
> >> think, be better style.
> >
> > Ok. Sure. No problem there. I wasn't talking about the particular name
> > choices.
> 
> What naming scheme would you recommend? I have complete control over the
> source code and I'm always happy to make changes to develop better 
> habits. Would you use names lik1 "p1", "p2", etc?

I can't say I have a particularly recommended naming scheme. Here's the
one I use, but I wouldn't argue for it necessarily being good in any
abstract sense; it just happens to be the one I use. I presume the
derivations of most of the names should be obvious enough to
"old-timers". The huge majority of my declarations just use r_kind,
which is my "working precision". All the others are for special
purposes. I almost never end up using rs_kind and rd_kind, but I define
them just in case.

This stuff all well predates the standardization of C interop; note the
'92 date for the first version, which I've slightly extended
subsequently, but never otherwise felt the need to change. That shows in
some places.

I happen to like having _kind in the names for my kinds and then
omitting the kind= from the syntax, so I end up with declarations like

  real(r_kind) ....

instead of real(kind=something). I might try to come up with arguments
for that, but mostly just put it down to a personal style preference.

I don't happen to have a kind with more precision than my working kind.
I certainly understand the need for such a thing in some applications;
it just hasn't really come up as a strong requirement in mine. Which is
a good thing because I've worked with way too many compilers that didn't
support anything larger, so I'd have been in trouble if it was a strong
requirement.

! $Id: precision.f90,v 1.2 2005/12/28 22:49:13 maine Exp $
! $Name:  $

!-- precision.f90
!-- 4 Mar 92, Richard Maine: Version 1.0.
!-- 31 May 01, Richard Maine.  Added i8_kind.
!-- 21 Dec 05. Richard Maine. Added ptr_kind.

module precision

  !-- Kind constants for system-independent precision specification.
  !-- 31 May 01, Richard Maine.

  implicit none
  public

  !-- System default kinds.
  integer, parameter :: i_kind = kind(0)      !-- default integer
  integer, parameter :: rs_kind = kind(0.)    !-- real single precision
  integer, parameter :: rd_kind = kind(0.d0)  !-- real double precision

  !-- Kinds for specified real precisions.
  integer, parameter :: r4_kind = selected_real_kind(6,30)   !-- 6
digits
  integer, parameter :: r8_kind = selected_real_kind(12,30)  !-- 12
digits

  !-- Kinds for specified integer ranges.
  !-- Caveat: Not all compilers have a suitable i8_kind.
  integer, parameter :: i1_kind = selected_int_kind(2)  !-- 99 max
  integer, parameter :: i2_kind = selected_int_kind(4)  !-- 9,999 max
  integer, parameter :: i4_kind = selected_int_kind(9)  !-- 999,999,999
max
  integer, parameter :: i8_kind = selected_int_kind(18) !-- 10**18-1 max

  !-- Kind adequate to store C addresses.
  !-- Differs for 32-bit vs 64-bit. Hand-modify to i4_kind or i8_kind.
  integer, parameter :: ptr_kind = i4_kind

  !-- Kind for working real precision.
  integer, parameter :: r_kind = r8_kind

  !-- Big constants.  These are less than huge so that we have some
  !-- room for comparisons and other arithmetic without overflowing.
  integer, parameter :: big_int = huge(i_kind)/16
  real(r_kind), parameter :: r_zero = 0.
  real(r_kind), parameter :: big_real = huge(r_zero)/16.
end module precision

-- 
Richard Maine                    | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle           |  -- Mark Twain

Ron Shepard <ron-shepard@nospam.comcast.net> wrote:

(snip)
> As far as trying to future-proof your codes when using KIND expressions, 
> I think programmers should also allow for the situation in which 
> different precisions occupy data types of the same size.  Although it 
> was never supported in F90 (as far as I know), the VAX hardware 
> supported two different 64-bit floating point types.  If F90 had been 
> approved by the ANSI committee in 1984 as it should have been, that 
> would have been an excellent example of the flexibility of the KIND 
> approach to declare various mixed-precision arithmetic.  However, the 
> standards committee drug its feet long enough (ironically DEC was one of 
> the reasons for that), and DEC went out of business, so we fortran 
> programmers never got the chance to write that kind of code.

VAX/VMS was supported for many years after, but not enough that
a Fortran90 compiler ever got written.  Alpha supports the VAX
floating point formats with special load and store instruction
which convert to/from the Alpha formats.  I don't know how much
is available in Alpha Fortran, though.

VMS was then ported to Itanium, which doesn't have hardware
support for D_float and G_float as far as I know.  

-- glen

Louisa wrote:

> On Oct 29, 11:59 pm, glen herrmannsfeldt <g...@ugcs.caltech.edu>
> wrote:
> 
>> The newer ones I know of support REAL*8 but not REAL*4, presumably
>> the assumption is that there is no need to declare the default *4.
> 
> Supporting REAL*8 is only to permit ancient non-standard code to
> compile.
> It doesn't change the fact that the archaic *n notations are
> non-standard.
> It's easy enough to change REAL*8 to something standard,
> such as DOUBLE PRECISION.

One archaic *n notation is stlll standard although obsolescent: CHARACTER*8 
for example.

-- 
John Harper

On 30/10/2011 8:26 p.m., Louisa wrote:
> On Oct 30, 8:18 am, Gib Bogle<g.bo...@auckland.ac.nz>  wrote:
>> On 30/10/2011 1:59 a.m., Daniel Carrera wrote:
>
>>> In some compilers, "double" will be 8, and in other compilers it will be
>>> something else,
>>
>> In my working life I've never met a compiler for which it is something
>> else, and I'm pretty confident that in what remains of it I will never
>> meet one.
>
> Certainly Silverfrost compilers use numbers other than 4 and 8.
> Those numbers are meaningless.
>
> And even if you never "meet" such a compiler,
> those that follow you may "meet" one,
> in which case you code won't work (assuming that
> you have persisted in writing non-portable code).

We must always take care with our assumptions.  :-)

On Oct 31, 7:58=A0am, John Harper <john.har...@vuw.ac.nz> wrote:
> Louisa wrote:
> > On Oct 29, 11:59 pm, glen herrmannsfeldt <g...@ugcs.caltech.edu>
> > wrote:
>
> >> The newer ones I know of support REAL*8 but not REAL*4, presumably
> >> the assumption is that there is no need to declare the default *4.
>
> > Supporting REAL*8 is only to permit ancient non-standard code to
> > compile.
> > It doesn't change the fact that the archaic *n notations are
> > non-standard.
> > It's easy enough to change REAL*8 to something standard,
> > such as DOUBLE PRECISION.
>
> One archaic *n notation is stlll standard although obsolescent: CHARACTER=
*8
> for example.

In the context of REAL and INTEGER as in the original post
and subsequent discussions, the *n notation is archaic,
is not standard, and your comment about CHARACTER is irrelevant.

On Oct 31, 2:56=A0am, nos...@see.signature (Richard Maine) wrote:

> Oh, and I forgot other ways in which DOUBLE PRECSION is unclear or
> otherwise annoying.
>
> There's the fact that it is just plain longish to type.

Obviously not a problem.

> I recall having
> to worry about leaving sufficient room on each line so that conversion
> by simple text substitution wouldn't make the lines too long.

Not really a problem.

> And if you
> get people used to DOUBLE PRECISION as a declaration, before long you'll
> run into someone who tries
>
> =A0 DOUBLE PRECSION COMPLEX X
>
> which is legal in fixed source form,

Wasn't that a long time ago?
Free form source has been available for some 20 years now.

> I just wish I could forget that DOUBLE PRECSION as a declaration ever
> existed.

DOUBLE PRECISION is clear and unequivocal.

Louisa <louisa.hutch@gmail.com> wrote:

> On Oct 31, 2:56 am, nos...@see.signature (Richard Maine) wrote:
> 
> > Oh, and I forgot other ways in which DOUBLE PRECSION is unclear or
> > otherwise annoying.
> >
> > There's the fact that it is just plain longish to type.
> 
> Obviously not a problem.

That's an opinion. Mine is different. Maybe if your typing was as bad as
mine has gotten (as illustrated, quite by accident, in my typo of it
above), yours would be different also,

> > I recall having
> > to worry about leaving sufficient room on each line so that conversion
> > by simple text substitution wouldn't make the lines too long.
> 
> Not really a problem.

It has been for me. And I've seen the same for others.
 
> > And if you
> > get people used to DOUBLE PRECISION as a declaration, before long you'll
> > run into someone who tries
> >
> >   DOUBLE PRECSION COMPLEX X
> >
> > which is legal in fixed source form,
> 
> Wasn't that a long time ago?
> Free form source has been available for some 20 years now.

And code in fixed still hangs around today. I don't happen to like it,
but I see plenty of it.
 
> > I just wish I could forget that DOUBLE PRECSION as a declaration ever
> > existed.
> 
> DOUBLE PRECISION is clear and unequivocal.

Apparently to you. I guess you have never had to deal with people asking
questions on things they found unclear about it. I have. See my prior
posting for some of the things people have asked me about it on
occasion.

-- 
Richard Maine                    | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle           |  -- Mark Twain

Richard Maine <nospam@see.signature> wrote:
> Louisa <louisa.hutch@gmail.com> wrote:

(snip regarding DOUBLE PRECISION)
>> > There's the fact that it is just plain longish to type.

One reason I always like REAL*8.

But I do specifically remember learning to spell EQUIVALENCE.

Well, many of my first programs I would punch one day, and not
see the results until the next day.  Incentive to get it right
the first time.  
 
>> Obviously not a problem.

> That's an opinion. Mine is different. 

(snip regarding DOUBLE PRECISION COMPLEX)

>> Wasn't that a long time ago?
>> Free form source has been available for some 20 years now.

> And code in fixed still hangs around today. 
> I don't happen to like it, but I see plenty of it.

I don't mind so much, maybe I am used to it by now.

-- glen

On 10/29/2011 7:59 AM, Daniel Carrera wrote:
> On 10/29/2011 02:14 PM, Jinsong Zhao wrote:
[snip]
> ! Extended precision (80 format for for Intel CPUs).
> integer, parameter :: extn = selected_real_kind(18)

>
> Cheers,
> Daniel.

You might want to check if that still applies.
The last I knew, the older Intel CPUs that used
a separate FPU chip had the 80-bit format, but
the newer ones with the CPU and the FPU on the
same chip didn't.

Robert Miles

On Mon, 31 Oct 2011 00:06:59 -0500, Robert Miles wrote:

> On 10/29/2011 7:59 AM, Daniel Carrera wrote:
>> On 10/29/2011 02:14 PM, Jinsong Zhao wrote:
> [snip]
>> ! Extended precision (80 format for for Intel CPUs). integer, parameter
>> :: extn = selected_real_kind(18)
> 
> 
>> Cheers,
>> Daniel.
> 
> You might want to check if that still applies. The last I knew, the
> older Intel CPUs that used a separate FPU chip had the 80-bit format,
> but the newer ones with the CPU and the FPU on the same chip didn't.
> 

Nope.  Any chip that supports the i387 instruction set has the
80-bit Intel format available.  This includes a large selection
of single chip cpu+fpu products from Intel, AMD, and licensees.

On Oct 31, 11:23=A0am, nos...@see.signature (Richard Maine) wrote:
> Louisa <louisa.hu...@gmail.com> wrote:
> > On Oct 31, 2:56 am, nos...@see.signature (Richard Maine) wrote:
>
> > > Oh, and I forgot other ways in which DOUBLE PRECSION is unclear or
> > > otherwise annoying.
>
> > > There's the fact that it is just plain longish to type.
>
> > Obviously not a problem.
>
> That's an opinion. Mine is different. Maybe if your typing was as bad as
> mine has gotten (as illustrated, quite by accident, in my typo of it
> above), yours would be different also,

Your typing is obviously not the problem that you claim,
judging from your full-screen post (23 lines) to which I replied
(and to which you are replying), and your many garrulous posts
elsewhere.

> > > I recall having
> > > to worry about leaving sufficient room on each line so that conversio=
n
> > > by simple text substitution wouldn't make the lines too long.
>
> > Not really a problem.
>
> It has been for me. And I've seen the same for others.
>
> > > And if you
> > > get people used to DOUBLE PRECISION as a declaration, before long you=
'll
> > > run into someone who tries
>
> > > =A0 DOUBLE PRECSION COMPLEX X
>
> > > which is legal in fixed source form,
>
> > Wasn't that a long time ago?
> > Free form source has been available for some 20 years now.
>
> And code in fixed still hangs around today.

That's irrelevant. The code would have been thru a compiler,
and won't have "DOUBLE PRECISION COMPLEX X" in it.

> I don't happen to like it,
> but I see plenty of it.
>
> > > I just wish I could forget that DOUBLE PRECSION as a declaration ever
> > > existed.
>
> > DOUBLE PRECISION is clear and unequivocal.
>
> Apparently to you. I guess you have never had to deal with people asking
> questions on things they found unclear about it.

DOUBLE PRECISION has been clear and unequivocal for how many years?
Just picked up a fortran manual at random, dated 1971.

> I have. See my prior
> posting for some of the things people have asked me about it on
> occasion.

Well, you may have had some queries about it,
but I bet you had many more queries about other fortran
statements.

Most of the queries about DP were along the lines of
how do I get double precision complex --
a question that arose because the standard was somewhat
slack in that the feature wasn't incorporated into the standard
until fortran 90.

On 2011-10-30, Daniel Carrera <daniel@gmail.com> wrote:
> On 10/30/2011 04:57 PM, Richard Maine wrote:
>> Phillip Helbig---undress to reply<helbig@astro.multiCLOTHESvax.de>
>>> I pretty much agree with your position; my main objection is about using
>>> "sp" and "dp", since they (intentionally) cry out "single precision" and
>>> "double precision" but are designed so that the definitions can be
>>> changed.  Something like p_1, p_2, p_3 for various precisions would, I
>>> think, be better style.
>>
>> Ok. Sure. No problem there. I wasn't talking about the particular name
>> choices.
>
> What naming scheme would you recommend? I have complete control over the 
> source code and I'm always happy to make changes to develop better 
> habits. Would you use names lik1 "p1", "p2", etc?

[snip]

> Perhaps an alternative is to do something like:
>
>
> module types
>      implicit none
>
>      integer, parameter :: sp = kind(1.0)
>      integer, parameter :: dp = selected_real_kind(12)
>      integer, parameter :: ep = selected_real_kind(18)
>      integer, parameter :: qp = selected_real_kind(24)
>
>      integer, parameter :: p1 = dp
>      integer, parameter :: p2 = max(dp, ep, qp)
>
> end module
>
>
> I don't particularly like "p1" and "p2". They don't tell me anything.

Yeah, I don't particularly like p1, p2 etc. either, for the same
reason you state. OTOH, I suppose there is a possibility for confusion
in your scheme above, in that do you mean by single/double precision
Fortran single (default kind ) and double precision, or do you mean
IEEE 754? Also, since you choose "sp" to be the default kind, whereas
the other kinds are selected by the selected_real_kind intrinsic, the
result might be weird on some non-IEEE 754 platform, or more likely,
if the user uses some -fdefault-real-8 or similar compiler flag (in
which case, with the scheme above, sp == dp).

One solution would be to use the size of the floating point format,
similar to IEEE 754-2008

https://secure.wikimedia.org/wikipedia/en/wiki/IEEE_754-2008

E.g.

module real_kinds
  implicit none
  integer, parameter :: r32 = selected_real_kind(6)
  integer, parameter :: r64 = selected_real_kind(15)
  integer, parameter :: r80 = selected_real_kind(18)
  integer, parameter :: r128 = selected_real_kind(33)
  integer, parameter :: wp = r64
end module real_kinds

-- 
JB

Am 31.10.2011 07:58, schrieb JB:
> One solution would be to use the size of the floating point format,
> similar to IEEE 754-2008
>
> https://secure.wikimedia.org/wikipedia/en/wiki/IEEE_754-2008
>
> E.g.
>
> module real_kinds
>    implicit none
>    integer, parameter :: r32 = selected_real_kind(6)
>    integer, parameter :: r64 = selected_real_kind(15)
>    integer, parameter :: r80 = selected_real_kind(18)
>    integer, parameter :: r128 = selected_real_kind(33)
>    integer, parameter :: wp = r64
> end module real_kinds

If one wants IEEE 754 names, one can also directly use:

module real_kinds
   use iso_fortran_env, only: REAL32, REAL64, REAL128
   implicit none
   integer, parameter :: wp = REAL64
end module real_kinds

(Admittedly, REAL{32,64,128} only exist since Fortran 2008 - and there 
is no REAL80 parameter. If I read the Fortran Forum's F2008 status 
correctly, Intel ifort, Cray ftn and gfortran support it.)

Tobias

On 10/31/2011 08:45 AM, Tobias Burnus wrote:
> Am 31.10.2011 07:58, schrieb JB:
>> One solution would be to use the size of the floating point format,
>> similar to IEEE 754-2008
>>
>> https://secure.wikimedia.org/wikipedia/en/wiki/IEEE_754-2008
>>
>> E.g.
>>
>> module real_kinds
>> implicit none
>> integer, parameter :: r32 = selected_real_kind(6)
>> integer, parameter :: r64 = selected_real_kind(15)
>> integer, parameter :: r80 = selected_real_kind(18)
>> integer, parameter :: r128 = selected_real_kind(33)
>> integer, parameter :: wp = r64
>> end module real_kinds
>
> If one wants IEEE 754 names, one can also directly use:
>
> module real_kinds
> use iso_fortran_env, only: REAL32, REAL64, REAL128
> implicit none
> integer, parameter :: wp = REAL64
> end module real_kinds
>
> (Admittedly, REAL{32,64,128} only exist since Fortran 2008 - and there
> is no REAL80 parameter. If I read the Fortran Forum's F2008 status
> correctly, Intel ifort, Cray ftn and gfortran support it.)
>
> Tobias


Interesting. Thanks to you both.

What is the advantage of the new F2008 feature? Is it mainly so we don't 
have to use "selected_real_kind" all the time? I'm thinking of doing 
something along the lines of what Tobias just wrote:

module kinds

     ! Provides:  real32, real64, real128
     !            int8, int16, int32, int64
     use iso_fortran-env

     implicit none

     integer, parameter :: r_kind = real64
     integer, parameter :: i_kind = int32

end module


Cheers,
Daniel.

On 31/10/2011 1:00 p.m., Louisa wrote:
> On Oct 31, 7:58 am, John Harper<john.har...@vuw.ac.nz>  wrote:
>> Louisa wrote:
>>> On Oct 29, 11:59 pm, glen herrmannsfeldt<g...@ugcs.caltech.edu>
>>> wrote:
>>
>>>> The newer ones I know of support REAL*8 but not REAL*4, presumably
>>>> the assumption is that there is no need to declare the default *4.
>>
>>> Supporting REAL*8 is only to permit ancient non-standard code to
>>> compile.
>>> It doesn't change the fact that the archaic *n notations are
>>> non-standard.
>>> It's easy enough to change REAL*8 to something standard,
>>> such as DOUBLE PRECISION.
>>
>> One archaic *n notation is stlll standard although obsolescent: CHARACTER*8
>> for example.
>
> In the context of REAL and INTEGER as in the original post
> and subsequent discussions, the *n notation is archaic,
> is not standard, and your comment about CHARACTER is irrelevant.

But the largest land mammal can live for as long as 80 years.

On Oct 31, 2:56=A0am, nos...@see.signature (Richard Maine) wrote:

> Oh, and I forgot other ways in which DOUBLE PRECSION is unclear or
> otherwise annoying.
>
> There's the fact that it is just plain longish to type. I recall having
> to worry about leaving sufficient room on each line so that conversion
> by simple text substitution wouldn't make the lines too long. And if you
> get people used to DOUBLE PRECISION as a declaration, before long you'll
> run into someone who tries
>
> =A0 DOUBLE PRECSION COMPLEX X
>
> which is legal in fixed source form, but doesn't do anything close to
> what they undoubtedly expect.

That's a bit of a red herring, isn't it, because
variable names were restricted to 6 letters.

Nowadays, of course, such a statement would be acceptable in
fixed source form, but with IMPLICIT NONE the statement would be
rejected.

However, there are many reasons for not using fixed source form
nowadays.

On 10/31/2011 1:21 AM, Steven G. Kargl wrote:
> On Mon, 31 Oct 2011 00:06:59 -0500, Robert Miles wrote:
>
>> On 10/29/2011 7:59 AM, Daniel Carrera wrote:
>>> On 10/29/2011 02:14 PM, Jinsong Zhao wrote:
>> [snip]
>>> ! Extended precision (80 format for for Intel CPUs). integer, parameter
>>> :: extn = selected_real_kind(18)
>>
>>
>>> Cheers,
>>> Daniel.
>>
>> You might want to check if that still applies. The last I knew, the
>> older Intel CPUs that used a separate FPU chip had the 80-bit format,
>> but the newer ones with the CPU and the FPU on the same chip didn't.
>>
>
> Nope.  Any chip that supports the i387 instruction set has the
> 80-bit Intel format available.  This includes a large selection
> of single chip cpu+fpu products from Intel, AMD, and licensees.
>
Windows libraries, however, don't support 80-bit format, and 32-bit 
applications using those libraries are expected to set 53-bit precision. 
  The X64 Windows sets 53-bit precision before launching an application.
Intel compilers (even on linux) make an application by default which 
sets 53-bit precision.
So it's likely that many people haven't used 64-bit precision/80-bit 
format for years.  As Steven pointed out, the hardware continues to 
support it.

-- 
Tim Prince

On 31/10/2011 7:48 PM, Daniel Carrera wrote:
....
>
> What is the advantage of the new F2008 feature? Is it mainly so we don't
> have to use "selected_real_kind" all the time? I'm thinking of doing
> something along the lines of what Tobias just wrote:

Programmer requirements/familiarity/laziness around selecting data types 
based on their bitness rather than the desired characteristic of the 
data type.

> module kinds
>
> ! Provides: real32, real64, real128
> ! int8, int16, int32, int64
> use iso_fortran-env

For good practice bonus points - any use statement that references an 
intrinsic module should have an ONLY clause, or your code will 
experience much unhappiness when F2013 adds the r_kind and i_kind names 
to iso_fortran_env.

>
> implicit none
>
> integer, parameter :: r_kind = real64
> integer, parameter :: i_kind = int32
>
> end module
>
>
> Cheers,
> Daniel.

On 10/31/2011 01:39 PM, Ian Harvey wrote:
> On 31/10/2011 7:48 PM, Daniel Carrera wrote:
>> module kinds
>>
>> ! Provides: real32, real64, real128
>> ! int8, int16, int32, int64
>> use iso_fortran-env
>
> For good practice bonus points - any use statement that references an
> intrinsic module should have an ONLY clause, or your code will
> experience much unhappiness when F2013 adds the r_kind and i_kind names
> to iso_fortran_env.

Can I have multiple use lines that refer to the same module and trust 
that it will work universally?

use iso_fortran_env, only: real32, real64, real128
use iso_fortran_env, only: int8, int16, int32, int64


Cheers,
Daniel.

Daniel Carrera <daniel@gmail.com> wrote:

> Can I have multiple use lines that refer to the same module and trust
> that it will work universally?
> 
> use iso_fortran_env, only: real32, real64, real128
> use iso_fortran_env, only: int8, int16, int32, int64

Yes. That is specified in the standard.

-- 
Richard Maine                    | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle           |  -- Mark Twain

In article <4eae2d08$0$14314$882e7ee2@usenet-news.net>,
 Robert Miles <milesrf@Usenet-News.net> wrote:

> You might want to check if that still applies.
> The last I knew, the older Intel CPUs that used
> a separate FPU chip had the 80-bit format, but
> the newer ones with the CPU and the FPU on the
> same chip didn't.

I'm not sure what kind of hardware and software integration there is, 
but I have a recent i7 intel chip in my laptop and a recent version of 
gfortran and it supports 32, 64, and 80-bit floating point declarations 
(with KIND values 4, 8, and 10).  I have heard that newer gfortran 
versions support 128-bit floating point, I assume with KIND value of 16, 
but I don't know if this replaces any of the old values or is appended 
to them.

I also know that many of the old motorola Macintoshes in the 1980's 
supported 80-bit floating point through the Apple SANE library.  I don't 
know what was the hardware and software integration required for this.

In any case, 80-bit floating point support is certainly not rare in 
either the current or the past environments.

$.02 -Ron Shepard

On 10/31/2011 10:37 AM, Ron Shepard wrote:
> In article<4eae2d08$0$14314$882e7ee2@usenet-news.net>,
>   Robert Miles<milesrf@Usenet-News.net>  wrote:
>
>> You might want to check if that still applies.
>> The last I knew, the older Intel CPUs that used
>> a separate FPU chip had the 80-bit format, but
>> the newer ones with the CPU and the FPU on the
>> same chip didn't.
>
> I'm not sure what kind of hardware and software integration there is,
> but I have a recent i7 intel chip in my laptop and a recent version of
> gfortran and it supports 32, 64, and 80-bit floating point declarations
> (with KIND values 4, 8, and 10).  I have heard that newer gfortran
> versions support 128-bit floating point, I assume with KIND value of 16,
> but I don't know if this replaces any of the old values or is appended
> to them.
>

fyi, in Ada, using recent GNU GNAT ada compiler, they are called long_float
and long_long_float, I get these sizes:

-------------
with Ada.Text_IO;        use Ada.Text_IO;
procedure Test is
begin

  Put_Line ("long float Size=" & Integer'Image (Long_Float'Size) );
  Put_Line ("long long float Size=" & Integer'Image(Long_long_Float'Size) );

end Test;
--------------

$ ./test.exe
long float Size= 64
long long float Size= 96

This was compiled on windows 7 running on an i7 intel PC.

--Nasser

"Ron Shepard" <ron-shepard@NOSPAM.comcast.net> wrote in message 
news:ron-shepard-03B3B1.14484830102011@news60.forteinc.com...

> In article <j8k3bm$tqj$1@dont-email.me>,
> "James Van Buskirk" <not_valid@comcast.net> wrote:

>> "Daniel Carrera" <daniel@gmail.com> wrote in message
>> news:j8jtm3$o0v$1@dont-email.me...

>> >     integer, parameter :: dp = max(sp, selected_real_kind(12))

>> Why max instead of min?  There is no guarantee that increasing
>> precision implies increasing kind numbers.

> That is a good point, but this doesn't work anyway since MAX() is not
> allowed in initialization expressions (at least not in the currently
> available supported standards).  Instead, you need to do the SIGN()
> trick, which is verbose and ugly, but it works with every version of
> fortran back to F90.

As the inventor of the SIGN trick, I was trying to call attention to
it here.  Thanks for appending an example.

I have to quibble about your comment regarding MAX, though.  As an
elemental function, MAX has been allowed in initialization
expressions since at least f90 provided its arguments are integer or
character.  Maybe the thing you are conflating is the fact that the
MAX/MIN family of specific function names are marked with bullets in
the standard's list of specific function names, so they can't be
used as actual arguments to procedures, pointed at by procedure
pointers, nor used as a proc-interface or a proc-pointer-init in a
procedure declaration statement.

-- 
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end

"Ron Shepard" <ron-shepard@NOSPAM.comcast.net> wrote in message 
news:ron-shepard-637040.10375031102011@news60.forteinc.com...

> I'm not sure what kind of hardware and software integration there is,
> but I have a recent i7 intel chip in my laptop and a recent version of
> gfortran and it supports 32, 64, and 80-bit floating point declarations
> (with KIND values 4, 8, and 10).  I have heard that newer gfortran
> versions support 128-bit floating point, I assume with KIND value of 16,
> but I don't know if this replaces any of the old values or is appended
> to them.

Appended!  On 64-bit Windows gfortran has 4 floating point kinds and
5 integer kinds.

-- 
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end

On 10/31/2011 12:27 PM, James Van Buskirk wrote:
> "Ron Shepard"<ron-shepard@NOSPAM.comcast.net>  wrote in message
> news:ron-shepard-03B3B1.14484830102011@news60.forteinc.com...
>

>
>> That is a good point, but this doesn't work anyway since MAX() is not
>> allowed in initialization expressions (at least not in the currently
>> available supported standards).  Instead, you need to do the SIGN()
>> trick, which is verbose and ugly, but it works with every version of
>> fortran back to F90.
>
> As the inventor of the SIGN trick, I was trying to call attention to
> it here.  Thanks for appending an example.
>

I didn't see the example.  Is this different from the SIGN() trick used 
to emulate MERGE in f77, still prevalent in legacy source code?

-- 
Tim Prince

"Tim Prince" <tprince@computer.org> wrote in message 
news:9h83n1FblnU1@mid.individual.net...

> On 10/31/2011 12:27 PM, James Van Buskirk wrote:

>> As the inventor of the SIGN trick, I was trying to call attention to
>> it here.  Thanks for appending an example.

> I didn't see the example.  Is this different from the SIGN() trick used to 
> emulate MERGE in f77, still prevalent in legacy source code?

Sometimes I forget that it can be difficult to back up through
threads in some newsreaders, so I elided a block of code above.
The post I replied to was:

http://groups.google.com/group/comp.lang.fortran/msg/cedd739cb558dedd?hl=en

And indeed it demonstrated the trick of using the SIGN intrisic to
synthesize projection operators in initialization expressions.
Was this common even in f77?  It was new to me when I figured it
out.

-- 
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end

In article <ron-shepard-03B3B1.14484830102011@news60.forteinc.com>, Ron
Shepard <ron-shepard@NOSPAM.comcast.net> writes: 

> As far as trying to future-proof your codes when using KIND expressions, 
> I think programmers should also allow for the situation in which 
> different precisions occupy data types of the same size.  Although it 
> was never supported in F90 (as far as I know), the VAX hardware 
> supported two different 64-bit floating point types.  

There was never F90 on VAX.  There was F90 and F95 on Alpha.  The Alpha
chip is flexible: it can run in big-endian or little-endian mode and
some use IEEE FP with it.  On Alpha, it was little-endian (like VAX) and
still had the two (non-IEEE) floating-point types.  However, IIRC the
default was changed from D-FLOAT to G-FLOAT.  I don't think one could 
use both in the same code, though; there was a compiler option to choose 
which one to use.

In article <j8mi8m$vu7$1@dont-email.me>,
 "James Van Buskirk" <not_valid@comcast.net> wrote:

> "Ron Shepard" <ron-shepard@NOSPAM.comcast.net> wrote in message 
> news:ron-shepard-03B3B1.14484830102011@news60.forteinc.com...
> 
> > In article <j8k3bm$tqj$1@dont-email.me>,
> > "James Van Buskirk" <not_valid@comcast.net> wrote:
> 
> >> "Daniel Carrera" <daniel@gmail.com> wrote in message
> >> news:j8jtm3$o0v$1@dont-email.me...
> 
> >> >     integer, parameter :: dp = max(sp, selected_real_kind(12))
> 
> >> Why max instead of min?  There is no guarantee that increasing
> >> precision implies increasing kind numbers.
> 
> > That is a good point, but this doesn't work anyway since MAX() is not
> > allowed in initialization expressions (at least not in the currently
> > available supported standards).  Instead, you need to do the SIGN()
> > trick, which is verbose and ugly, but it works with every version of
> > fortran back to F90.
> 
> As the inventor of the SIGN trick,

I meant no offense with that "verbose and ugly" comment. ;-)

> I was trying to call attention to
> it here.  Thanks for appending an example.
> 
> I have to quibble about your comment regarding MAX, though.  As an
> elemental function, MAX has been allowed in initialization
> expressions since at least f90 provided its arguments are integer or
> character.  Maybe the thing you are conflating is the fact that the
> MAX/MIN family of specific function names are marked with bullets in
> the standard's list of specific function names, so they can't be
> used as actual arguments to procedures, pointed at by procedure
> pointers, nor used as a proc-interface or a proc-pointer-init in a
> procedure declaration statement.

I should have double checked that before posting.  I thought there was 
an easier way to do the SIGN() like thing with MAX/MIN but it was not 
allowed for that reason.  Maybe I was thinking of MERGE() or something 
similar.

I wish that there were easier ways to specify conditional values in 
parameter statements.

$.02 -Ron Shepard

Louisa <louisa.hutch@gmail.com> wrote:

> On Oct 31, 11:23 am, nos...@see.signature (Richard Maine) wrote:
> > Louisa <louisa.hu...@gmail.com> wrote:
> > > On Oct 31, 2:56 am, nos...@see.signature (Richard Maine) wrote:
> >
> > > > Oh, and I forgot other ways in which DOUBLE PRECSION is unclear or
> > > > otherwise annoying.
> >
> > > > There's the fact that it is just plain longish to type.
> >
> > > Obviously not a problem.
> >
> > That's an opinion. Mine is different. Maybe if your typing was as bad as
> > mine has gotten (as illustrated, quite by accident, in my typo of it
> > above), yours would be different also,
> 
> Your typing is obviously not the problem that you claim,
> judging from your full-screen post (23 lines) to which I replied
> (and to which you are replying), and your many garrulous posts
> elsewhere.
> 

Louisa:

It is almost never wise to deny that someone that claims to have a
problem doesn't have a problem. They have far more experience with their
life than you have, and denying that the problem is real denies the
value of their experience. Richard is a far better judge of his problems
than you are. As a former editor he knows how to recognize and correct
the typos, but doing the corrections is an undesirable expendicture of
time. FWIW I have a benign essential tremor with associated typing error
issues, and share his preference for a reduction in typing. 

<snip>


-- 
Bill Clodius
los the lost and net the pet to email

William Clodius wrote:

> 
> ... FWIW I have a benign essential tremor with associated typing error
> issues, and share [Richard's] preference for a reduction in typing.

That is one reason why I still use statement functions occasionally: they 
need less typing than the equivalent internal procedure. Another reason is 
that they can be declared inside internal procedures, but internal 
procedures can't be. (Of course internal procedures can do many things that 
statement functions can't.)

-- 
John Harper

Terence wrote:

> This comment of John encapsulates why I still use F77.
> I type FAR less, to get in a short time, an uncomplicated program that
> solves my requirement.
> It then runs in any M.S. operating system from (M.S.) year dot to current
> Version 7.
> And if I was so  inclined, such a program would probably compile and run
> in other frameworks.
> 
> I am reminded of all those early useful programs that were born in the IBM
> PC days, that sales and marketing considerations insisted had to be
> replaced regularly by a "newer", "better" version that was pretty much
> useless (or less useful). e.g. Norton utilities, Wordstar v1979 (still the
> best, most versatile editor), MS Fortran (ditto).
> 
> Gresham's law: "the bad drives out the good".
> 
> I see all these Forum questions about compiler switch options, and "what's
> wrong with my code" etc.
> I don't even HAVE compiler options. A program compiles, links and runs or
> stops and clearly displays why not and where. It's the ALGORITM in the
> program that's important to the problem to be solved.

Although I agree with Terence about (some uses of) statement functions I 
seldom still use f77. There are so many things it can't do, or can do but 
less well.  

-- John Harper

On 11/2/2011 4:40 PM, Terence wrote:

>
> Gresham's law: "the bad drives out the good".
>
> I see all these Forum questions about compiler switch options, and "what's
> wrong with my code" etc.
> I don't even HAVE compiler options. A program compiles, links and runs or
> stops and clearly displays why not and where. It's the ALGORITM in the
> program that's important to the problem to be solved.
>
>

One of the 'problems' with computer languages is that they have to be
updated every 5 years or so, by some law of ANSI or ISO or one of those
ones, the ones that are standard (experts here would know more
about this).

The standard committee is 'required' or tasked with updating the
language 'standard' on regular intervals (it seems to be every 5
years).

So, a language starts simple, and with time, improvements are
added to it, but at the same time, complexity is also added,
to make the language more fashionable and 'modern'

In 20-30 years, what started as a simple language becomes
a very complicated language and the language manual becomes
more and more thick.

This is the case not just in Fortran, but many other languages as
well. You can now do OO even in COBOL !

But still, I do not think I will use F77 now. There are
many improvements made in modern Fortran. You could always
select to use the features of the modern versions that are
easy to learn, and not use those newer and more complex features,
like OO and pointers and such?

--Nasser

Nasser M. Abbasi <nma@12000.org> wrote:

(snip)
> One of the 'problems' with computer languages is that they have to be
> updated every 5 years or so, by some law of ANSI or ISO or one of those
> ones, the ones that are standard (experts here would know more
> about this).

> The standard committee is 'required' or tasked with updating the
> language 'standard' on regular intervals (it seems to be every 5
> years).

> So, a language starts simple, and with time, improvements are
> added to it, but at the same time, complexity is also added,
> to make the language more fashionable and 'modern'

No comment on Fortran, but it does seem to me that C99 is way
more complicated than it should be.  One advantage of C, 
specifically C89, is that it is a pretty simple language.
The compiler does what you tell it, and not a lot more.

And if it doesn't do something you can always call a Fortran
subroutine to do it!  But now they added so much to C99.

Oh well.

-- glen

On 3/11/2011 10:40 a.m., Terence wrote:
> This comment of John encapsulates why I still use F77.
> I type FAR less, to get in a short time, an uncomplicated program that
> solves my requirement.
> It then runs in any M.S. operating system from (M.S.) year dot to current
> Version 7.
> And if I was so  inclined, such a program would probably compile and run in
> other frameworks.
>
> I am reminded of all those early useful programs that were born in the IBM
> PC days, that sales and marketing considerations insisted had to be replaced
> regularly by a "newer", "better" version that was pretty much useless (or
> less useful). e.g. Norton utilities, Wordstar v1979 (still the best, most
> versatile editor), MS Fortran (ditto).
>
> Gresham's law: "the bad drives out the good".
>
> I see all these Forum questions about compiler switch options, and "what's
> wrong with my code" etc.
> I don't even HAVE compiler options. A program compiles, links and runs or
> stops and clearly displays why not and where. It's the ALGORITM in the
> program that's important to the problem to be solved.
>
>

Many programs can be coded perfectly satisfactorily in Fortran77.  Many 
other programs are much better coded in Fortran90.  One thing seems 
clear: once you've tried Fortran90, you will not go back to Fortran77.

This comment of John encapsulates why I still use F77.
I type FAR less, to get in a short time, an uncomplicated program that
solves my requirement.
It then runs in any M.S. operating system from (M.S.) year dot to current
Version 7.
And if I was so  inclined, such a program would probably compile and run in
other frameworks.

I am reminded of all those early useful programs that were born in the IBM
PC days, that sales and marketing considerations insisted had to be replaced
regularly by a "newer", "better" version that was pretty much useless (or
less useful). e.g. Norton utilities, Wordstar v1979 (still the best, most
versatile editor), MS Fortran (ditto).

Gresham's law: "the bad drives out the good".

I see all these Forum questions about compiler switch options, and "what's
wrong with my code" etc.
I don't even HAVE compiler options. A program compiles, links and runs or
stops and clearly displays why not and where. It's the ALGORITM in the
program that's important to the problem to be solved.

Nasser M. Abbasi <nma@12000.org> wrote:

> One of the 'problems' with computer languages is that they have to be
> updated every 5 years or so, by some law of ANSI or ISO or one of those
> ones, the ones that are standard (experts here would know more
> about this).

No, that is simply not so. I was editor of f95 and f2003, so I have
pretty direct knowledge of this.

I know what Nasser is almost certainly thinking about. It has bits that
are close enough to make it recognizable. But he got one "little" point
wrong. It just happens that the "little" point is at the very center and
makes the whole statement just wrong.

Every 5 years the standard has to be either revised *OR* reaffirmed.
That "or reaffirmed" bit is what he missed. A reaffirmation is quite
normal. It takes maybe 5 minutes of committee time (unless it is
controversial and generates debate).

I recall, for example, the reaffirmation of the f77 standard after f90
had been published. That one was actually a bit controversial. Yes, it
did pass, and for a while f77 and f90 were both valid current standards.
(Not any more, as 5 years later f77 was not reaffirmed again).

The standards committee may seek to pursue a revision instead of
reafirmation. But that is not at all required by the ISO rules. In fact,
a revision constitutes a project that requires approval as an ISO
project. Not only isn't one required, you can't even do one without
first going through the procedures to get project approval.
Reaffirmation, on the other hand, just requires sending ISO a notice
that yes, the committee did vote to reaffirm the standard.

-- 
Richard Maine                    | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle           |  -- Mark Twain

On 11/2/2011 4:10 PM, glen herrmannsfeldt wrote:

>
> No comment on Fortran, but it does seem to me that C99 is way
> more complicated than it should be.  One advantage of C,
> specifically C89, is that it is a pretty simple language.
> The compiler does what you tell it, and not a lot more.
>
> And if it doesn't do something you can always call a Fortran
> subroutine to do it!  But now they added so much to C99.
>
> Oh well.
>
> -- glen

Hoare said, reference:

http://modula3.elegosoft.com/cm3//doc/reference/complete/html/0_0_0_91_4_9_Simplicity.html

thatif the language reference manual becomes more than 50 pages,
then the language is deemed too complex. (any one knows the size,
in pages, of the latest Fortran language manual from ISO/ANSI standard?)

also here:
http://thid.thesa.com/thid-0698-8201-th-1129-8613

"a language is too complicated if a precise, readable definition requires more than 50 pages"

It will interesting to find the size, in pages, of all the standard
languages out there. I am talking about the official ANSI/ISO RM (language
refernence manual), and compare the number of pages over the years.

btw, the early Fortran book, called

"The Fortran Automatic Coding System For The Ibm 704 Epdm by IBM, 1956"

by Backus et al, had, guess how many pages? 50 pages !

--Nasser

Richard Maine <nospam@see.signature> wrote:
> Nasser M. Abbasi <nma@12000.org> wrote:

>> One of the 'problems' with computer languages is that they have to be
>> updated every 5 years or so, by some law of ANSI or ISO or one of those
>> ones, the ones that are standard (experts here would know more
>> about this).

> No, that is simply not so. I was editor of f95 and f2003, so I have
> pretty direct knowledge of this.

OK, but which looks bettter on your resume:  "Headed the committee
the generated the new XXX standard" or "headed the committee that
decided that the previous XXX standard was just fine and didn't
need to be revised."   (or even member of such committee.)

> I know what Nasser is almost certainly thinking about. It has bits that
> are close enough to make it recognizable. But he got one "little" point
> wrong. It just happens that the "little" point is at the very center and
> makes the whole statement just wrong.

And then there is Brooks' "second system effect" where all the
features that were left out of the first system for all the good
reasons get added to the second system "because they can be."
(My words, I don't remember his words by now.)

Anyone working on large (or even medium) sized software projects
should read "Mythical Man Month."

-- glen

-- glen

Nasser M. Abbasi <nma@12000.org> wrote:

> On 11/2/2011 4:10 PM, glen herrmannsfeldt wrote:
> 
> >
> > No comment on Fortran, but it does seem to me that C99 is way
> > more complicated than it should be.  One advantage of C,
> > specifically C89, is that it is a pretty simple language.
> > The compiler does what you tell it, and not a lot more.
> >
> > And if it doesn't do something you can always call a Fortran
> > subroutine to do it!  But now they added so much to C99.
> >
> > Oh well.
> >
> > -- glen
> 
> Hoare said, reference:
> 
> <http://modula3.elegosoft.com/cm3//doc/reference/complete/html/0_0_0_91_
4_9_Simplicity.html>
> 
> thatif the language reference manual becomes more than 50 pages,
> then the language is deemed too complex. (any one knows the size,
> in pages, of the latest Fortran language manual from ISO/ANSI standard?)
> 
> also here:
> http://thid.thesa.com/thid-0698-8201-th-1129-8613
> 
> "a language is too complicated if a precise, readable definition requires
more than 50 pages"
> 
> It will interesting to find the size, in pages, of all the standard
> languages out there. I am talking about the official ANSI/ISO RM (language
> refernence manual), and compare the number of pages over the years.
> 
> btw, the early Fortran book, called
> 
> "The Fortran Automatic Coding System For The Ibm 704 Epdm by IBM, 1956"
> 
> by Backus et al, had, guess how many pages? 50 pages !
> 
> --Nasser
But in the end, in spite of his initial complaints, Hoar came to comment
favorably on Ada whose standard is far longer than fifty pages. In
practice you get to fifty pages by not clearly defining all aspects of
the language, and by leaving out useful functionality, a standard
library in particular. The lack of standard libraries was a particular
problem for Wirth's languages.

-- 
Bill Clodius
los the lost and net the pet to email

On 10/31/11 4:44 PM, Ron Shepard wrote:
> In article<j8mi8m$vu7$1@dont-email.me>,
>   "James Van Buskirk"<not_valid@comcast.net>  wrote:
>
>> "Ron Shepard"<ron-shepard@NOSPAM.comcast.net>  wrote in message
>> news:ron-shepard-03B3B1.14484830102011@news60.forteinc.com...
>>
>>> In article<j8k3bm$tqj$1@dont-email.me>,
>>> "James Van Buskirk"<not_valid@comcast.net>  wrote:
>>
>>>> "Daniel Carrera"<daniel@gmail.com>  wrote in message
>>>> news:j8jtm3$o0v$1@dont-email.me...
>>
>>>>>      integer, parameter :: dp = max(sp, selected_real_kind(12))
>>
>>>> Why max instead of min?  There is no guarantee that increasing
>>>> precision implies increasing kind numbers.
>>
>>> That is a good point, but this doesn't work anyway since MAX() is not
>>> allowed in initialization expressions (at least not in the currently
>>> available supported standards).  Instead, you need to do the SIGN()
>>> trick, which is verbose and ugly, but it works with every version of
>>> fortran back to F90.
>>
>> As the inventor of the SIGN trick,
>
> I meant no offense with that "verbose and ugly" comment. ;-)
>
>> I was trying to call attention to
>> it here.  Thanks for appending an example.
>>
>> I have to quibble about your comment regarding MAX, though.  As an
>> elemental function, MAX has been allowed in initialization
>> expressions since at least f90 provided its arguments are integer or
>> character.  Maybe the thing you are conflating is the fact that the
>> MAX/MIN family of specific function names are marked with bullets in
>> the standard's list of specific function names, so they can't be
>> used as actual arguments to procedures, pointed at by procedure
>> pointers, nor used as a proc-interface or a proc-pointer-init in a
>> procedure declaration statement.
>
> I should have double checked that before posting.  I thought there was
> an easier way to do the SIGN() like thing with MAX/MIN but it was not
> allowed for that reason.  Maybe I was thinking of MERGE() or something
> similar.
>
> I wish that there were easier ways to specify conditional values in
> parameter statements.
>
> $.02 -Ron Shepard
Maybe I'm missing something here, but I think that F95 and above allows 
the MERGE function with constant (i. e. compile time evaluable) 
arguments.  Actually F95 allows any elemental intrinsic in both 
parameter and specification statements.

Dick Hendrickson

"Dick Hendrickson" <dick.hendrickson@att.net> wrote in message 
news:9hg12mFt8rU1@mid.individual.net...

> Maybe I'm missing something here, but I think that F95 and above allows 
> the MERGE function with constant (i. e. compile time evaluable) arguments. 
> Actually F95 allows any elemental intrinsic in both parameter and 
> specification statements.

F95 has the weird restriction that it only allows elemental
intrinsics with integer or character argments in initialization
expressions.  F03 lifts this restriction and I think that is also
when transformational intrinsics were allowed in initialization
expressions.  Since the MERGE intrinsic takes a LOGICAL argument,
that excludes it from initialization expressions in F95.

Now, one thing I've wondered about in F95 is that there are
intrinsics that take an optional LOGICAL argument, like INDEX,
SCAN, and VERIFY.  Were those allowed in F95 initialization
expressions if the optional LOGICAL argument was omitted?

-- 
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end

"Tim Prince" <tprince@computer.org> wrote in message 
news:9h7ghjF8abU1@mid.individual.net...

> On 10/31/2011 1:21 AM, Steven G. Kargl wrote:

>> Nope.  Any chip that supports the i387 instruction set has the
>> 80-bit Intel format available.  This includes a large selection
>> of single chip cpu+fpu products from Intel, AMD, and licensees.

> Windows libraries, however, don't support 80-bit format, and 32-bit 
> applications using those libraries are expected to set 53-bit precision. 
> The X64 Windows sets 53-bit precision before launching an application.
> Intel compilers (even on linux) make an application by default which sets 
> 53-bit precision.
> So it's likely that many people haven't used 64-bit precision/80-bit 
> format for years.  As Steven pointed out, the hardware continues to 
> support it.

gfortran seems to start with 64-bit precision on 64-bit Windows:

C:\gfortran\clf\test80>type test80.f90
module utils
   use ISO_C_BINDING
   implicit none
   private
   public utils_init, ldmxcsr, stmxcsr, fstsw, fstcw, fldcw, &
      fclex, rdtsc, CPUID_type, cpuid
   integer(C_INT8_T) BAD_STUFF(224)
   data BAD_STUFF / &
      Z'31', Z'C0', Z'40', Z'75', Z'0A', Z'89', Z'4C', Z'24', &
      Z'08', Z'0F', Z'AE', Z'54', Z'24', Z'08', Z'C3', Z'0F', &
      Z'AE', Z'54', Z'24', Z'04', Z'C3', Z'90', Z'90', Z'90', &
      Z'90', Z'90', Z'90', Z'90', Z'90', Z'90', Z'90', Z'90', &
      Z'31', Z'C0', Z'40', Z'75', Z'0A', Z'0F', Z'AE', Z'5C', &
      Z'24', Z'08', Z'8B', Z'44', Z'24', Z'08', Z'C3', Z'50', &
      Z'0F', Z'AE', Z'1C', Z'24', Z'58', Z'C3', Z'90', Z'90', &
      Z'31', Z'C0', Z'DF', Z'E0', Z'C3', Z'90', Z'90', Z'90', &
      Z'31', Z'C0', Z'40', Z'75', Z'0A', Z'D9', Z'7C', Z'24', &
      Z'08', Z'66', Z'8B', Z'44', Z'24', Z'08', Z'C3', Z'50', &
      Z'D9', Z'3C', Z'24', Z'58', Z'C3', Z'90', Z'90', Z'90', &
      Z'90', Z'90', Z'90', Z'90', Z'90', Z'90', Z'90', Z'90', &
      Z'31', Z'C0', Z'40', Z'75', Z'0A', Z'66', Z'89', Z'4C', &
      Z'24', Z'08', Z'D9', Z'6C', Z'24', Z'08', Z'C3', Z'D9', &
      Z'6C', Z'24', Z'04', Z'C3', Z'90', Z'90', Z'90', Z'90', &
      Z'DB', Z'E2', Z'C3', Z'90', Z'90', Z'90', Z'90', Z'90', &
      Z'31', Z'C0', Z'40', Z'75', Z'0A', Z'0F', Z'31', Z'48', &
      Z'C1', Z'E2', Z'20', Z'48', Z'09', Z'D0', Z'C3', Z'0F', &
      Z'31', Z'C3', Z'90', Z'90', Z'90', Z'90', Z'90', Z'90', &
      Z'90', Z'90', Z'90', Z'90', Z'90', Z'90', Z'90', Z'90', &
      Z'31', Z'C0', Z'40', Z'75', Z'18', Z'53', Z'89', Z'D0', &
      Z'49', Z'87', Z'C8', Z'0F', Z'A2', Z'49', Z'90', Z'44', &
      Z'89', Z'00', Z'89', Z'58', Z'04', Z'89', Z'50', Z'08', &
      Z'89', Z'48', Z'0C', Z'5B', Z'C3', Z'53', Z'56', Z'8B', &
      Z'44', Z'24', Z'10', Z'8B', Z'4C', Z'24', Z'14', Z'0F', &
      Z'A2', Z'8B', Z'74', Z'24', Z'0C', Z'89', Z'06', Z'89', &
      Z'5E', Z'04', Z'89', Z'56', Z'08', Z'89', Z'4E', Z'0C', &
      Z'5E', Z'5B', Z'C3', Z'90', Z'90', Z'90', Z'90', Z'90' /
   type, bind(C) :: CPUID_type
      integer(C_INT32_T) eax
      integer(C_INT32_T) ebx
      integer(C_INT32_T) edx
      integer(C_INT32_T) ecx
   end type CPUID_type
   abstract interface
      subroutine ldmxcsr_template(source) bind(C)
         use ISO_C_BINDING
         implicit none
         integer(C_INT32_T), value :: source
      end subroutine ldmxcsr_template
      function stmxcsr_template() bind(C)
         use ISO_C_BINDING
         implicit none
         integer(C_INT32_T) :: stmxcsr_template
      end function stmxcsr_template
      function fstsw_template() bind(C)
         use ISO_C_BINDING
         implicit none
         integer(C_INT16_T) :: fstsw_template
      end function fstsw_template
      function fstcw_template() bind(C)
         use ISO_C_BINDING
         implicit none
         integer(C_INT16_T) :: fstcw_template
      end function fstcw_template
      subroutine fldcw_template(source) bind(C)
         use ISO_C_BINDING
         implicit none
         integer(C_INT16_T), value :: source
      end subroutine fldcw_template
      subroutine fclex_template() bind(C)
         use ISO_C_BINDING
         implicit none
      end subroutine fclex_template
      function rdtsc_template() bind(C)
         use ISO_C_BINDING
         implicit none
         integer(C_INT64_T) :: rdtsc_template
      end function rdtsc_template
      subroutine cpuid_template(result,eax,ecx) bind(C)
         use ISO_C_BINDING
         import CPUID_type
         implicit none
         type(CPUID_type) :: result
         integer(C_INT32_T), value :: eax
         integer(C_INT32_T), value :: ecx
      end subroutine cpuid_template
   end interface
   procedure(ldmxcsr_template), pointer :: ldmxcsr => NULL()
   procedure(stmxcsr_template), pointer :: stmxcsr => NULL()
   procedure(fstsw_template), pointer :: fstsw => NULL()
   procedure(fstcw_template), pointer :: fstcw => NULL()
   procedure(fldcw_template), pointer :: fldcw => NULL()
   procedure(fclex_template), pointer :: fclex => NULL()
   procedure(rdtsc_template), pointer :: rdtsc => NULL()
   procedure(cpuid_template), pointer :: cpuid => NULL()
   interface
      function VirtualAlloc(lpAddress, dwSize, flAllocationType, &
            flProtect) bind(C, name = 'VirtualAlloc')
         use ISO_C_BINDING
         implicit none
!GCC$ ATTRIBUTES STDCALL :: VirtualAlloc
         type(C_PTR) VirtualAlloc
         type(C_PTR), value :: lpAddress
         integer(C_SIZE_T), value :: dwSize
         integer(C_LONG), value :: flAllocationType
         integer(C_LONG), value :: flProtect
      end function VirtualAlloc
      function GetLastError() bind(C,name='GetLastError')
         use ISO_C_BINDING
         implicit none
!GCC$ ATTRIBUTES STDCALL :: GetLastError
         integer(C_LONG) GetLastError
      end function GetLastError
   end interface
   contains
      subroutine utils_init()
         type(C_PTR) address
         integer(C_INTPTR_T) temp
         integer(C_LONG) error
         integer(C_INT8_T), pointer :: temp_ptr(:)
         type(C_FUNPTR) fun_address
         logical :: first = .TRUE.

         if(.NOT.first) return
         first = .FALSE.
         address = VirtualAlloc(C_NULL_PTR, &
            size(BAD_STUFF,kind=C_SIZE_T),int(Z'1000',C_LONG), &
            int(Z'40',C_LONG))
         if(.NOT.C_ASSOCIATED(address)) then
            error = GetLastError()
            write(*,'(a,z0,a)') "Error Z'",error,"' allocating memory"
            stop
         end if
         call C_F_POINTER(address, temp_ptr, shape(BAD_STUFF))
         temp_ptr = BAD_STUFF
         temp = transfer(address, temp)
         fun_address = transfer(temp, fun_address)
         call C_F_PROCPOINTER(fun_address, ldmxcsr)
         temp = temp+32
         fun_address = transfer(temp, fun_address)
         call C_F_PROCPOINTER(fun_address, stmxcsr)
         temp = temp+24
         fun_address = transfer(temp, fun_address)
         call C_F_PROCPOINTER(fun_address, fstsw)
         temp = temp+8
         fun_address = transfer(temp, fun_address)
         call C_F_PROCPOINTER(fun_address, fstcw)
         temp = temp+32
         fun_address = transfer(temp, fun_address)
         call C_F_PROCPOINTER(fun_address, fldcw)
         temp = temp+24
         fun_address = transfer(temp, fun_address)
         call C_F_PROCPOINTER(fun_address, fclex)
         temp = temp+8
         fun_address = transfer(temp, fun_address)
         call C_F_PROCPOINTER(fun_address, rdtsc)
         temp = temp+32
         fun_address = transfer(temp, fun_address)
         call C_F_PROCPOINTER(fun_address, cpuid)
      end subroutine utils_init
end module utils

program test80
   use utils, only: utils_init, fstcw
   use ISO_C_BINDING, only: C_INT16_T,C_INTPTR_T
   implicit none
   integer, parameter :: ep = selected_real_kind(18,4931)
   real(ep) x
   integer(C_INT16_T) fcw
   integer fpc
   character*100,parameter :: PCs(0:3)=[character*100:: &
      'Single Precision (24 bits)', &
      'Reserved', &
      'Double Precision (53 bits)', &
      'Double Extended Precision (64 bits)']

   call utils_init
   write(*,'(a,i0,a)') 'This is a ', &
      bit_size(0_C_INTPTR_T), '-bit Fortran processor.'
   write(*,'(3(a,i0:";",1x))') 'Kind = ', kind(x), &
              'Precision = ', precision(x), &
              'Range = ', range(x)
   fcw = fstcw()
   fpc = ibits(fcw,8,2)
   write(*,'(a,i0)') 'Precision Control = ', fpc
   write(*,'(a)') 'Description = '//trim(PCs(fpc))
end program test80

C:\gfortran\clf\test80>gfortran -fno-range-check test80.f90 -otest80

C:\gfortran\clf\test80>test80
This is a 64-bit Fortran processor.
Kind = 10; Precision = 18; Range = 4931
Precision Control = 3
Description = Double Extended Precision (64 bits)

-- 
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end

On 11/3/2011 3:47 PM, James Van Buskirk wrote:
> "Tim Prince"<tprince@computer.org>  wrote in message
> news:9h7ghjF8abU1@mid.individual.net...
>
>> On 10/31/2011 1:21 AM, Steven G. Kargl wrote:
>
>>> Nope.  Any chip that supports the i387 instruction set has the
>>> 80-bit Intel format available.  This includes a large selection
>>> of single chip cpu+fpu products from Intel, AMD, and licensees.
>
>> Windows libraries, however, don't support 80-bit format, and 32-bit
>> applications using those libraries are expected to set 53-bit precision.
>> The X64 Windows sets 53-bit precision before launching an application.
>> Intel compilers (even on linux) make an application by default which sets
>> 53-bit precision.
>> So it's likely that many people haven't used 64-bit precision/80-bit
>> format for years.  As Steven pointed out, the hardware continues to
>> support it.
>
> gfortran seems to start with 64-bit precision on 64-bit Windows:
>
> C:\gfortran\clf\test80>type test80.f90
> module utils
>     use ISO_C_BINDING
>     implicit none
>     private
>     public utils_init, ldmxcsr, stmxcsr, fstsw, fstcw, fldcw,&
>        fclex, rdtsc, CPUID_type, cpuid
>     integer(C_INT8_T) BAD_STUFF(224)
>     data BAD_STUFF /&
>        Z'31', Z'C0', Z'40', Z'75', Z'0A', Z'89', Z'4C', Z'24',&
>        Z'08', Z'0F', Z'AE', Z'54', Z'24', Z'08', Z'C3', Z'0F',&
>        Z'AE', Z'54', Z'24', Z'04', Z'C3', Z'90', Z'90', Z'90',&
>        Z'90', Z'90', Z'90', Z'90', Z'90', Z'90', Z'90', Z'90',&
>        Z'31', Z'C0', Z'40', Z'75', Z'0A', Z'0F', Z'AE', Z'5C',&
>        Z'24', Z'08', Z'8B', Z'44', Z'24', Z'08', Z'C3', Z'50',&
>        Z'0F', Z'AE', Z'1C', Z'24', Z'58', Z'C3', Z'90', Z'90',&
>        Z'31', Z'C0', Z'DF', Z'E0', Z'C3', Z'90', Z'90', Z'90',&
>        Z'31', Z'C0', Z'40', Z'75', Z'0A', Z'D9', Z'7C', Z'24',&
>        Z'08', Z'66', Z'8B', Z'44', Z'24', Z'08', Z'C3', Z'50',&
>        Z'D9', Z'3C', Z'24', Z'58', Z'C3', Z'90', Z'90', Z'90',&
>        Z'90', Z'90', Z'90', Z'90', Z'90', Z'90', Z'90', Z'90',&
>        Z'31', Z'C0', Z'40', Z'75', Z'0A', Z'66', Z'89', Z'4C',&
>        Z'24', Z'08', Z'D9', Z'6C', Z'24', Z'08', Z'C3', Z'D9',&
>        Z'6C', Z'24', Z'04', Z'C3', Z'90', Z'90', Z'90', Z'90',&
>        Z'DB', Z'E2', Z'C3', Z'90', Z'90', Z'90', Z'90', Z'90',&
>        Z'31', Z'C0', Z'40', Z'75', Z'0A', Z'0F', Z'31', Z'48',&
>        Z'C1', Z'E2', Z'20', Z'48', Z'09', Z'D0', Z'C3', Z'0F',&
>        Z'31', Z'C3', Z'90', Z'90', Z'90', Z'90', Z'90', Z'90',&
>        Z'90', Z'90', Z'90', Z'90', Z'90', Z'90', Z'90', Z'90',&
>        Z'31', Z'C0', Z'40', Z'75', Z'18', Z'53', Z'89', Z'D0',&
>        Z'49', Z'87', Z'C8', Z'0F', Z'A2', Z'49', Z'90', Z'44',&
>        Z'89', Z'00', Z'89', Z'58', Z'04', Z'89', Z'50', Z'08',&
>        Z'89', Z'48', Z'0C', Z'5B', Z'C3', Z'53', Z'56', Z'8B',&
>        Z'44', Z'24', Z'10', Z'8B', Z'4C', Z'24', Z'14', Z'0F',&
>        Z'A2', Z'8B', Z'74', Z'24', Z'0C', Z'89', Z'06', Z'89',&
>        Z'5E', Z'04', Z'89', Z'56', Z'08', Z'89', Z'4E', Z'0C',&
>        Z'5E', Z'5B', Z'C3', Z'90', Z'90', Z'90', Z'90', Z'90' /
>     type, bind(C) :: CPUID_type
>        integer(C_INT32_T) eax
>        integer(C_INT32_T) ebx
>        integer(C_INT32_T) edx
>        integer(C_INT32_T) ecx
>     end type CPUID_type
>     abstract interface
>        subroutine ldmxcsr_template(source) bind(C)
>           use ISO_C_BINDING
>           implicit none
>           integer(C_INT32_T), value :: source
>        end subroutine ldmxcsr_template
>        function stmxcsr_template() bind(C)
>           use ISO_C_BINDING
>           implicit none
>           integer(C_INT32_T) :: stmxcsr_template
>        end function stmxcsr_template
>        function fstsw_template() bind(C)
>           use ISO_C_BINDING
>           implicit none
>           integer(C_INT16_T) :: fstsw_template
>        end function fstsw_template
>        function fstcw_template() bind(C)
>           use ISO_C_BINDING
>           implicit none
>           integer(C_INT16_T) :: fstcw_template
>        end function fstcw_template
>        subroutine fldcw_template(source) bind(C)
>           use ISO_C_BINDING
>           implicit none
>           integer(C_INT16_T), value :: source
>        end subroutine fldcw_template
>        subroutine fclex_template() bind(C)
>           use ISO_C_BINDING
>           implicit none
>        end subroutine fclex_template
>        function rdtsc_template() bind(C)
>           use ISO_C_BINDING
>           implicit none
>           integer(C_INT64_T) :: rdtsc_template
>        end function rdtsc_template
>        subroutine cpuid_template(result,eax,ecx) bind(C)
>           use ISO_C_BINDING
>           import CPUID_type
>           implicit none
>           type(CPUID_type) :: result
>           integer(C_INT32_T), value :: eax
>           integer(C_INT32_T), value :: ecx
>        end subroutine cpuid_template
>     end interface
>     procedure(ldmxcsr_template), pointer :: ldmxcsr =>  NULL()
>     procedure(stmxcsr_template), pointer :: stmxcsr =>  NULL()
>     procedure(fstsw_template), pointer :: fstsw =>  NULL()
>     procedure(fstcw_template), pointer :: fstcw =>  NULL()
>     procedure(fldcw_template), pointer :: fldcw =>  NULL()
>     procedure(fclex_template), pointer :: fclex =>  NULL()
>     procedure(rdtsc_template), pointer :: rdtsc =>  NULL()
>     procedure(cpuid_template), pointer :: cpuid =>  NULL()
>     interface
>        function VirtualAlloc(lpAddress, dwSize, flAllocationType,&
>              flProtect) bind(C, name = 'VirtualAlloc')
>           use ISO_C_BINDING
>           implicit none
> !GCC$ ATTRIBUTES STDCALL :: VirtualAlloc
>           type(C_PTR) VirtualAlloc
>           type(C_PTR), value :: lpAddress
>           integer(C_SIZE_T), value :: dwSize
>           integer(C_LONG), value :: flAllocationType
>           integer(C_LONG), value :: flProtect
>        end function VirtualAlloc
>        function GetLastError() bind(C,name='GetLastError')
>           use ISO_C_BINDING
>           implicit none
> !GCC$ ATTRIBUTES STDCALL :: GetLastError
>           integer(C_LONG) GetLastError
>        end function GetLastError
>     end interface
>     contains
>        subroutine utils_init()
>           type(C_PTR) address
>           integer(C_INTPTR_T) temp
>           integer(C_LONG) error
>           integer(C_INT8_T), pointer :: temp_ptr(:)
>           type(C_FUNPTR) fun_address
>           logical :: first = .TRUE.
>
>           if(.NOT.first) return
>           first = .FALSE.
>           address = VirtualAlloc(C_NULL_PTR,&
>              size(BAD_STUFF,kind=C_SIZE_T),int(Z'1000',C_LONG),&
>              int(Z'40',C_LONG))
>           if(.NOT.C_ASSOCIATED(address)) then
>              error = GetLastError()
>              write(*,'(a,z0,a)') "Error Z'",error,"' allocating memory"
>              stop
>           end if
>           call C_F_POINTER(address, temp_ptr, shape(BAD_STUFF))
>           temp_ptr = BAD_STUFF
>           temp = transfer(address, temp)
>           fun_address = transfer(temp, fun_address)
>           call C_F_PROCPOINTER(fun_address, ldmxcsr)
>           temp = temp+32
>           fun_address = transfer(temp, fun_address)
>           call C_F_PROCPOINTER(fun_address, stmxcsr)
>           temp = temp+24
>           fun_address = transfer(temp, fun_address)
>           call C_F_PROCPOINTER(fun_address, fstsw)
>           temp = temp+8
>           fun_address = transfer(temp, fun_address)
>           call C_F_PROCPOINTER(fun_address, fstcw)
>           temp = temp+32
>           fun_address = transfer(temp, fun_address)
>           call C_F_PROCPOINTER(fun_address, fldcw)
>           temp = temp+24
>           fun_address = transfer(temp, fun_address)
>           call C_F_PROCPOINTER(fun_address, fclex)
>           temp = temp+8
>           fun_address = transfer(temp, fun_address)
>           call C_F_PROCPOINTER(fun_address, rdtsc)
>           temp = temp+32
>           fun_address = transfer(temp, fun_address)
>           call C_F_PROCPOINTER(fun_address, cpuid)
>        end subroutine utils_init
> end module utils
>
> program test80
>     use utils, only: utils_init, fstcw
>     use ISO_C_BINDING, only: C_INT16_T,C_INTPTR_T
>     implicit none
>     integer, parameter :: ep = selected_real_kind(18,4931)
>     real(ep) x
>     integer(C_INT16_T) fcw
>     integer fpc
>     character*100,parameter :: PCs(0:3)=[character*100::&
>        'Single Precision (24 bits)',&
>        'Reserved',&
>        'Double Precision (53 bits)',&
>        'Double Extended Precision (64 bits)']
>
>     call utils_init
>     write(*,'(a,i0,a)') 'This is a ',&
>        bit_size(0_C_INTPTR_T), '-bit Fortran processor.'
>     write(*,'(3(a,i0:";",1x))') 'Kind = ', kind(x),&
>                'Precision = ', precision(x),&
>                'Range = ', range(x)
>     fcw = fstcw()
>     fpc = ibits(fcw,8,2)
>     write(*,'(a,i0)') 'Precision Control = ', fpc
>     write(*,'(a)') 'Description = '//trim(PCs(fpc))
> end program test80
>
> C:\gfortran\clf\test80>gfortran -fno-range-check test80.f90 -otest80
>
> C:\gfortran\clf\test80>test80
> This is a 64-bit Fortran processor.
> Kind = 10; Precision = 18; Range = 4931
> Precision Control = 3
> Description = Double Extended Precision (64 bits)
>

As far as I know, in order to make 80-bit format visible under Win64, 
the compiler has to reset to 64-bit precision mode.  This exceeds the 
valid range of Windows supplied math libraries.  It's difficult to know 
without detailed study where this may lead with the various 
implementations of gfortran, but it's of no concern when using plain 
32-bit and 64-bit data types.

-- 
Tim Prince

James Van Buskirk <not_valid@comcast.net> wrote:

> F95 has the weird restriction that it only allows elemental
> intrinsics with integer or character argments in initialization
> expressions.  F03 lifts this restriction and I think that is also
> when transformational intrinsics were allowed in initialization
> expressions.  Since the MERGE intrinsic takes a LOGICAL argument,
> that excludes it from initialization expressions in F95.
> 
> Now, one thing I've wondered about in F95 is that there are
> intrinsics that take an optional LOGICAL argument, like INDEX,
> SCAN, and VERIFY.  Were those allowed in F95 initialization
> expressions if the optional LOGICAL argument was omitted?

Yes, I'd say so with a high degree of certainty. I was going to say
probably yes, but with perhaps questionable reasoning involving the lack
of any mention of the incompatibities that there would have otherwise
been. Dug out a copy of f95 to start checking to see exactly what
compatibility problems would have resulted. But checking that involved
first looking at the exact words in the f95 standard. Once I checked
those exact words, I decided that I didn't need any such roundabout
reasoning and that I was far more certain of my answer.

Your informal description talks about allowing "elemental intrinsics
with integer or character arguments". That's good enough for informal
description, but it isn't actually what the words of the standard say
and the difference answers the question.

The standard says it allows "an elemental intrinsic function reference
of type integer or character where each argument is an initialization
expression of type integer or character". Two things about that sentence
tell me that it is only talking about the arguments that are actually
present.

First, note the word "reference". The "where" clause modifies
"reference" - not "function". Thus it describes requirements that apply
to the reference - not to things inside the function.

Second, and even more convincing for those who might try to argue that
the grammar could be ambiguous on the first point (I don't think it is
ambiguous, but I suppose some might try to argue it), is that the
restriction is not just that the arguments be of type integer or
character, but that they be initialization expressions of type integer
or character. That absolutely has to be talking about the actual
arguments; I see no way around it. It would be nonsense to talk about
dummy arguments being expressions. (Well, maybe one could define such
things, but it sure isn't done in f95). Since this can't be talking
about the dummy argument, and there is no actual argument to talk about,
there is nothing for this restriction to apply to. It isn't a
restriction about what actual arguments could potentially look like; it
is a restriction on what they actualy are.

-- 
Richard Maine                    | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle           |  -- Mark Twain

"Richard Maine" <nospam@see.signature> wrote in message 
news:1ka5tbf.1hkjj5huswlyaN%nospam@see.signature...

> Your informal description talks about allowing "elemental intrinsics
> with integer or character arguments". That's good enough for informal
> description, but it isn't actually what the words of the standard say
> and the difference answers the question.

> The standard says it allows "an elemental intrinsic function reference
> of type integer or character where each argument is an initialization
> expression of type integer or character". Two things about that sentence
> tell me that it is only talking about the arguments that are actually
> present.

Excellent point.  Thanks a lot, Richard.

-- 
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end

On 4/11/2011 9:18 AM, Terence wrote:
....
> Having said all that, I wouldn't like to do development of new systems in
> F90/95; there's really too much additional typing and  problems in compiling
> (I use CVF on M.S. Developer Studio basis); then all the fiddling with Debug
> and Release sub-folders; the (to me) reduced testing facilities compared
> with DOS trials, and increased turn-around time of the next correction and
> test.

You are (mostly) confusing the language specification with the tools 
provided with a particular processor.

On 4/11/2011 11:18 a.m., Terence wrote:
> I hate to disagree. I then usually get attacked for age-related limited
> functionality.
>
> However.
> I HAVE used F90, and quite a lot, when I converted  a 60-odd commercial
> DOS/DOS-in-Windows program suite, to be able to compile and link with a
> Windows based TUI library, instead of the same facilities in DOS (i.e System
> calls versus API calls) used by all modules to control the screen and mouse
> and provide colours and 103-key support that Fortran does not offer.. This
> 'upgrade' was a general customer request based on perceived needs to add
> cut-and-paste facilities to move screen tables to Excel and MS plotting
> services, even though all reports already came out in Word-ready RTF format.
>
> Having said all that, I wouldn't like to do development of new systems in
> F90/95; there's really too much additional typing and  problems in compiling
> (I use CVF on M.S. Developer Studio basis); then all the fiddling with Debug
> and Release sub-folders; the (to me) reduced testing facilities compared
> with DOS trials, and increased turn-around time of the next correction and
> test.

"Fiddling with Debug and Release sub-folders", and "reduced testing 
facilities" (whatever these mean) have nothing at all to do with F77 vs 
F90.  You can build F90 programs in exactly the same way you build F77 
programs.  Did you know that CVF can be invoked from the command line?

Your objections seem to reduce to "too much additional typing".  I can't 
think what you are referring to.

Ian Harvey <ian_harvey@bigpond.com> wrote:

> On 4/11/2011 9:18 AM, Terence wrote:
> ...
> > Having said all that, I wouldn't like to do development of new systems in
> > F90/95; there's really too much additional typing and  problems in compiling
> > (I use CVF on M.S. Developer Studio basis); then all the fiddling with Debug
> > and Release sub-folders; the (to me) reduced testing facilities compared
> > with DOS trials, and increased turn-around time of the next correction and
> > test.
> 
> You are (mostly) confusing the language specification with the tools 
> provided with a particular processor.

Along with the common falacy of thinking that f77 code isn't also
f90/f95 code. If one is developing f77 code, then one is also developing
f90/f95 code. One is restricting oneself to a subset of f90/f95, but it
is still valid f90/f95.

I also restrict myself to a subset of f90/f95. I think most people do.
My personl subset happens to be very different from the subset that
constitutes f77, but that doesn't make me claim that I'm not using
f90/f95.

-- 
Richard Maine                    | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle           |  -- Mark Twain

I hate to disagree. I then usually get attacked for age-related limited
functionality.

However.
I HAVE used F90, and quite a lot, when I converted  a 60-odd commercial
DOS/DOS-in-Windows program suite, to be able to compile and link with a
Windows based TUI library, instead of the same facilities in DOS (i.e System
calls versus API calls) used by all modules to control the screen and mouse
and provide colours and 103-key support that Fortran does not offer.. This
'upgrade' was a general customer request based on perceived needs to add
cut-and-paste facilities to move screen tables to Excel and MS plotting
services, even though all reports already came out in Word-ready RTF format.

Having said all that, I wouldn't like to do development of new systems in
F90/95; there's really too much additional typing and  problems in compiling
(I use CVF on M.S. Developer Studio basis); then all the fiddling with Debug
and Release sub-folders; the (to me) reduced testing facilities compared
with DOS trials, and increased turn-around time of the next correction and
test.
 Usually I don't get any Fortran code errors, but I DO need to adjust
presentations and colour balances and change data error messages, and hence
the code..

On 11/03/2011 10:53 PM, Richard Maine wrote:
> Along with the common falacy of thinking that f77 code isn't also
> f90/f95 code. If one is developing f77 code, then one is also developing
> f90/f95 code. One is restricting oneself to a subset of f90/f95, but it
> is still valid f90/f95.
>
> I also restrict myself to a subset of f90/f95. I think most people do.
> My personl subset happens to be very different from the subset that
> constitutes f77, but that doesn't make me claim that I'm not using
> f90/f95.

This is certainly true for me. I have chosen a subset of F2008 that I am 
comfortable with (I do use some F2008 features). I use features that I 
find helpful and avoid the ones I find harmful.

I have learned through this forum that there is legitimate disagreement 
on which features are good. I still avoid GOTOs, but this forum has 
shown me code examples that I admit are legitimately clearer with GOTOs.

Cheers,
Daniel.

On 11/3/2011 7:05 PM, Terence wrote:
....

> It's fara far clearer than working with for-Windows compilers.
....

That again has virtually nothing per se to do w/ F90+ vis a vis F77; 
it's confusing the compilers/OS/implementation w/ the language.

--

I don't think you understand that I program in MSDOS. or a MSDOS emulator,
..not in Windows.per se. I use an old simple MSDOS Fortran F77 compiler for
commercial development work.
If the market then requires a native windows version, I recompile the tested
code with DVF 6.6c and supply a Windows console version of the same
application. There's actually not much visible difference to the user. And
even DOS versions have cut-and paste and drop-down menus.

And yes, I DO understand that "F77" is a functional syntaxical subset of the
F90/F95 versionof the language. However; to use the TUI libraries I need
under Windows execution, I have to provide Modules for the code. And then it
really starts to get fiiddly with what goes where and what has to be
compiled first.

With MSDOS I just compile and link or get told where and why there is a
problem.
It's fara far clearer than working with for-Windows compilers.

dpb <none@non.net> wrote:
> On 11/3/2011 7:05 PM, Terence wrote:

>> It's fara far clearer than working with for-Windows compilers.
> ...

> That again has virtually nothing per se to do w/ F90+ vis a vis F77; 
> it's confusing the compilers/OS/implementation w/ the language.

Maybe, but often there aren't new compilers for older systems.

Note no Fortran90 or later compilers for VAX/VMS, for example.

Are there any for 16 bit DOS or Win16?  

Yes it confuses the implementation with the language, but that
doesn't help people running those systems with no implementation.

-- glen

glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:

> dpb <none@non.net> wrote:

> > That again has virtually nothing per se to do w/ F90+ vis a vis F77;
> > it's confusing the compilers/OS/implementation w/ the language.
> 
> Maybe, but often there aren't new compilers for older systems.

> Yes it confuses the implementation with the language, but that
> doesn't help people running those systems with no implementation.

And confusing the language and the implementation does help them? That
was a rhetorical question. No, it doesn't help. Confusing things seldom
does. It isn't as though it is particularly complicated in this case to
say what *IS* the distinction instead of to explain it as something that
it actually isn't. Confusing such things does a definite disservice in
my opinion - quite a large one.

When you ascribe things to the language that actually relate to a
particular implementation, you'll make other people who read the posts
think something applies to them when it doesn't. Yes, people other than
those directly posting on a topic do read these things. That's why I
post corrections about these things. I'm sure not aiming the corrections
in this thread at Terence. I see no point in doing that. The corrections
are aimed at other readers.

If one wants to say that you program in f77 instead of f90 because there
are no f90 compilers available on your platform of choice (or of need),
that's a simple enough thing to say. It might also have the advantage of
being true - a feature that Mom long ago taught me to prefer.

-- 
Richard Maine                    | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle           |  -- Mark Twain

On 4/11/2011 2:20 p.m., Richard Maine wrote:

> If one wants to say that you program in f77 instead of f90 because there
> are no f90 compilers available on your platform of choice (or of need),
> that's a simple enough thing to say. It might also have the advantage of
> being true - a feature that Mom long ago taught me to prefer.
>

That was all Terence needed to say.