Reputation: 499
fmod returns inconsistent value
Ran into an odd bug while trying to play around with some perlin noise functions. All of the sudden I got a off value in the middle of all of my calls. Traced it down to an inconsistent return value in fmod().
i=512;
cout << i << "," << fmod(i/102.4,1.f) << "," << fmod(i/102.4,1.f) << endl;
I would expect to get the following output.
512,0,0
But I don't. I get this.
512,0,1
What is even MORE strange is that if I call the cout line several times, the error goes away on the later runs.
512,0,1
512,0,0
512,0,0
Hard coding the value into the function (replace all the 'y' with '512') results in the correct results (always returns 0).
Has anyone ever seen a result like this?
Upvotes: 2
Views: 2176
Answers (2)
Reputation: 263267
It's not a gcc or library bug. It's just a result of an imprecise floating-point representation.
i=512;
cout << i << "," << fmod(i/102.4,1.f) << "," << fmod(i/102.4,1.f) << endl;
The mathematical result of 512/102.4 is exactly 5. But 102.4 cannot be represented exactly in binary floating-point, so the value passed to fmod could be either exactly 5.0, or slightly above or below it.
If the result of the division is, say, 4.99999999, then fmod(i/102.4,1.f) will return 0.99999999, which will likely be rounded on output to 1.
Try displaying the value with more precision.
You'll need to modify your code so it allows for values very slightly smaller than what you're expecting. Since fmod() is a discontinuous function, it can magnify such differences tremendously.
This program:
#include <iostream>
#include <iomanip>
#include <cmath>
int main(void) {
int i = 512;
std::cout << i << ","
<< std::setprecision(20) << fmod(i/102.4,1.f)
<< "," << fmod(i/102.4,1.f) << std::endl;
return 0;
}
produces this output on my system:
512,0,0.99999999999999977796
Upvotes: 3
Reputation: 3753
Final Edit: This is almost certainly a bug in either GCC or glibc. Simply declaring a function that calls fmod somewhere else in the code (even if that function doesn't get called) makes the problem go away.
I suggest passing -fno-builtins to the compiler to work around this. Thas seems to fix it for me.
I'm able to reproduce this in GCC 4.5.3 for cygwin.
This only happens if the i variable is non-const [Edit: Probably because it's encouraging the compiler to use a temporary to store the result of the initial division). My even simpler C program to test:
#include <stdio.h>
#include <math.h>
int main()
{
int i = 512;
printf("%f %f\n", fmod(i/102.4,1.f), fmod(i/102.4,1.f));
printf("%f %f\n", fmod(i/102.4,1.f), fmod(i/102.4,1.f));
}
Which outputs:
0.000000 1.000000
0.000000 0.000000
I've tried looking through the asm output, but my x87-foo is weak. Can anyone else see what's wrong? I'll keep looking in the meantime:
.file "test.cpp"
.section .debug_abbrev,"dr"
Ldebug_abbrev0:
.section .debug_info,"dr"
Ldebug_info0:
.section .debug_line,"dr"
Ldebug_line0:
.text
Ltext0:
.def ___main; .scl 2; .type 32; .endef
.section .rdata,"dr"
LC3:
.ascii "%f %f\12\0"
.text
.globl _main
.def _main; .scl 2; .type 32; .endef
_main:
LFB7:
.file 1 "test.cpp"
.loc 1 6 0
pushl %ebp
LCFI0:
movl %esp, %ebp
LCFI1:
andl $-16, %esp
LCFI2:
subl $64, %esp
LCFI3:
.loc 1 6 0
call ___main
LBB2:
.loc 1 7 0
movl $512, 60(%esp)
.loc 1 8 0
fildl 60(%esp)
fldl LC0
fdivrp %st, %st(1)
fld1
fld %st(1)
L2:
fprem
fnstsw %ax
sahf
jp L2
fstp %st(1)
fucomi %st(0), %st
jp L5
fucomi %st(0), %st
je L6
fstp %st(0)
jmp L4
L5:
fstp %st(0)
L4:
fld1
fstpl 8(%esp)
fstpl (%esp)
call _fmod
jmp L3
L6:
fstp %st(1)
L3:
fstpl 40(%esp)
fildl 60(%esp)
fldl LC0
fdivrp %st, %st(1)
fld1
fstpl 8(%esp)
fstpl (%esp)
call _fmod
fldl 40(%esp)
fstpl 12(%esp)
fstpl 4(%esp)
movl $LC3, (%esp)
call _printf
.loc 1 9 0
fildl 60(%esp)
fldl LC0
fdivrp %st, %st(1)
fld1
fstpl 8(%esp)
fstpl (%esp)
call _fmod
fstpl 32(%esp)
fildl 60(%esp)
fldl LC0
fdivrp %st, %st(1)
fld1
fstpl 8(%esp)
fstpl (%esp)
call _fmod
fldl 32(%esp)
fstpl 12(%esp)
fstpl 4(%esp)
movl $LC3, (%esp)
call _printf
LBE2:
movl $0, %eax
.loc 1 10 0
leave
LCFI4:
ret
LFE7:
.section .rdata,"dr"
.align 8
LC0:
.long -1717986918
.long 1079613849
.section .debug_frame,"dr"
Lframe0:
.long LECIE0-LSCIE0
LSCIE0:
.long 0xffffffff
.byte 0x1
.ascii "\0"
.uleb128 0x1
.sleb128 -4
.byte 0x8
.byte 0xc
.uleb128 0x4
.uleb128 0x4
.byte 0x88
.uleb128 0x1
.align 4
LECIE0:
LSFDE0:
.long LEFDE0-LASFDE0
LASFDE0:
.secrel32 Lframe0
.long LFB7
.long LFE7-LFB7
.byte 0x4
.long LCFI0-LFB7
.byte 0xe
.uleb128 0x8
.byte 0x85
.uleb128 0x2
.byte 0x4
.long LCFI1-LCFI0
.byte 0xd
.uleb128 0x5
.byte 0x4
.long LCFI4-LCFI1
.byte 0xc5
.byte 0xc
.uleb128 0x4
.uleb128 0x4
.align 4
LEFDE0:
.section .eh_frame,"w"
Lframe1:
.long LECIE1-LSCIE1
LSCIE1:
.long 0x0
.byte 0x1
.ascii "\0"
.uleb128 0x1
.sleb128 -4
.byte 0x8
.byte 0xc
.uleb128 0x4
.uleb128 0x4
.byte 0x88
.uleb128 0x1
.align 4
LECIE1:
LSFDE3:
.long LEFDE3-LASFDE3
LASFDE3:
.long LASFDE3-Lframe1
.long LFB7
.long LFE7-LFB7
.byte 0x4
.long LCFI0-LFB7
.byte 0xe
.uleb128 0x8
.byte 0x85
.uleb128 0x2
.byte 0x4
.long LCFI1-LCFI0
.byte 0xd
.uleb128 0x5
.byte 0x4
.long LCFI4-LCFI1
.byte 0xc5
.byte 0xc
.uleb128 0x4
.uleb128 0x4
.align 4
LEFDE3:
.text
Letext0:
.section .debug_loc,"dr"
Ldebug_loc0:
LLST0:
.long LFB7-Ltext0
.long LCFI0-Ltext0
.word 0x2
.byte 0x74
.sleb128 4
.long LCFI0-Ltext0
.long LCFI1-Ltext0
.word 0x2
.byte 0x74
.sleb128 8
.long LCFI1-Ltext0
.long LCFI4-Ltext0
.word 0x2
.byte 0x75
.sleb128 8
.long LCFI4-Ltext0
.long LFE7-Ltext0
.word 0x2
.byte 0x74
.sleb128 4
.long 0x0
.long 0x0
.section .debug_info,"dr"
.long 0x13a
.word 0x2
.secrel32 Ldebug_abbrev0
.byte 0x4
.uleb128 0x1
.ascii "GNU C++ 4.5.3\0"
.byte 0x4
.ascii "test.cpp\0"
.ascii "/home/martin\0"
.long Ltext0
.long Letext0
.secrel32 Ldebug_line0
.uleb128 0x2
.byte 0x4
.byte 0x7
.ascii "unsigned int\0"
.uleb128 0x2
.byte 0x1
.byte 0x6
.ascii "char\0"
.uleb128 0x2
.byte 0x1
.byte 0x6
.ascii "signed char\0"
.uleb128 0x2
.byte 0x1
.byte 0x8
.ascii "unsigned char\0"
.uleb128 0x2
.byte 0x2
.byte 0x5
.ascii "short int\0"
.uleb128 0x2
.byte 0x2
.byte 0x7
.ascii "short unsigned int\0"
.uleb128 0x2
.byte 0x4
.byte 0x5
.ascii "int\0"
.uleb128 0x2
.byte 0x8
.byte 0x5
.ascii "long long int\0"
.uleb128 0x2
.byte 0x8
.byte 0x7
.ascii "long long unsigned int\0"
.uleb128 0x2
.byte 0x4
.byte 0x5
.ascii "long int\0"
.uleb128 0x2
.byte 0x4
.byte 0x7
.ascii "long unsigned int\0"
.uleb128 0x2
.byte 0x8
.byte 0x4
.ascii "double\0"
.uleb128 0x2
.byte 0x4
.byte 0x4
.ascii "float\0"
.uleb128 0x2
.byte 0xc
.byte 0x4
.ascii "long double\0"
.uleb128 0x3
.byte 0x1
.ascii "main\0"
.byte 0x1
.byte 0x5
.long 0x98
.long LFB7
.long LFE7
.secrel32 LLST0
.uleb128 0x4
.long LBB2
.long LBE2
.uleb128 0x5
.ascii "i\0"
.byte 0x1
.byte 0x7
.long 0x98
.byte 0x2
.byte 0x74
.sleb128 60
.byte 0x0
.byte 0x0
.byte 0x0
.section .debug_abbrev,"dr"
.uleb128 0x1
.uleb128 0x11
.byte 0x1
.uleb128 0x25
.uleb128 0x8
.uleb128 0x13
.uleb128 0xb
.uleb128 0x3
.uleb128 0x8
.uleb128 0x1b
.uleb128 0x8
.uleb128 0x11
.uleb128 0x1
.uleb128 0x12
.uleb128 0x1
.uleb128 0x10
.uleb128 0x6
.byte 0x0
.byte 0x0
.uleb128 0x2
.uleb128 0x24
.byte 0x0
.uleb128 0xb
.uleb128 0xb
.uleb128 0x3e
.uleb128 0xb
.uleb128 0x3
.uleb128 0x8
.byte 0x0
.byte 0x0
.uleb128 0x3
.uleb128 0x2e
.byte 0x1
.uleb128 0x3f
.uleb128 0xc
.uleb128 0x3
.uleb128 0x8
.uleb128 0x3a
.uleb128 0xb
.uleb128 0x3b
.uleb128 0xb
.uleb128 0x49
.uleb128 0x13
.uleb128 0x11
.uleb128 0x1
.uleb128 0x12
.uleb128 0x1
.uleb128 0x40
.uleb128 0x6
.byte 0x0
.byte 0x0
.uleb128 0x4
.uleb128 0xb
.byte 0x1
.uleb128 0x11
.uleb128 0x1
.uleb128 0x12
.uleb128 0x1
.byte 0x0
.byte 0x0
.uleb128 0x5
.uleb128 0x34
.byte 0x0
.uleb128 0x3
.uleb128 0x8
.uleb128 0x3a
.uleb128 0xb
.uleb128 0x3b
.uleb128 0xb
.uleb128 0x49
.uleb128 0x13
.uleb128 0x2
.uleb128 0xa
.byte 0x0
.byte 0x0
.byte 0x0
.section .debug_pubnames,"dr"
.long 0x17
.word 0x2
.secrel32 Ldebug_info0
.long 0x13e
.long 0x10d
.ascii "main\0"
.long 0x0
.section .debug_pubtypes,"dr"
.long 0xe
.word 0x2
.secrel32 Ldebug_info0
.long 0x13e
.long 0x0
.section .debug_aranges,"dr"
.long 0x1c
.word 0x2
.secrel32 Ldebug_info0
.byte 0x4
.byte 0x0
.word 0x0
.word 0x0
.long Ltext0
.long Letext0-Ltext0
.long 0x0
.long 0x0
.def _fmod; .scl 2; .type 32; .endef
.def _printf; .scl 2; .type 32; .endef
[Edit: Note, it's always the first call to fmod that is returning the strange result (never later one's). The fmod calls are being evaluated right-to-left.
[Edit 2: Defining a function, double my_fmod(double a, double b) { return fmod(a, b); } and passing the calls through that makes the problem go away. ]
Upvotes: 4
Related Questions
- fmod function from math.h library in C not working correctly?
- c++ fmod returns 0.2 for fmod(0.6,0.2)
- Using fmod() in C always results in zero (0)
- output of fmod function c++
- Lots of errors when compiling project using FMOD with MinGW
- fmod or not fmod?
- Why Does fmod Produce Different Results?
- Inconsistencies when using cmath's fmod (C++)
- Comparison with fmod() result returning false
- C++ - fmod return the wrong answer