Hello,

I am a newcomer to Fortran and I have the following question. Does the
cos intrinsic in fortran returns a double precision number o a single
precision one. Reading the documentation I am lead to believe the
latter, but then how do I calculate trigonometric functions in double
precision.

Thank you in advance,
Makis

ps. I am using g77 from the gcc4.3.6 collection.

makis wrote:

> Hello,
> 
> I am a newcomer to Fortran and I have the following question. Does the
> cos intrinsic in fortran returns a double precision number o a single
> precision one. Reading the documentation I am lead to believe the
> latter, but then how do I calculate trigonometric functions in double
> precision.

COS SIN ... intrinsic functions return a result of the same kind of the 
argument.

So COS(1.) is a REAL value when COS(1.D0) is a double precision value.

These fonctions may even be used on array (elemental functions), returning 
an array of the same dimension and the same kind as the argument.
> 
> Thank you in advance,
> Makis
> 
> ps. I am using g77 from the gcc4.3.6 collection.

-- 
François Jacq
email : first name . last name at domain . fr
domain : irsn

makis <makismunich@gmail.com> wrote:
 
> I am a newcomer to Fortran and I have the following question. Does the
> cos intrinsic in fortran returns a double precision number o a single
> precision one. Reading the documentation I am lead to believe the
> latter, but then how do I calculate trigonometric functions in double
> precision.

With generic intrinsic functions, I believe since Fortran 90,
you get a double precision cos for a double precision argument.
 
> ps. I am using g77 from the gcc4.3.6 collection.

In Fortran 77 (and Fortran 66) you need the DCOS function for
double precision arguments, which will return a double precision
result.

If you want a double precision result from a single precision
argument, then DCOS(DBLE(X)).

Otherwise, upgrade to gfortran or g95.

-- glen

On 09/07/2010 06:39 PM, fj wrote:
> makis wrote:
>> I am a newcomer to Fortran [...]
>> ps. I am using g77 from the gcc4.3.6 collection.

First, I think you mistyped the version number g77 is not part of any 
GCC version since 4.0.0 - and 4.3.6 does not exist. You probably mean 3.4.6.

Additionally and especially if you start with Fortran: I would seriously 
consider to use Fortran 90/95 rather than FORTRAN 77. Fortran 90/95 is 
backward compatible* to Fortran 77 but it offers many nice new features. 
The number of compilers supporting Fortran 90 and 95 is also large.

Independent whether you stay with Fortran 77 or move to Fortran 90, you 
should consider to install (additionally) a newer compiler. My very 
limited experience with g77 and Fortran 77 code was that other compilers 
such as gfortran or g95 have much better diagnostics and thus help 
finding bugs in the program. The only disadvantage this has: Fortran 90 
(and newer) features might slip into your program - but that can also be 
regarded as feature (and you could cross check with g77 whether it still 
compiles).

One disadvantage with FORTRAN 77 is that many features are lacking - 
thus one tends to use compiler specific extension ("vendor extensions") 
which make the code less portable. Using Fortran 90/95/2003/2008** the 
need to use such extensions became much lower - which makes programs 
more portable and better defined. Additionally, there are many other 
features in Fortran 90/95/2003/2008 which are very useful by their own 
right.

If you have a somewhat recent Linux, there should also be a package with 
gfortran, which is a Fortran 90/95 compiler and part of GCC since 4.0. 
Otherwise, have a look at http://gcc.gnu.org/wiki/GFortranBinaries

There are also many other Fortran 90+ compilers available such as g95 
and open64 (both opensource), sunf95 (free), Intel's ifort (commercial 
but free for non-commercial use), as well as NAG's, PathScale's, 
Portland Groups's, IBM's, Cray's, Absoft's, etc. Fortran compiler.

Tobias

* Except for minor items which were deleted but compilers continue to 
support.
** Fortran 90/95 is widely supported; however, not all Fortran 2003 and 
Fortran 2008 features have been implemented; a per-compiler 
implementation status can be found at 
http://www.fortranplus.co.uk/resources/fortran_2003_2008_compiler_support.pdf 
(data as of beginning of this year - thus, partially outdated)

On 09/07/2010 07:13 PM, glen herrmannsfeldt wrote:
> With generic intrinsic functions, I believe since Fortran 90,
> you get a double precision cos for a double precision argument.
>
> In Fortran 77 (and Fortran 66) you need the DCOS function for
> double precision arguments, which will return a double precision
> result.

I might misread the Fortran 77 standard, but I believe that Fortran 77 
also supports generic _intrinsic_ functions. Cf. 
ftp://ftp.nag.co.uk/sc22wg5/ARCHIVE/Fortran77.html which lists in Table 
5: COS as generic name with COS, DCOS and CCOS as specific names.

> If you want a double precision result from a single precision
> argument, then DCOS(DBLE(X)).

Thus, I think that also applies to Fortran 77:

   WRITE(*,*)  COS (1.0)  ! print single-precision (default-kind REAL)
   WRITE(*,*)  COS (1.0d0)! print double-precision result


> Otherwise, upgrade to gfortran or g95.

I concur. I think gfortran or g95 are better suited for Fortran 77 
programming - and especially they allow to move on to Fortran 90, 
Fortran 95 and (with restrictions) to Fortran 2003 and 2008.

Tobias

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

> makis <makismunich@gmail.com> wrote:
>  
> > I am a newcomer to Fortran and I have the following question. Does the
> > cos intrinsic in fortran returns a double precision number o a single
> > precision one. Reading the documentation I am lead to believe the
> > latter, but then how do I calculate trigonometric functions in double
> > precision.
> 
> With generic intrinsic functions, I believe since Fortran 90,

No. SInce f77.

> In Fortran 77 (and Fortran 66) you need the DCOS function for
> double precision arguments, which will return a double precision
> result.

No. Please do not recommend using specific functions like that. It is
essentially *NEVER* a good idea. Most people are better off not knowing
that the specifics exist. Generic intrinsics came with 77. (You need f90
for user-written intrinsics, but that's not the question here.)

Nobody asking questions like that here is going to be using an f66
compiler. Yes, I know you can find such compilers if you look hard
enough, but if some newbie has managed the trick of stumbling on such a
thing as an f66 compiler for reasons other than historical curiosity,
they would be better helped by pointing them to a newer compiler than by
teaching them f66. F77 I can sort of understand in some cases. I
generally argue for people moving to f90+, but I can understand f77. Not
f66.

One can invent arcane situations where a specific generic intrinsic
could be used, but they are so arcane and rare that I am quite serious
about my comment that a new user is literally better of not knowing that
the specifics exist. That knowledge will cause more harm than it will
help. (Sure, you could pass a specific intrinsic to, say, a numerical
integration routine, but there are lots better ways to find the integral
of cosine. And if you wanted to use that as a test case, you coudl still
invoke the generic intrinsic via a user-written wrapper). If he finds
some use that he needs to understand in an existing code, he can go look
up the anachronism in a reference.

-- 
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:

> (You need f90 for user-written intrinsics,

Of course, I mean "user-written generics" there. "User-written
intrinsics" is probably a contradiction in terms, or at least darn close
to one.

-- 
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:
 
(snip, I wrote)
>> With generic intrinsic functions, I believe since Fortran 90,
 
> No. SInce f77.

Yes, I forgot that one.  Most of the programs I worked on in 
the Fortran 77 days were left over from the Fortran 66
days, and no-one went through to change all the functions.
 
>> In Fortran 77 (and Fortran 66) you need the DCOS function for
>> double precision arguments, which will return a double precision
>> result.
 
> No. Please do not recommend using specific functions like that. It is
> essentially *NEVER* a good idea. Most people are better off not knowing
> that the specifics exist. Generic intrinsics came with 77. (You need f90
> for user-written intrinsics, but that's not the question here.)

I am not sure that it is quite that good, but otherwise I agree.
For one, many generics don't have an integer version.  Just about
my first Fortran program, the sample program in the OS/360 Fortran
manual, prints a list of prime numbers.  As usual, it uses trial
divisors up to the square root of the potential prime as 
SQRT(FLOAT(I)).  I believe that even now you can't SQRT(I).

(I always wondered why no ISQRT.)
 
(snip)

> One can invent arcane situations where a specific generic intrinsic
> could be used, but they are so arcane and rare that I am quite serious
> about my comment that a new user is literally better of not knowing that
> the specifics exist. 

OK, but experienced users should know about them.  If for no
other reason than reading old programs.

> That knowledge will cause more harm than it will
> help. (Sure, you could pass a specific intrinsic to, say, a numerical
> integration routine, but there are lots better ways to find the integral
> of cosine. And if you wanted to use that as a test case, you coudl still
> invoke the generic intrinsic via a user-written wrapper). If he finds
> some use that he needs to understand in an existing code, he can go look
> up the anachronism in a reference.

Yes I agree that one shouldn't do numerical integration on cos,
(though maybe as a test of the integration routines).  And yes,
if you do want to do it, a wrapper is a better solution.

-- glen 

Richard Maine <nospam@see.signature> wrote:
> Richard Maine <nospam@see.signature> wrote:
 
>> (You need f90 for user-written intrinsics,
 
> Of course, I mean "user-written generics" there. "User-written
> intrinsics" is probably a contradiction in terms, or at least darn close
> to one.

Maybe in the Fortran I or Fortran II days.

-- glen 

On Sep 7, 6:39=A0pm, fj <nos...@see.signature> wrote:

> COS SIN ... intrinsic functions return a result of the same kind of the
> argument.
>
> So COS(1.) is a REAL value when COS(1.D0) is a double precision value.
>

I thank everyone for answering, but I still have a question.
First of all I really mistype the version I am using as someone
pointed out. I am using g77 from gcc 3.4.6. And for the moment I
cannot change either fortran version or compiler suite.
Reading the documentation of cos at
http://gcc.gnu.org/onlinedocs/gcc-3.4.6/g77/Cos-Intrinsic.html#Cos-Intrinsi=
c

I understand that if the argument of cos is double it will demoted to
single precision and that will be the accuracy of the result. Is this
correct?
According to the documentation the cos never returns a double.

Thanks for all the help,
Makis

makis <makismunich@gmail.com> wrote:

> I understand that if the argument of cos is double it will demoted to
> single precision and that will be the accuracy of the result. Is this
> correct?

No. If the argument of cos is double, the result will be double. There
is no demotion/degradation of precision.

> According to the documentation the cos never returns a double.

Then either

1. The documentation is wrong

or

2. You are misinterpreting it.

I'd place my money on (2) as most likely. You might be looking at
documentation of the specific intrinsics, which can be confusing. (Per
my comments to Glenn, you are better off not even knowing about the
specific intrinsics, at least for now, and possibly ever; it will just
mislead you.) If you just reference cos, you will get the generic
version.

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

On 8 sep, 07:35, makis <makismun...@gmail.com> wrote:
> On Sep 7, 6:39=A0pm, fj <nos...@see.signature> wrote:
>
> > COS SIN ... intrinsic functions return a result of the same kind of the
> > argument.
>
> > So COS(1.) is a REAL value when COS(1.D0) is a double precision value.
>
> I thank everyone for answering, but I still have a question.
> First of all I really mistype the version I am using as someone
> pointed out. I am using g77 from gcc 3.4.6. And for the moment I
> cannot change either fortran version or compiler suite.
> Reading the documentation of cos athttp://gcc.gnu.org/onlinedocs/gcc-3.4.=
6/g77/Cos-Intrinsic.html#Cos-In...
>
> I understand that if the argument of cos is double it will demoted to
> single precision and that will be the accuracy of the result. Is this
> correct?
> According to the documentation the cos never returns a double.
>
> Thanks for all the help,
> Makis

Why can you not change the compiler suite? While I am not commenting
on the quality of the compiler you are using, you _are_ using
programming
language technology that 30 years or so old.

The gfortran and g95 compilers support Fortran 90/95 (fully) and
beyond (partly)
and are both free as in "no money involved". Installing them can be
done
completely locally as in "no sysadmin involved" (modulo a set-up where
you
can do almost nothing).

If you have proprietary libraries compiled with/for g77, then the
issue
may indeed arise, but other than that, I advise you, as others have,
to move to another language standard.

Regards,

Arjen

I looked at the g77 documentation, and I see how a reader might go
astray. All intrinsics mingle in one long list, with no indication of
which are generic (applicable to multiple types) and which are
specific (applicable to a single type.) For COS it says:

"Cos: REAL or COMPLEX function, the exact type being that of argument
X."

The author expects the reader to understand that "REAL" means all
kinds of REAL rather than default REAL, and doesn't mention
DOUBLEPRECISION because it's a synonym for one kind of REAL. If a
function is specific to one kind of REAL, even if it's the default
kind, the author always mentions the KIND (as in "REAL(KIND=3D1)".

Anyway, to reiterate what others have said, generic COS operates on
any of the kinds of REAL or COMPLEX, and on DOUBLEPRECISION, returning
the same type as its argument. And you'll be happier in the long run
if you can switch to a Fortran 90 or newer compiler (for example, the
ability to use COS with an array argument, as mentioned by an earlier
poster, requires Fortran 90.)

On Sep 7, 10:35=A0pm, makis <makismun...@gmail.com> wrote:
> On Sep 7, 6:39=A0pm, fj <nos...@see.signature> wrote:
>
> > COS SIN ... intrinsic functions return a result of the same kind of the
> > argument.
>
> > So COS(1.) is a REAL value when COS(1.D0) is a double precision value.
>
> I thank everyone for answering, but I still have a question.
> First of all I really mistype the version I am using as someone
> pointed out. I am using g77 from gcc 3.4.6. And for the moment I
> cannot change either fortran version or compiler suite.
> Reading the documentation of cos athttp://gcc.gnu.org/onlinedocs/gcc-3.4.=
6/g77/Cos-Intrinsic.html#Cos-In...
>
> I understand that if the argument of cos is double it will demoted to
> single precision and that will be the accuracy of the result. Is this
> correct?
> According to the documentation the cos never returns a double.
>
> Thanks for all the help,
> Makis

Steven Correll <steven.correll@gmail.com> wrote:

> I looked at the g77 documentation, and I see how a reader might go
> astray. 

So I see. Sort of a cross between the possibilities I mentioned of
either the documentation being wrong or the OP misinterpreting it. On
glancing over it, I see that it isn't exactly wrong, but I'd say it has
a confusing and imprecise mixture of f77 and f90 terminology. Yes, I can
see how a reader might go astray. I'd probably have trouble reading it
myself if I didn't already know the right answer (and how that answer
would be phrased in both f77 and f90).

In f77, real and double precision are different types. In f90, they are
different kinds of the same type. The referenced documentation can't
really seem to make up its mind. It says that the argument of cos is
real or complex, which would be correct for f90, but not for f77. It
then says that the "exact type" of the function is the same as that of
the argument, where the term "exact type" is not defined, but I'm
guessing it is trying to invent an f77ish term for what f90 would call
type and kind, sort of waffling around the idea that even though the
documentation says "real", it means "real or double".

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

Steven Correll <steven.correll@gmail.com> wrote:

> I looked at the g77 documentation, and I see how a reader might go
> astray. All intrinsics mingle in one long list, with no indication
> of which are generic (applicable to multiple types) and which are
> specific (applicable to a single type.) For COS it says:
 
> "Cos: REAL or COMPLEX function, the exact type being that 
> of argument X."
 
> The author expects the reader to understand that "REAL" means all
> kinds of REAL rather than default REAL, and doesn't mention
> DOUBLEPRECISION because it's a synonym for one kind of REAL. If a
> function is specific to one kind of REAL, even if it's the default
> kind, the author always mentions the KIND (as in "REAL(KIND=1)".

Well, I could be wrong, but I thought KIND didn't come until 
Fortran 90, so I wouldn't expect it in g77 documentation.
Though I suppose it is possible that g77 offers KIND.

Many new features of a version of the standard were tested out
as extensions earlier, sometimes many years earlier.

-- glen