|
|
 Up |
|
|
  |
Author: e p chandlere p chandler Date: May 28, 2008 10:53
This is related to a different thread in which the OP claimed that
numbers set to 0 were being displayed as approx. e-309.
While playing with numbers in this range, I encountered what appears
to be a bug in g95. (See Google's gg95)
Apparently there is a problem with assigning a very small double
precision literal to a 10-byte real. (MinGW on Win32). Assigning a
literal of the proper kind resolves the problem.
Of course I realize that assigning a real constant to a double
precision variable, etc. may result in loss of precision, but in this
case it seems more like a real error. It looks like a bit gets dropped
near 1e-308.
Program listing:
C:\temp>type x.f95
real*10 x,y
x=1d-306
y=1e-306_10
print *,306,x,y
print '(2(e30.20e4,/))',x,y
|
| Show full article (2.56Kb) |
|
| | 12 Comments |
|
|
Author: James Van BuskirkJames Van Buskirk Date: May 28, 2008 18:43
> Apparently there is a problem with assigning a very small double
> precision literal to a 10-byte real. (MinGW on Win32). Assigning a
> literal of the proper kind resolves the problem.
Yeah, and FX relates to me that it's not only g95 that can run into
problems with denormals. He gave an example where BOZ
representations of denormals could be converted improperly, but
inconsistently so in gfortran and said that other compilers faced
problems. Likely the problem is that denormals are a special case
so that code where they are handled is not as well tested as the
normal case.
Just for fun, tell me what g95 does with the following:
C:\gcc_mingw64a\test\denormal>type denormal.f90
real*10 x,y
x=1d-306
y=1e-306_10
print *,306,x,y
print '(2(e30.20e4,/))',x,y
|
| Show full article (2.64Kb) |
|
| | no comments |
|
|
Author: James Van BuskirkJames Van Buskirk Date: May 28, 2008 20:01
"James Van Buskirk" comcast.net> wrote in message
news:ZNidnfL7Zs7Jl6PVnZ2dnUVZ_vCdnZ2d@comcast.com...
> Just for fun, tell me what g95 does with the following:
And for even more fun, this experiment tempting overflow:
C:\gcc_mingw64a\test\denormal>type mega.f90
program mega
real(4) x4
real(8) x8
real(10) x10
real pi
pi = 4*atan(1.0)
x4 = 2
x4 = log(huge(x4))+log(x4)*1.1
write(*,*) cos(complex(pi/4,x4))
x4 = log(huge(x4))
write(*,*) cos(complex(pi/4,x4))
|
| Show full article (1.50Kb) |
| no comments |
|
|
Author: e p chandlere p chandler Date: May 28, 2008 20:12
On May 28, 9:43 pm, "James Van Buskirk" comcast.net> wrote:>> Apparently there is a problem with assigning a very small double
>> precision literal to a 10-byte real. (MinGW on Win32). Assigning a
>> literal of the proper kind resolves the problem.
>
> Yeah, and FX relates to me that it's not only g95 that can run into
> problems with denormals. He gave an example where BOZ
> representations of denormals could be converted improperly, but
> inconsistently so in gfortran and said that other compilers faced
> problems. Likely the problem is that denormals are a special case
> so that code where they are handled is not as well tested as the
> normal case.
>
> Just for fun, tell me what g95 does with the following:
>
> C:\gcc_mingw64a\test\denormal>type denormal.f90
> real*10 x,y
> ...
|
| Show full article (3.59Kb) |
| no comments |
|
|
Author: e p chandlere p chandler Date: May 28, 2008 20:21
On May 28, 11:01 pm, "James Van Buskirk" comcast.net>
wrote:> "James Van Buskirk" comcast.net> wrote in messagenews:ZNidnfL7Zs7Jl6PVnZ2dnUVZ_vCdnZ2d@comcast.com...
>>> Just for fun, tell me what g95 does with the following:
>
> And for even more fun, this experiment tempting overflow:
>
> C:\gcc_mingw64a\test\denormal>type mega.f90
> program mega
> real(4) x4
> real(8) x8
> real(10) x10
> real pi
>
> pi = 4*atan(1.0)
>
> x4 = 2
> x4 = log(huge(x4))+log(x4)*1.1
> write(*,*) cos(complex(pi/4,x4)) ...
|
| Show full article (3.61Kb) |
| no comments |
|
|
Author: James Van BuskirkJames Van Buskirk Date: May 28, 2008 20:52
> C:\Users\epc\AppData\Local\Temp/ccErGX8Q.o:mega.f90:(.text+0xb0):
> undefined refe
> rence to `complex_'
Oops. The COMPLEX intrinsic was a Craig Burley original, not
carried forward to g95. Here is the standard-conforming variant:
C:\gcc_mingw64a\test\denormal>type mega.f90
program mega
real(4) x4
real(8) x8
real(10) x10
real pi
pi = 4*atan(1.0)
x4 = 2
x4 = log(huge(x4))+log(x4)*1.1
write(*,*) cos(cmplx(pi/4,x4,kind(x4)))
x4 = log(huge(x4))
write(*,*) cos(cmplx(pi/4,x4,kind(x4)))
|
| Show full article (1.67Kb) |
| no comments |
|
|
Author: James Van BuskirkJames Van Buskirk Date: May 28, 2008 20:58
> Looking up TINY() shows:
> TINY(X) returns the smallest positive (non zero) number in the model
> of the type of X.
> Please explain what I am seeing in light of the above definition. Does
> this mean that specifying a literal in double precision where that
> literal is less than tiny() is invalid? Yet it seems to work with
> gfortran.
> At least you found the boundary where the bug is triggered.
--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end
|
| |
| no comments |
|
|
Author: e p chandlere p chandler Date: May 28, 2008 21:23
On May 28, 11:52 pm, "James Van Buskirk" comcast.net>
wrote:>> C:\Users\epc\AppData\Local\Temp/ccErGX8Q.o:mega.f90:(.text+0xb0):
>> undefined refe
>> rence to `complex_'
>
> Oops. The COMPLEX intrinsic was a Craig Burley original, not
> carried forward to g95. Here is the standard-conforming variant:
>
> C:\gcc_mingw64a\test\denormal>type mega.f90
> program mega
> real(4) x4
> real(8) x8
> real(10) x10
> real pi
>
> pi = 4*atan(1.0)
> ...
|
| Show full article (2.32Kb) |
| no comments |
|
|
Author: e p chandlere p chandler Date: May 28, 2008 22:09
On May 28, 11:58 pm, "James Van Buskirk" comcast.net>
wrote:>> Looking up TINY() shows:
>> TINY(X) returns the smallest positive (non zero) number in the model
>> of the type of X.
>> Please explain what I am seeing in light of the above definition. Does
>> this mean that specifying a literal in double precision where that
>> literal is less than tiny() is invalid? Yet it seems to work with
>> gfortran.
>> At least you found the boundary where the bug is triggered.
|
| Show full article (1.15Kb) |
| no comments |
|
|
|
|
|
Author: James Van BuskirkJames Van Buskirk Date: May 28, 2008 23:08
> OK. Here it goes with G95:
> C:\Users\epc\temp>g95 mega.f90
> C:\Users\epc\temp>a
> (2.5788508E+38,-2.5788508E+38)
> (1.2030801E+38,-1.2030801E+38)
> (+Inf,-Inf)
> (6.355804891857543E+307,-6.355805169678616E+307)
> (+Inf,-Inf)
> (4.2063359488591517347E+4931,-4.2063361327239468925E+4931)
> 3.4028235E+38
> 1.7976931348623157E+308
> 1.189731495357231765E+4932
|
| Show full article (1.38Kb) |
| no comments |
|
|
|
|
