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

A naive question, why Fortran not assign parameters with initial value of zero??


I try it and get the following results

real(8) :: g (defalut value with no assign g = 1.697825921128655E-313)
integer(4) :: g  (defalut value with no assign  g = 4640848)
real(8) :: g(4)  (defalut value with no assign  g(4) =
0.000000000000000E+000)
integer(4) :: g(4) (defalut value with no assign  g(4) = 0)

real(8),allocatable :: g(:)
allocate(g(4)) (defalut value with no assign  g(4) =
-6.277438562204192E+066)

why Fortran didn't assign parameters with initial value of zero?? I
think it may be convennient with a zero initial value at most case.

<li.sim@gmail.com> wrote in message

news:1180710342.819248.32200@j4g2000prf.googlegroups.com...

> why Fortran didn't assign parameters with initial value of zero?? I
> think it may be convennient with a zero initial value at most case.

Because zero is the average value of all representable numbers on a
computer. If variables are set to this value inadvertently and used in
calculations, the resulting wrong results will be closer to the true results
that if the values you quote are used, and thus the fault harder to detect.
Default initialization to zero is A VERY BAD IDEA.

Regards,

Mike Metcalf

On Jun 1, 11:05 am, li.sim@gmail.com wrote:

> I try it and get the following results

> real(8) :: g (defalut value with no assign g = 1.697825921128655E-313)
> integer(4) :: g  (defalut value with no assign  g = 4640848)
> real(8) :: g(4)  (defalut value with no assign  g(4) =
> 0.000000000000000E+000)
> integer(4) :: g(4) (defalut value with no assign  g(4) = 0)

> real(8),allocatable :: g(:)
> allocate(g(4)) (defalut value with no assign  g(4) =
> -6.277438562204192E+066)

> why Fortran didn't assign parameters with initial value of zero?? I
> think it may be convennient with a zero initial value at most case.

The literal reply to your subject line is that Fortran *can* assign
parameters with an initial value of zero:

real, parameter :: x=0.0

If you want a variable with an initial value of zero, just assign it
after declaring it.

real :: x
x = 0.0

Some compilers have options that intialize variables to zero as you
are requesting, but I URGE you not to rely on them --  not all
compilers have such an option, and the code will have undefined
behavior according to the Fortran standard.

Michael Metcalf wrote:
> <li.sim@gmail.com> wrote in message
> news:1180710342.819248.32200@j4g2000prf.googlegroups.com...

>> why Fortran didn't assign parameters with initial value of zero?? I
>> think it may be convennient with a zero initial value at most case.

> Because zero is the average value of all representable numbers on a
> computer. If variables are set to this value inadvertently and used in
> calculations, the resulting wrong results will be closer to the true results
> that if the values you quote are used, and thus the fault harder to detect.
> Default initialization to zero is A VERY BAD IDEA.

Thinking on this.... are there any compilers which will do something
useful - like a default initialisation to NaN? IME (admittedly limited),
zero initialisation tends to be the default (and much cursed) unless you
turn on stack allocation of local variables (-stackvar or -automatic
being common options), which gives 'random' values. These are more
likely to cause a crash, but there isn't the nice guarantee which NaN
provides.

Richard

On Jun 1, 11:52 am, Richard Edgar <r@pas.rochester.edu> wrote:

G95 has the option -freal. From http://www.g95.org/docs.html,

-freal= Initialize uninitialized scalar real and complex variables.
Legal values are none, zero, nan, inf, +inf and -inf.

The full set of debugging options I use when compiling with g95 (not
that anyone asked) are

-Wall -Wextra -Wimplicit-none -Werror=113,115,137,146,147,159,163 -
ftrace=full -fbounds-check -freal=nan -fmodule-private

where the numeric warning numbers have the meanings below.

102 MODULE PROCEDURE USEd is not referenced
112 Variable is set but never used
113 Variable is used but not set
115 Line is being truncated
137 Variable is never used and never set
146 Variable is set and never allocated
147 Variable is used and never allocated
157 Variable has the target attribute but is never pointed to
158 Intent(out) variable not set
159 PARAMETER is never used
163 Actual argument does not have an intent
167 PRIVATE module procedure is not invoked

Richard Edgar <r@pas.rochester.edu> writes:
> Michael Metcalf wrote:
>> Default initialization to zero is A VERY BAD IDEA.

> Thinking on this.... are there any compilers which will do something
> useful - like a default initialisation to NaN?

The SGI compiler had this. I loved this feature, it helped me to track
down lots of uninitialised variables. Not only statically (doing it
once before the program runs), but dynamically (once before a
subroutine is entered). That way it did not only find the 'standard'
cases that also the compiler can recognise, but also these tricky once
where once in a while (depending which path you take through the
routine) are not set, and you would get a value from a previous cycle
through that routine. Access as FP then gives a nice FPE, usage of
such a variable as pointer usually gives a out of bound error (if
boundcheck also enable) or a segfault (I believe the value was
-37056). Of course you must explicitly SAVE the variable you want to
have saved (but that you do anyhow, don't you?).

This did slow down the program, so I only used it for special test
runs, but hese did help a lot.

Extremely useful feature.

Matthias

Cheers to Mike ;)

"Matthias SCHROEDER" <Matthias.Schro@cern.ch> wrote in message

news:x94fy57svdb.fsf@pcitps345.cern.ch...

> Richard Edgar <r@pas.rochester.edu> writes:

>> Michael Metcalf wrote:

>>> Default initialization to zero is A VERY BAD IDEA.

>> Thinking on this.... are there any compilers which will do something
>> useful - like a default initialisation to NaN?

> The SGI compiler had this.

I was brought up on Cray computers. Memory was initialized to a pattern that
was close to what we would now call a NaN. Not only that, it contained its
own address (with 60 bits, there was plenty of room!). This meant that if an
unitialized variable was assigned to another, it could be traced back. About
90% of all crashes could be solved by inspection of a 1-page octal register
and core dump.

Regards,

Mike Metcalf

In article <1180714162.017952.316@q69g2000hsb.googlegroups.com>,
Beliavsky  <beliav@aol.com> wrote:
>On Jun 1, 11:52 am, Richard Edgar <r@pas.rochester.edu> wrote:
>> Michael Metcalf wrote:
>> > Default initialization to zero is A VERY BAD IDEA.

>G95 has the option -freal. From http://www.g95.org/docs.html,

It also has -finteger. When debugging I use -finteger=-2109876543
because (unlike the real case) there is no integer nan or inf,
-2109876543 is easy to recognise and seldom occurs in correct output.

-- John Harper, School of Mathematics, Statistics and Computer Science,
Victoria University, PO Box 600, Wellington 6140, New Zealand
e-mail john.har@vuw.ac.nz phone (+64)(4)463 5341 fax (+64)(4)463 5045

On Jun 4, 6:27 am, Matthias SCHROEDER <Matthias.Schro@cern.ch>
wrote:

> The SGI compiler had this. I loved this feature, it helped me to track
> down lots of uninitialised variables. Not only statically (doing it
> once before the program runs), but dynamically (once before a
> subroutine is entered).

Not surprisingly, the PathScale compiler has this feature, both
assigning to zero and assigning to NaN. And, to update it to
Fortran9X, you can do the same for allocated arrays. We used it a lot
internally, to figure out when customer programs are buggy, instead of
our compiler.

-- greg
(formerly employed by PathScale. I pushed to get this feature
implemented. :-)

This sounds like the Salford (now Silverfrost) /UNDEF feature. Though I
don't think they use a specific NaN, just a very very unlikely value
which their own system triggered on.

In my experience, the majority of bugs in code are due to undefined
variables, with almost all the remainder being either array indices out
of bounds or mismatching subroutine argument lists.

Second (third, etc.) all the comments that initialisation to zero is a
very bad idea. If you want a value to be zero, then set it that way.
It's a few seconds of typing which will save you hours of debugging when
you forget to set the next variable along which should have been 0.005...

Catherine.
--
Catherine Rees Lay

Polyhedron Software Ltd. Registered Office: Linden House,
93 High St, Standlake, Witney, OX29 7RH, United Kingdom.
Registered in England No.2541693. Vat Reg No. GB 537 3214 57

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