Home     |     .Net Programming    |     cSharp Home    |     Sql Server Home    |     Javascript / Client Side Development     |     Ajax Programming

Ruby on Rails Development     |     Perl Programming     |     C Programming Language     |     C++ Programming     |     IT Jobs

Python Programming Language     |     Laptop Suggestions?    |     TCL Scripting     |     Fortran Programming     |     Scheme Programming Language


 
 
Cervo Technologies
The Right Source to Outsource

MS Dynamics CRM 3.0

Fortran Programming Language

question about initializing variables to 0


Maybe this is a question of style more than substance, but when initializing
variables to zero, does it matter if you use:

        x = 0

or

        x = 0.0  (for real)

or

        x = 0.d0 (for double real)

or

        x = cmplx(0.d0, 0.d0, kind=r8)  (for example)

Does the first one (x = 0) always work regardless of how x is declared?

Thanks in advance,

Randy M.

On May 3, 1:11 pm, Randall Mackie <rlmackie@yahoo.com> wrote:

Yes.  Some purists would insist that you use the correct
type of literal regardless.  If the value were, say, one-tenth
it would make a difference which kind of literal you used.
By always using a matching kind (both type and KIND) of
literal, you have a habit which is perhaps safer.  I have no
strong opinion either way in Fortran.  I'd would prefer that
it not matter though.  I think Fortran is misdesigned in that
respect.

I do have one change to your above though.  When I have
any COMPLEX data at all, I always USE a module that defines
a generic operator for COMPLEX literals called .I.  Using
that, the last assignment would read:

   X = 0.d0 +.i. 0.d0

I don't use the CMPLX intrinsic at all anymore.

--
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies."   --  C. A. R. Hoare

Randall Mackie wrote:
> Maybe this is a question of style more than substance,
> but when  initializing
> variables to zero, does it matter if you use:
>     x = 0
> or
>     x = 0.0  (for real)

(snip of complex case)

All will work just fine.  In older(*) compilers, there was the
suggestion that the conversion might be done at run time.
I would be very surprised if any current, or even not so
current, compilers did runtime conversion, especially as
they have to do constant expression evaluation, anyway.

Still, it is sometimes more readable to use the appropriate
type.  It makes it more obvious when reading it that the variable
is actually real or complex and not integer.

(*) From Fortran 66 days, or even earlier.

-- glen

jamesgi@att.net wrote:

(snip)

> Yes.  Some purists would insist that you use the correct
> type of literal regardless.  If the value were, say, one-tenth
> it would make a difference which kind of literal you used.
> By always using a matching kind (both type and KIND) of
> literal, you have a habit which is perhaps safer.  I have no
> strong opinion either way in Fortran.  I'd would prefer that
> it not matter though.  I think Fortran is misdesigned in that
> respect.

Which somehow reminds me of one important case that it
does matter, and that is constant arguments to subprograms.
In that case the type must match, and, unlike some other
languages which will do type conversion for subprogram
arguments with the appropriate declaration, for Fortran
they must match.

Since you can't write one tenth as an integer constant,
that wouldn't seem to be a problem.  For a large number,
which might be too large for an integer constant but not
for a real constant, one should be sure to use a real
constant, with either a decimal point or E exponent.

Also, to be sure to get a double precision constant,
one should be sure to use the appropriate notation.

-- glen

On May 3, 3:11 pm, Randall Mackie <rlmackie@yahoo.com> wrote:

I'll let the language lawyers answer the "does it matter" question. I
always declare a REAL with a KIND, and use _kind in a constant when
assigning the real to a constant, for example

integer, parameter :: dp = kind(1.0d0)
real(kind=dp)        :: x
x = 0.0_dp

This procedure has been recommended by the experts.

In article <1178220542.486359.125@y5g2000hsa.googlegroups.com>,
        "jamesgi@att.net" <jamesgi@att.net> writes:

> I do have one change to your above though.  When I have
> any COMPLEX data at all, I always USE a module that defines
> a generic operator for COMPLEX literals called .I.  Using
> that, the last assignment would read:

>    X = 0.d0 +.i. 0.d0

> I don't use the CMPLX intrinsic at all anymore.

Can you show some code for your .i. operator?

--
Steve
http://troutmask.apl.washington.edu/~kargl/

On May 3, 2:39 pm, glen herrmannsfeldt <g@ugcs.caltech.edu> wrote:

> jamesgi@att.net wrote:
> > [...]        I'd would prefer that
> > it not matter though.  I think Fortran is misdesigned in that
> > respect.

> Which somehow reminds me of one important case that it
> does matter, and that is constant arguments to subprograms.
> In that case the type must match, and, unlike some other
> languages which will do type conversion for subprogram
> arguments with the appropriate declaration, for Fortran
> they must match.

Yes, there are in Fortran several contexts where you pretty
much have to be specific.  I think at one time I counted seven
such cases.  I'd have to dig through some old notes to be
sure.  Calling a procedure that has no interface is, as you
say here, one such case.  If the procedure has an interface
(and it's not generic) a mismatch will be caught and reported
by the compiler.  If you have a generic procedure, which
type and KIND of literal you use makes a difference.  If you
assign a value that isn't integral to a non-default KIND float,
you need to be specific.  If you WRITE the value using
unformatted I/O, it makes a difference.  If you use a literal
value that's not integral mixed-mode with a non-default float
operand, it makes a difference.  I don't remember the other
case; as I said, I vaguely recall there were seven.  I'll
probably remember it just after I press the send button for
this article.

I think that Fortran implementations should issue a warning
for KINDless literals if used in any of the above ways.  All
other uses are probably safe.  When I say that I'd prefer that
it not matter, I mean that those cases should all be handled
differently than Fortran requires.  Some of them should
be illegal and some should have different semantics.  It won't
happen.

--
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies."   --  C. A. R. Hoare

jamesgi@att.net wrote:

(snip)

> Yes, there are in Fortran several contexts where you pretty
> much have to be specific.  I think at one time I counted seven
> such cases.  I'd have to dig through some old notes to be
> sure.  Calling a procedure that has no interface is, as you
> say here, one such case.  If the procedure has an interface
> (and it's not generic) a mismatch will be caught and reported
> by the compiler.  

Reported, but you still need to fix it before it will work.

> If you have a generic procedure, which
> type and KIND of literal you use makes a difference.  If you
> assign a value that isn't integral to a non-default KIND float,
> you need to be specific.  If you WRITE the value using
> unformatted I/O, it makes a difference.  

It would also make a difference in formatted I/O.  For list
directed and G format output it will change the formatting
of the result.  Otherwise, it would be a mismatch to the
appropriate descriptor type.

-- glen

Can you share that module? I like the way that looks, much better
than cmplx statements.

Thanks, Randy

On May 3, 3:14 pm, glen herrmannsfeldt <g@ugcs.caltech.edu> wrote:
...

> It would also make a difference in formatted I/O.  For list
> directed and G format output it will change the formatting
> of the result.  Otherwise, it would be a mismatch to the
> appropriate descriptor type.

Well, the difference would apply only to O, not I/O (you
can't read into a literal).  Yes, that would matter in Fortran.
(So, that brings my count up to seven.  If someone comes
up with another that would be a surprise.)

--
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies."   --  C. A. R. Hoare

On May 3, 2:24 pm, Randall Mackie <rlmackie@yahoo.com> wrote:

> jamesgi@att.net wrote:
...
> > I do have one change to your above though.  When I have
> > any COMPLEX data at all, I always USE a module that defines
> > a generic operator for COMPLEX literals called .I.  Using
> > that, the last assignment would read:

> >    X = 0.d0 +.i. 0.d0

> > I don't use the CMPLX intrinsic at all anymore.
...
> Can you share that module? I like the way that looks, much better
> than cmplx statements.

Well, I'm traveling and don't have my usual stuff handy.
But it's not difficult to roll your own:

  Module COMPLEX_STUFF
    ! James Giles 2007

    Private  !  procedure names won't enter you namespace
    Public :: operator(.i.)  !  The operator itself will be available

    Interface operator(.i.)  ! add more if your system has more KINDs
        module procedure i_by_real, i_by_double
    End interface operator(.i.)

  Contains

    Elemental Function i_by_real(x)
      Real, Intent(in) :: x
      Complex :: i_by_real
      i_by_real = CMPLX(0.0, x)
      return
    End Function i_by_real

    Elemental Function i_by_double(x)
      Real(KIND(0.0d0)), Intent(in) :: x
      Complex(KIND(0.0d0)) :: i_by_double
      i_by_double = CMPLX(0.0, x, KIND(0.0d0))
      return
    End Function i_by_double

  End Module COMPLEX_STUFF

Assuming I haven't made any mistakes, this is all there is.
More KINDs of floats can be accommodated if you have
them.  Note that the CMPLX intrinsic is never used again
since the .I. operator is used elsewhere.

--
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies."   --  C. A. R. Hoare

Beliavsky wrote:

> >         x = 0

> integer, parameter :: dp = kind(1.0d0)
> real(kind=dp)        :: x
> x = 0.0_dp

> This procedure has been recommended by the experts.

Hideous, it looks like fodder for the fools en route to self
destruction. Take your evangelical recipe for *tripling* a code size and
shove it, and don't bother squealing back anytime soon.
On May 3, 8:29?pm, "jamesgi@att.net" <jamesgi@att.net> wrote:

I respectfully disagree about your non use of the intrinsic CMPLX.

The problem is not how the code looks to you, but how it looks to a
future maintenance programmer.

When there is a choice between two ways of writing code, other things
being equal, the more standard one should be chosen.

David Flower

David Flower wrote (in reply to James Giles):

> I respectfully disagree about your non use of the intrinsic CMPLX.

> The problem is not how the code looks to you, but how it looks to a
> future maintenance programmer.

> When there is a choice between two ways of writing code, other things
> being equal, the more standard one should be chosen.

Yes.  But things are not equal; the requirement for the KIND argument to
CMPLX is a bit counterintuitive to some programmers, and thus can lead
to errors of omission, and thence to lurking bugs of the sort that may
well still be lurking (and subtly corrupting results) years later.

In addition, in some cases one has a fairly good idea of the opinions of
the future maintenance programmer who will be working on the project,
and can program in ways that match their expected idiosyncracies.  (In
particular, this happens when the maintenance programmer is likely to be
oneself some years later.)  My guess is that James falls into this
category much of the time, and has fairly good evidence that his future
maintenance programmer will prefer the .I. operator.  :)

- Brooks

--
The "bmoses-nospam" address is valid; no unmunging needed.

"Randall Mackie" <rlmackie@yahoo.com> wrote in message

news:7KydncUvOpZirqfbnZ2dnUVZ_hudnZ2d@comcast.com...

> Maybe this is a question of style more than substance, but when initializing
> variables to zero, does it matter if you use:

> x = 0
> or
> x = 0.0  (for real)
> or
> x = 0.d0 (for double real)
> or
> x = cmplx(0.d0, 0.d0, kind=r8)  (for example)

> Does the first one (x = 0) always work regardless of how x is declared?

Not only does it not matter, x = 0 is simple and clear, and is to be preferred.
On May 4, 2:28 am, Brooks Moses <bmoses-nos@cits1.stanford.edu>
wrote:

> David Flower wrote (in reply to James Giles):

> > I respectfully disagree about your non use of the intrinsic CMPLX.

> > The problem is not how the code looks to you, but how it looks to a
> > future maintenance programmer.

> > When there is a choice between two ways of writing code, other things
> > being equal, the more standard one should be chosen.

> Yes.  But things are not equal; the requirement for the KIND argument to
> CMPLX is a bit counterintuitive to some programmers, and thus can lead
> to errors of omission, and thence to lurking bugs of the sort that may
> well still be lurking (and subtly corrupting results) years later.

CMPLX is worse than counter intuitive, it's inconsistent
with the rest of the generic intrinsics.  All the others
yield a result whose KIND is consistent with that of
its argument(s).  CMPLX doesn't.

> In addition, in some cases one has a fairly good idea of the opinions of
> the future maintenance programmer who will be working on the project,
> and can program in ways that match their expected idiosyncracies.  (In
> particular, this happens when the maintenance programmer is likely to be
> oneself some years later.)  My guess is that James falls into this
> category much of the time, and has fairly good evidence that his future
> maintenance programmer will prefer the .I. operator.  :)

Well, sort of.  I did say that *I* use the form I suggested
in my own code.  I didn't even recommend it for others.
I merely stated what I do.  I do think that the more people
that use it, the less confusing it will seem.  I also think
that some change to the standard is appropriate.  I've
suggested a new intrinsic (spelled COMPLEX) which
would be consistent with the usual pattern for generic
intrinsics.  The CMPLX intrinsic would then be placed
on the obsolescent list (probably never to really go away,
just to emphasize there's a better way).  I've even suggested
that the .I. operator be made intrinsic.  Then the use of
it *would* be the standard way.

However, most of my real work over the years has not
been maintaining my own code but debugging the code
of others.  If you're doing site maintenance on a compiler
one of your most common activities is dealing with users
that come in and say "I think I've found a bug in the compiler:
this code doesn't work right."  Believe me, you soon have an
instinct for the kinds of things people tend to get wrong.
Or, if you're maintaining an I/O library, or merely doing
"consulting office" duty, that same observation applies.

--
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies."   --  C. A. R. Hoare

jamesgi@att.net <jamesgi@att.net> wrote:
> ... some change to the standard is appropriate.  I've
> suggested a new intrinsic (spelled COMPLEX) which
> would be consistent with the usual pattern for generic
> intrinsics.  The CMPLX intrinsic would then be placed
> on the obsolescent list (probably never to really go away,
> just to emphasize there's a better way).

I agree with James on this. Seems liek a good way to make a new
consistent version available, while not breaking existing codes.

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

On 2007-05-04 14:08:28 -0300, nos@see.signature (Richard Maine) said:

> jamesgi@att.net <jamesgi@att.net> wrote:

>> ... some change to the standard is appropriate.  I've
>> suggested a new intrinsic (spelled COMPLEX) which
>> would be consistent with the usual pattern for generic
>> intrinsics.  The CMPLX intrinsic would then be placed
>> on the obsolescent list (probably never to really go away,
>> just to emphasize there's a better way).

> I agree with James on this. Seems liek a good way to make a new
> consistent version available, while not breaking existing codes.

One gets the impression that cleaning up a number of these historical
rough spots get lost in the rush for new features.

Extending the notion of statement label to allow construct names
to also act as statement labels would be another example. The
suggestion for GOTO MY_ERROR_EXIT rather than GOTO 9001 seemed
to have gotten lost behind improved error trapping which then was
dropped. (The several places that one would do this all work in
free format and the ambiuities in fixed format are cured by making
trailing colons required in fixed format and optional in free format.)

Net result is that numerical statement labels are trotted out as
an example of "Fortran the Ancient and Obsolete" by those looking
for ways to avoid Fortran in persuit of their language of the day.

It is the common "It may be important but it is not urgent" so we
will do it another day.

I'd rather the rules be consistent between fixed and free (always
include colons).

> Net result is that numerical statement labels are trotted out as
> an example of "Fortran the Ancient and Obsolete" by those looking
> for ways to avoid Fortran in persuit of their language of the day.

> It is the common "It may be important but it is not urgent" so we
> will do it another day.

--

Gary Scott
mailto:garylscott@sbcglobal dot net

Fortran Library:  http://www.fortranlib.com

Support the Original G95 Project:  http://www.g95.org
-OR-
Support the GNU GFortran Project:  http://gcc.gnu.org/fortran/index.html

If you want to do the impossible, don't hire an expert because he knows
it can't be done.

-- Henry Ford

On 2007-05-04 17:31:09 -0300, Gary Scott <garylsc@sbcglobal.net> said:

I would venture that there would be vendor extensions to permit dropping
them pretty fast so it was more an issue of realism. One could say that
they are required when things are ambiguous and leave it to the reader to
figure out the consequences.

One could always stick with "ancient and obsolete" and be consistent.

Add to del.icio.us | Digg this | Stumble it | Powered by Megasolutions Inc