Different Numerical answers: VMS vs. Unix Fortran 
Author Message
 Different Numerical answers: VMS vs. Unix Fortran

Sorry, I know this must be in the FAQ somewhere, but I hope someone
can lend their expertise quickly and easily!

I have a program that's working fine (as far as I can tell!) in VMS fortran.
However, when I run it on a Unix machine (f77), I get different (wrong)
numbers.  Might this be a result of different ways of calling functions?
I'm using lots of double precision numbers.  Does Unix require the
variable definitions to be in strict order?  

I can e-mail you the program if you have the time to help me find
where the incompatibility is.

Thanks muchly,

Bram



Tue, 09 Dec 1997 03:00:00 GMT  
 Different Numerical answers: VMS vs. Unix Fortran

Quote:

>I have a program that's working fine (as far as I can tell!) in VMS Fortran.
>However, when I run it on a Unix machine (f77), I get different (wrong)
>numbers.  Might this be a result of different ways of calling functions?

In some sense, "different" is one way to describe it.  In a better sense,
"wrong" is the true way to describe it.

Quote:
>I'm using lots of double precision numbers.  Does Unix require the
>variable definitions to be in strict order?  

Passing a single precision variable to a subroutine expecting a double
precision is pretty much OK on the VAX.  You can get away with it because the
default FP formats are really quite compatible with each other, and the
interpretation of a certain bit pattern as a "real" will match, to within
single-precision accuracy, the interpretation of that same bit pattern
as a "double precision".

This "feature" of the VAX architecture doesn't work at all on IEEE-based
machines.  You'll end up with total garbage, if the program doesn't flat-out
crash.  In many ways, the VAX "feature" turned out to be a Bad Thing, because
many codes were developed over many years with no regards for calling
consistency, and now we're stuck fixing things to make them work.

For example, consider the following program:

        program yy

        real w
        w=0.18
        call tests(w)
        call testd(w)
        end

        subroutine tests(w)
        real w
        write(6,*) w
        return
        end

        subroutine testd(w)
        double precision w
        write(6,*) w
        return
        end

If I run it on a VAX running VMS, this is what happens:
$ fort yy
$ link yy
$ run yy
 0.1800000
 0.1800000071527847

But if I run it on our Alpha running OSF/1, I get this:

Quote:
> f77 -o yy yy.for
> yy

  0.1800000
  5.662443822440663E-009

The quick and dirty way to fix problems like these is to use a compiler
that lets you specify that *all* floating point variables are to be
double precision.  This option is available on the HP-UX and OSF/1
f77 compilers, and probably many others.  Under OSF/1, for example, I can
use the same source code but say:

Quote:
> f77 -o yy -r8 yy.for
> yy

  0.180000000000000
  0.180000000000000
And everything is fine.

The right way to fix this, of course, is to fix all the mistakes in the
source code.  Some tools such as ftncheck can help with this, but it may
still be a lot of work.




Tue, 09 Dec 1997 03:00:00 GMT  
 Different Numerical answers: VMS vs. Unix Fortran

Quote:
(Timothy D. Shoppa) writes:
>Passing a single precision variable to a subroutine expecting a double
>precision is pretty much OK on the VAX.  You can get away with it because the
>default FP formats are really quite compatible with each other, and the
>interpretation of a certain bit pattern as a "real" will match, to within
>single-precision accuracy, the interpretation of that same bit pattern
>as a "double precision".

>This "feature" of the VAX architecture doesn't work at all on IEEE-based
>machines.  You'll end up with total garbage, if the program doesn't flat-out
>crash.  In many ways, the VAX "feature" turned out to be a Bad Thing, because
>many codes were developed over many years with no regards for calling
>consistency, and now we're stuck fixing things to make them work.

We don't consider this to be a "feature" of the VAX architecture - any more
than the problem of passing small integers to a routine expecting a float
which will silently use zero.  It's a program bug that happens to work by
coincidence.  (Actually, the "VAX floating" (F and D) formats originated on
the PDP-11.)

Note that on OpenVMS Alpha systems, the default double type is VAX G_float
which is similar to IEEE double and does not have the same layout in the
first 32 bits as VAX F_float (single), so program bugs of this nature can
turn up this way too.  I address this in my article on "Migrating Fortran
Applications from VAX to Alpha AXP" available at ftp.digital.com in
/pub/Digital/info/document/migrating-fortran.txt.


DEC Fortran Development           WWW:  http://www.digital.com/info/slionel.html
Digital Equipment Corporation     CompuServe: 75263,3001
110 Spit Brook Road, ZKO2-3/N30
Nashua, NH 03062-2698             "Free advice is worth every cent"




Thu, 11 Dec 1997 03:00:00 GMT  
 Different Numerical answers: VMS vs. Unix Fortran

: Sorry, I know this must be in the FAQ somewhere, but I hope someone
: can lend their expertise quickly and easily!

: I have a program that's working fine (as far as I can tell!) in VMS Fortran.
: However, when I run it on a Unix machine (f77), I get different (wrong)
: numbers.  Might this be a result of different ways of calling functions?
: I'm using lots of double precision numbers.  Does Unix require the
: variable definitions to be in strict order?  

: I can e-mail you the program if you have the time to help me find
: where the incompatibility is.

: Thanks muchly,

: Bram

 I had the same problem with a small program for binary star orbits.
 The only real answer if, like me, you have to move programs
around a lot is to check your data types and do all that tedious
stuff like
      XREAL = 0.
               ^
          makes all the difference.

 I seem to recall that adding a "." to a digit involved in an
expression for a real number cured the problem in my case.

 Fortran wouldn't be half as much fun without this sort of thing :-)

--
_-_-_                                          _-_-_

| Astronomical Observatory, Brorfelde, Denmark     |
-_-_-   Procrastinate now !!!                  -_-_-



Fri, 12 Dec 1997 03:00:00 GMT  
 Different Numerical answers: VMS vs. Unix Fortran

Quote:
> The only real answer if, like me, you have to move programs
>around a lot is to check your data types and do all that tedious
>stuff like
>      XREAL = 0.
>               ^
>          makes all the difference.

It makes no difference at all.  The compiler is _required_ to convert
0 to the type of XREAL before assigning it.

Quote:

> I seem to recall that adding a "." to a digit involved in an
>expression for a real number cured the problem in my case.

This is something completely different. 1/N and 1./N are likely to
produce very different results.  However, their behaviour has to be the
same both on VMS and Unix, so this doesn't explain the differences seen
by the original poster.
Quote:

> Fortran wouldn't be half as much fun without this sort of thing :-)

What sort of thing?  What is specific to Fortran here?

Dan
--
Dan Pop
CERN, CN Division

Mail:  CERN - PPE, Bat. 31 R-004, CH-1211 Geneve 23, Switzerland



Fri, 12 Dec 1997 03:00:00 GMT  
 Different Numerical answers: VMS vs. Unix Fortran

Quote:

> I have a program that's working fine (as far as I can tell!) in VMS Fortran.
> However, when I run it on a Unix machine (f77), I get different (wrong)
> numbers.  Might this be a result of different ways of calling functions?

There are a number of programs around that can automatically check
function and subroutine calls & find the sort of programmer error that
usually causes such problems.  I use FTNCHEK, which is available free of
charge.  I use it on the PC.  Try contacting the author, Robert Moniot

and/or VAX versions.

At the risk of sounding pedantic, I would also suggest that you declare
each variable and use INTERFACE blocks, if they are available on the
compilers you use.  But FTNCHECK will find most (if not all) of the
problems detected by those methods.


.................I speak for myself, not for Uncle Sam.



Fri, 12 Dec 1997 03:00:00 GMT  
 Different Numerical answers: VMS vs. Unix Fortran

Quote:
(Mike Prager) writes:
>There are a number of programs around that can automatically check
>function and subroutine calls & find the sort of programmer error that
>usually causes such problems.  I use FTNCHEK, which is available free of
>charge.  I use it on the PC.  Try contacting the author, Robert Moniot

>and/or VAX versions.

I also like FTNCHEK - the standard distribution works just fine on OpenVMS.
It's at netlib.att.com.


DEC Fortran Development           WWW:  http://www.digital.com/info/slionel.html
Digital Equipment Corporation     CompuServe: 75263,3001
110 Spit Brook Road, ZKO2-3/N30
Nashua, NH 03062-2698             "Free advice is worth every cent"




Sat, 13 Dec 1997 03:00:00 GMT  
 Different Numerical answers: VMS vs. Unix Fortran

Quote:

>...
>(Actually, the "VAX floating" (F and D) formats originated on
>the PDP-11.)

Yep, I know.  I've got both a 11/45 and 11/70 in my living room, BTW.


Kellogg Radiation Lab, Caltech.



Sat, 13 Dec 1997 03:00:00 GMT  
 Different Numerical answers: VMS vs. Unix Fortran

Quote:

>There are a number of programs around that can automatically check
>function and subroutine calls & find the sort of programmer error that
>usually causes such problems.  I use FTNCHEK, which is available free of
>charge.  I use it on the PC.  Try contacting the author, Robert Moniot

>and/or VAX versions.

Thank you very much.  Mr. Moniot pointed me towards an ftp site for
FTNCHEK, which did the job well.  As another post mentioned, compiling
with f77 -r8 (or in VMS, for /real_size=64) also ensures that all the
constants, variables, and expressions are double-precision.

Bram



Sun, 14 Dec 1997 03:00:00 GMT  
 Different Numerical answers: VMS vs. Unix Fortran
It should be noted that once semantics between platforms are certified,
(that is, that the program is bona fide Fortran 77 or 90 so that
subprogram arguments agree in type, length, number; there are no
subscripts generated that exceed array bounds, etc.) then if a program
gets different "answers" on two different platforms, one "real" (get it:-)
conclusion is that the mathematics of computation as implemented in the
program is faulty. That is, neither set of "answers" (on either platform)
can be assumed to be correct. When one perturbs (changes slightly) program
input (or floating-point word length slightly; or even floating-point model)
and gets different "answers" then the problem is usually faulty algorithms.
In thirty years of computing using Fortran, I can tell you from experience
that this is not at all unusual. And these days, where people are thought
to be experts in numerical computations within months instead of years,
this problem seems even more frequent.


Mon, 15 Dec 1997 03:00:00 GMT  
 
 [ 10 post ] 

 Relevant Pages 

1. VMS vs. Unix Fortran

2. VMS to Unix (was: Is there a Fortran to Ada translator)

3. Convert Dec-Fortran from VMS to DEC-UNIX

4. Porting fortran code (VMS system calls under Unix)

5. VMS Fortran -> PC/Unix/Mac

6. Transportable FORTRAN VMS/Unix

7. VMS --> Unix fortran translator wanted

8. Coverting a package written in VMS Fortran to Unix

9. Fortran vs. C for numerical work

10. Fortran vs. C for numerical work

11. Fortran vs. C for numerical work

12. Languages for Numerical Computation --- Was C vs FORTRAN

 

 
Powered by phpBB® Forum Software