Does your machine also FFT like mine?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Does your machine also FFT like mine?

Dirk Laurie
Encouraged by the prompt responses to my plot question -- thanks
everyone! -- let me rephrase the FFT one to which nobody replied.

On my Linux/586 machine, I get

> ifft(fft([1 1 0 0 1]))
ans =
    1.0000e+00    1.0000e+00   -1.4682e-08   -1.4682e-08    1.0000e+00

This is only single precision accurate.  Unfortunately the other
machines I have access to have the same architecture and use the
same binary and not surprisingly gives the same result.

What happens on your machine?

Dirk


Reply | Threaded
Open this post in threaded view
|

Re: Does your machine also FFT like mine?

Bryce Gardner-2
> On my Linux/586 machine, I get
>  
> > ifft(fft([1 1 0 0 1]))
> ans =
>     1.0000e+00    1.0000e+00   -1.4682e-08   -1.4682e-08    1.0000e+00
>  
> This is only single precision accurate.  Unfortunately the other


On my machine (Sparc 10, solaris 2.4) and with Octave 2.0.9,
I get:

echos{bgard}41: octave
Octave, version 2.0.9 (sparc-sun-solaris2.4).
Copyright (C) 1996, 1997 John W. Eaton.
This is free software with ABSOLUTELY NO WARRANTY.
For details, type `warranty'.
 
octave:1> ifft(fft([1 1 0 0 1]))
ans =
 
   1.0000e+00   1.0000e+00   7.3275e-16   7.3275e-16   1.0000e+00
 
octave:2>

So I get double precision accuracy on my version of Octave.
My version is not the lastest (it is more recent then my printed
version of the manual which is version 1.0 Feb 1994).

Bryce

Bryce Gardner
[hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Does your machine also FFT like mine?

Francesco Potorti`-9
In reply to this post by Dirk Laurie
   On my Linux/586 machine, I get
   
   > ifft(fft([1 1 0 0 1]))
   ans =
       1.0000e+00    1.0000e+00   -1.4682e-08   -1.4682e-08    1.0000e+00
   
   This is only single precision accurate.  Unfortunately the other
   machines I have access to have the same architecture and use the
   same binary and not surprisingly gives the same result.
   
   What happens on your machine?
   
Octave, version 2.0.8 (alpha-dec-osf4.0).
Copyright (C) 1996, 1997 John W. Eaton.
This is free software with ABSOLUTELY NO WARRANTY.
For details, type `warranty'.

pot@sable:~/math> ifft(fft([1 1 0 0 1]))
ans =

   1.0000e+00   1.0000e+00   7.3275e-16   7.3275e-16   1.0000e+00


Reply | Threaded
Open this post in threaded view
|

RE: Does your machine also FFT like mine?

Ted.Harding
In reply to this post by Dirk Laurie
On 11-May-98 Dirk Laurie wrote:

> On my Linux/586 machine, I get
>
>> ifft(fft([1 1 0 0 1]))
> ans =
>     1.0000e+00    1.0000e+00   -1.4682e-08   -1.4682e-08    1.0000e+00
>
> This is only single precision accurate.  Unfortunately the other
> machines I have access to have the same architecture and use the
> same binary and not surprisingly gives the same result.
>
> What happens on your machine?
>
> Dirk

With S.u.S.E. Linux 5.1, Pentium,
Octave, version 2.0.11 (i586-pc-linux-gnulibc1).
Copyright (C) 1996, 1997, 1998 John W. Eaton.
This is free software with ABSOLUTELY NO WARRANTY.
For details, type `warranty'.

octave:1> ifft(fft([1 1 0 0 1]))
ans =

   1.0000e+00   1.0000e-00   7.4583e-16   7.4583e-16   1.0000e-00

octave:2>
Ted.

--------------------------------------------------------------------
E-Mail: (Ted Harding) <[hidden email]>
Date: 11-May-98                                       Time: 17:08:19
--------------------------------------------------------------------


Reply | Threaded
Open this post in threaded view
|

Re: Does your machine also FFT like mine?

PETER HOPFGARTNER-6
In reply to this post by Dirk Laurie

     On Digital Unix 4.0c, Alpha 20164a, egcs-1.0.2 for C, C++, Digital
     Fortran, Octave 2.0.12:
     
     1.0000e+00  1.0000e+00  7.3275e-16  7.3275e-16  1.0000e+00
     
     
     Peter
     
     


______________________________ Reply Separator _________________________________
Subject: Does your machine also FFT like mine?
Author:  <[hidden email] > at NOVARALINK
Date:    5/11/98 10:16 AM


Encouraged by the prompt responses to my plot question -- thanks
everyone! -- let me rephrase the FFT one to which nobody replied.
     
On my Linux/586 machine, I get
     
> ifft(fft([1 1 0 0 1]))
ans =
    1.0000e+00    1.0000e+00   -1.4682e-08   -1.4682e-08    1.0000e+00
     
This is only single precision accurate.  Unfortunately the other
machines I have access to have the same architecture and use the
same binary and not surprisingly gives the same result.
     
What happens on your machine?
     
Dirk
     
     



Reply | Threaded
Open this post in threaded view
|

Does your machine also FFT like mine?

John W. Eaton-6
In reply to this post by Dirk Laurie
On 11-May-1998, Dirk Laurie <[hidden email]> wrote:

| Encouraged by the prompt responses to my plot question -- thanks
| everyone! -- let me rephrase the FFT one to which nobody replied.
|
| On my Linux/586 machine, I get
|
| > ifft(fft([1 1 0 0 1]))
| ans =
|     1.0000e+00    1.0000e+00   -1.4682e-08   -1.4682e-08    1.0000e+00
|
| This is only single precision accurate.  Unfortunately the other
| machines I have access to have the same architecture and use the
| same binary and not surprisingly gives the same result.
|
| What happens on your machine?

I was getting the same as you, but then I made the following changes
and the problem seems to be fixed.  :-)

For people who are using g77 and tried this test and got the double
precision accuracy, what version of g77 do you have?

I think the problem is that older versions of g77 (I am using 0.5.19.1)
handle things like

      double precision foo
      data foo /3.14159265358979/

by first constructing a single precision number (if you just look at
the number, there is nothing to tell you that it should be double),
then initializing the double variable foo with that.  I seem to
remember some heated debates on comp.lang.fortran about what the
proper interpretation should be.  In any case, I'd guess that g77's
default behavior has changed.  (Or were people who got the more accurate
result were using f2c?)

In any case, we can force double precision constants anyway, so I did
that for the next release of Octave by making the changes below.

If you apply this patch, be sure to also remove the libcruft.a file
to ensure that the new .o files are inserted (there is a small problem
with the libcruft makefiles, but fixing it would make the default
build process much slower).

Thanks,

jwe


*** libcruft/fftpack/passb3.f.orig Thu Jul 18 20:29:15 1996
--- libcruft/fftpack/passb3.f Mon May 11 12:03:13 1998
***************
*** 2,8 ****
        implicit double precision (a-h,o-z)
        dimension       cc(ido,3,l1)           ,ch(ido,l1,3)           ,
       1                wa1(1)     ,wa2(1)
!       data taur,taui /-.5,.866025403784439/
        if (ido .ne. 2) go to 102
        do 101 k=1,l1
           tr2 = cc(1,2,k)+cc(1,3,k)
--- 2,8 ----
        implicit double precision (a-h,o-z)
        dimension       cc(ido,3,l1)           ,ch(ido,l1,3)           ,
       1                wa1(1)     ,wa2(1)
!       data taur,taui /-.5,.866025403784439d0/
        if (ido .ne. 2) go to 102
        do 101 k=1,l1
           tr2 = cc(1,2,k)+cc(1,3,k)
*** libcruft/fftpack/passb5.f.orig Thu Jul 18 20:29:15 1996
--- libcruft/fftpack/passb5.f Mon May 11 12:03:13 1998
***************
*** 2,9 ****
        implicit double precision (a-h,o-z)
        dimension       cc(ido,5,l1)           ,ch(ido,l1,5)           ,
       1                wa1(1)     ,wa2(1)     ,wa3(1)     ,wa4(1)
!       data tr11,ti11,tr12,ti12 /.309016994374947,.951056516295154,
!      1-.809016994374947,.587785252292473/
        if (ido .ne. 2) go to 102
        do 101 k=1,l1
           ti5 = cc(2,2,k)-cc(2,5,k)
--- 2,9 ----
        implicit double precision (a-h,o-z)
        dimension       cc(ido,5,l1)           ,ch(ido,l1,5)           ,
       1                wa1(1)     ,wa2(1)     ,wa3(1)     ,wa4(1)
!       data tr11,ti11,tr12,ti12 /.309016994374947d0,.951056516295154d0,
!      1-.809016994374947d0,.587785252292473d0/
        if (ido .ne. 2) go to 102
        do 101 k=1,l1
           ti5 = cc(2,2,k)-cc(2,5,k)
*** libcruft/fftpack/passf3.f.orig Thu Jul 18 20:29:15 1996
--- libcruft/fftpack/passf3.f Mon May 11 12:03:13 1998
***************
*** 2,8 ****
        implicit double precision (a-h,o-z)
        dimension       cc(ido,3,l1)           ,ch(ido,l1,3)           ,
       1                wa1(1)     ,wa2(1)
!       data taur,taui /-.5,-.866025403784439/
        if (ido .ne. 2) go to 102
        do 101 k=1,l1
           tr2 = cc(1,2,k)+cc(1,3,k)
--- 2,8 ----
        implicit double precision (a-h,o-z)
        dimension       cc(ido,3,l1)           ,ch(ido,l1,3)           ,
       1                wa1(1)     ,wa2(1)
!       data taur,taui /-.5d0,-.866025403784439d0/
        if (ido .ne. 2) go to 102
        do 101 k=1,l1
           tr2 = cc(1,2,k)+cc(1,3,k)
*** libcruft/fftpack/passf5.f.orig Thu Jul 18 20:29:15 1996
--- libcruft/fftpack/passf5.f Mon May 11 12:03:13 1998
***************
*** 2,9 ****
        implicit double precision (a-h,o-z)
        dimension       cc(ido,5,l1)           ,ch(ido,l1,5)           ,
       1                wa1(1)     ,wa2(1)     ,wa3(1)     ,wa4(1)
!       data tr11,ti11,tr12,ti12 /.309016994374947,-.951056516295154,
!      1-.809016994374947,-.587785252292473/
        if (ido .ne. 2) go to 102
        do 101 k=1,l1
           ti5 = cc(2,2,k)-cc(2,5,k)
--- 2,9 ----
        implicit double precision (a-h,o-z)
        dimension       cc(ido,5,l1)           ,ch(ido,l1,5)           ,
       1                wa1(1)     ,wa2(1)     ,wa3(1)     ,wa4(1)
!       data tr11,ti11,tr12,ti12 /.309016994374947d0,-.951056516295154d0,
!      1-.809016994374947d0,-.587785252292473d0/
        if (ido .ne. 2) go to 102
        do 101 k=1,l1
           ti5 = cc(2,2,k)-cc(2,5,k)


Reply | Threaded
Open this post in threaded view
|

Re: Does your machine also FFT like mine?

steve53
In reply to this post by Bryce Gardner-2
In <[hidden email]>, on 05/11/98
   at 11:32 AM, Bryce Gardner <[hidden email]> said:

>> On my Linux/586 machine, I get
>>  
>> > ifft(fft([1 1 0 0 1]))
>> ans =
>>     1.0000e+00    1.0000e+00   -1.4682e-08   -1.4682e-08    1.0000e+00
>>  
>> This is only single precision accurate.  Unfortunately the other

Octave 2.0.11 for OS/2 2.x, Warp 3 and Warp 4.
(Patchlevel 2.0.11-b02).
Copyright (C) 1996, 1997, 1998 John W. Eaton.
OS/2-Port by Klaus Gebhardt, 1996 - 1998.
This is free software with ABSOLUTELY NO WARRANTY.
For details, type `warranty'.

octave:1>ifft(fft([1 1 0 0 1]))
ans =

   1.0000e+00   1.0000e+00   7.4583e-16   7.4583e-16   1.0000e+00

octave:2>

Seems to be double precision here.

Steven



--
-----------------------------------------------------------
Steven Levine <[hidden email]>  MR2/ICE #10183
-----------------------------------------------------------


Reply | Threaded
Open this post in threaded view
|

Re: Does your machine also FFT like mine?

jpf-4


Octave, version 2.0.5 (i586-pc-linux-gnu).
Copyright (C) 1996 John W. Eaton.
This is free software with ABSOLUTELY NO WARRANTY.
For details, type `warranty'.
 
octave:1> ifft(fft([1 1 0 0 1]))
ans =
 
    1.0000e+00    1.0000e+00   -1.4682e-08   -1.4682e-08    1.0000e+00
 
* * *

...Single precision attained with an old version.


J.P. Fernandez
Department of Physics and Astronomy
University of Massachusetts


Reply | Threaded
Open this post in threaded view
|

Re: Does your machine also FFT like mine?

Jim Van Zandt
In reply to this post by Dirk Laurie

Dirk -

For your 5-point fft, the accuracy of version 2.0.11.92
(i686-pc-linux-gnu) is also only single precision.

                              - Jim Van Zandt


Reply | Threaded
Open this post in threaded view
|

Re: Does your machine also FFT like mine?

Kai Mueller-2
In reply to this post by Dirk Laurie
On Mon, May 11, 1998 at 05:17:27PM +0200, Dirk Laurie wrote:

> Encouraged by the prompt responses to my plot question -- thanks
> everyone! -- let me rephrase the FFT one to which nobody replied.
>
> On my Linux/586 machine, I get
>
> > ifft(fft([1 1 0 0 1]))
> ans =
>     1.0000e+00    1.0000e+00   -1.4682e-08   -1.4682e-08    1.0000e+00
>
> This is only single precision accurate.  Unfortunately the other
> machines I have access to have the same architecture and use the
> same binary and not surprisingly gives the same result.
>
> What happens on your machine?
>
> Dirk
>

My reply is a little late but this happens on
DEC Alpha, OSF3.2c, gcc 2.7.2.3, DEC f90:

-----------------------------------------------------------------------
octave:3> ifft(fft([1 1 0 0 1]))
ans =

    1.0000e+00    1.0000e+00   -1.4682e-08   -1.4682e-08    1.0000e+00

-----------------------------------------------------------------------
Without patching the fortran sources I recompiled the FORTRAN
sources using the "-fpconstant" switch to 90, i.e. I entered

     gnumake FFLAGS="-O -fpconstant".

The man page says:

  -fpconstant
      Extend the precision of single precision constants assigned to
      double precision variables to double precision.

I have no idea why this is not the default but the result looks ok:

-----------------------------------------------------------------------
octave:3> ifft(fft([1 1 0 0 1]))
ans =

   1.0000e+00   1.0000e+00   7.3275e-16   7.3275e-16   1.0000e+00

-----------------------------------------------------------------------

--
 Kai P. Mueller
 Control Department (Regelungstechnik) | Phone [+49] (531) 391-3835
 Technical University Braunschweig     | Fax   [+49] (531) 391-5194
 D-38092 Braunschweig                  | Email [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Does your machine also FFT like mine?

John W. Eaton-6
On 13-May-1998, Kai Mueller <[hidden email]> wrote:

| The man page says:
|
|   -fpconstant
|       Extend the precision of single precision constants assigned to
|       double precision variables to double precision.
|
| I have no idea why this is not the default

It has to do with when is the correct time to do the conversion to
double.  If I write

      double precision pi
      pi = 3.1415925358979

should this be evaluated as

  convert the string `3.1415925358979' to a single precision
  constant (thus losing some information) and then convert to double

or

  convert the string `3.1415925358979' to a constant with as much
  precision as necessary to avoid losing any information, then convert
  to a double precision constant.

If I recall correctly, there was quite a debate about this in the
comp.lang.fortran newsgroup several years ago.

Here is what the g77 manual has to say about this topic:

     `g77' strictly assigns types to all constants not documented as
  "typeless" (typeless constants including `'1'Z', for example).  Context
  is never a determining factor for the type, and hence the
  interpretation, of a typed constant.  Examples: `1' is always type
  `INTEGER', `9.435784839284958' is always type `REAL' (even if the
  additional precision specified is lost, and even when used in a `DOUBLE
  PRECISION' context), `1E0' is always type `REAL', and `1D0' is always
  type `DOUBLE PRECISION'.

     Many other Fortran compilers attempt to assign types to typed
  constants based on their context.  This results in hard-to-find bugs,
  nonportable code, and is not in the spirit (though it strictly follows
  the letter) of the 77 and 90 standards.  `g77' will not support these
  dangerous semantics, but might offer, in a future release, explicit
  constructs by which a wider variety of typeless constants may be
  specified, and/or user-requested warnings indicating places where `g77'
  might differ from how other compilers assign types to constants.


jwe



Reply | Threaded
Open this post in threaded view
|

Re: Does your machine also FFT like mine?

Kai Mueller-2
On Wed, May 13, 1998 at 02:45:31PM -0500, John W. Eaton wrote:
> It has to do with when is the correct time to do the conversion to
> double.  If I write
>
>       double precision pi
>       pi = 3.1415925358979
>

I understand that using a switch like "-fpconstant" for DEC f90
is "dangerous semantic". Does that mean that a portable source
code must use typed constants like "pi = 3.1415925358979D0"?
Thanks
Kai

--
 Kai P. Mueller
 Control Department (Regelungstechnik) | Phone [+49] (531) 391-3835
 Technical University Braunschweig     | Fax   [+49] (531) 391-5194
 D-38092 Braunschweig                  | Email [hidden email]