math.h fmod() problem

View: New views
6 Messages — Rating Filter:   Alert me  

math.h fmod() problem

by myso :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hi,
 I'm not a C guru, so if there will be any basic mistakes present, I'm sorry.
I guess this is a MinGW sepcific problem.

I'm working with doubles and I need to get a floating-point reminder using the fmod() function.
I think it doesn't work correctly. fmod() gives me wrong results and I also tried using fmodf() with casting the double variables to floats. It didn't work either.

Here are some practical examples:

double range, tempSS;

tempSS = 0.04;
range = 4; //both these numbers are received as arguments of a callback function, this is just one case

double value = fmod(range, tempSS); //the result was 0,04 which is wrong, because it should be zero

I tried to use the fmodf() function instead like this:

double value = (double)fmodf( (float)range, (float) tempSS);

The result seemed to be zero (as it was supposed be), however in

if(value != 0)
{
     //program jumped here so the zero doesn't seem to be a real zero
}

So I tried this:

fprintf(stdout, "value: %f , %e , %g\n", value, value, value);

and the output was:

value 0,000000 , 8,940697e-008 , 8,9407e-008

So it seems the zero isn't a real zero after all. And maybe that's the reason why the if statement doesn't work as I'd expect it to.
The question is - why is this so? And why doesn't the fmod() function give me the correct results for doubles.

thanks,

myso




Re: math.h fmod() problem

by Martin Prüsse :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On Wed, Nov 4, 2009 at 8:39 PM, myso <myso77@...> wrote:
> double value = fmod(range, tempSS); //the result was 0,04 which is wrong,
> because it should be zero

With a bit of debug gdb showed the MS supplied msvcrt in my computer
(0x77c2ced0 in msvcrt!fmod \(\) from C:\WINDOWS\system32\msvcrt.dll).
Since the msdn site for the function did not show any restriction
about the parameters this maybe are a MS problem.

> if(value != 0)
> {
>     //program jumped here so the zero doesn't seem to be a real zero
> }

You are right, this way is not safe to check floats and doubles, check
http://www.cygnus-software.com/papers/comparingfloats/Comparing%20floating%20point%20numbers.htm.

Martin

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
MinGW-users mailing list
MinGW-users@...

A: Yes.
> Q: Is it really?
>> A: Because the logical conversation flow is disrupted.
>>> Q: Why does MinGW object to top posting?
(abstracted from Larry Hall signature)

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.

Most annoying abuses are:
1) Top posting
2) Thread hijacking
3) HTML/MIME encoded mail
4) Improper quoting
5) Improper trimming
_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users

Re: math.h fmod() problem

by myso :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message



> Od: Martin Prüsse <prusse.martin@...>
> Predmet: Re: [Mingw-users] math.h fmod() problem
> Dátum: 05.11.2009 22:59:46
> ----------------------------------------
> On Wed, Nov 4, 2009 at 8:39 PM, myso <myso77@...> wrote:
> > double value = fmod(range, tempSS); //the result was 0,04 which is wrong,
> > because it should be zero
>
> With a bit of debug gdb showed the MS supplied msvcrt in my computer
> (0x77c2ced0 in msvcrt!fmod \(\) from C:\WINDOWS\system32\msvcrt.dll).
> Since the msdn site for the function did not show any restriction
> about the parameters this maybe are a MS problem.
>
> > if(value != 0)
> > {
> >     //program jumped here so the zero doesn't seem to be a real zero
> > }
>
> You are right, this way is not safe to check floats and doubles, check
> http://www.cygnus-software.com/papers/comparingfloats/Comparing%20floating%20point%20numbers.htm.
>
> Martin

Thank you Martin.
I'll check the article.

However, couldn't the fmod() function problem be somehow connected to this issue?
http://old.nabble.com/mingw32-gcc-(Graphite)-and-float-numbers-to24446439.html#a24582282

I read the whole thread, but I'm definitely not enough experienced to understand everything that was discussed.
I work on a scientefic application and I just have to be sure all the floats and doubles are visualised, stored and processed correctly.
Is working with floats in an application  compiled in MinGW perfectly safe?

Cheers,
Michael



> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> MinGW-users mailing list
> MinGW-users@...
>
> A: Yes.
> > Q: Is it really?
> >> A: Because the logical conversation flow is disrupted.
> >>> Q: Why does MinGW object to top posting?
> (abstracted from Larry Hall signature)
>
> This list observes the Etiquette found at
> http://www.mingw.org/Mailing_Lists.
> We ask that you be polite and do the same.
>
> Most annoying abuses are:
> 1) Top posting
> 2) Thread hijacking
> 3) HTML/MIME encoded mail
> 4) Improper quoting
> 5) Improper trimming
> _______________________________________________
> You may change your MinGW Account Options or unsubscribe at:
> https://lists.sourceforge.net/lists/listinfo/mingw-users
>
>
>

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
MinGW-users mailing list
MinGW-users@...

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users

Re: math.h fmod() problem

by Greg Chicares-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On 2009-11-06 12:19Z, Michael T. wrote:
[...]
> However, couldn't the fmod() function problem be somehow connected to
> this issue?
> http://old.nabble.com/mingw32-gcc-(Graphite)-and-float-numbers-to24446439.html#a24582282
>
> I read the whole thread, but I'm definitely not enough experienced to
> understand everything that was discussed.

That thread seems to discuss the effect of strict aliasing on how
floating-point numbers are formatted in code provided by MinGW.
I don't see how that would be related to your issue.

> I work on a scientefic application and I just have to be sure all the
> floats and doubles are visualised, stored and processed correctly.
> Is working with floats in an application  compiled in MinGW perfectly
> safe?

It's not perfectly safe with any compiler: they all have defects.
Yet I've done a lot of floating-point work with several different
compilers, and I think MinGW gcc is as good as any other I've used.

Any issue with the mscvrt implementation of fmod() would affect
contemporary versions of the ms compiler as well as MinGW. I'm
not convinced that implementation is defective, though: the
remainder of 4.0 / 0.4 isn't exactly zero in computer floating
point. See this classic paper:
  http://docs.sun.com/source/806-3568/ncg_goldberg.html

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
MinGW-users mailing list
MinGW-users@...

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users

Re: math.h fmod() problem

by myso :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


> ------------ Pôvodná správa ------------
> Od: Greg Chicares <gchicares@...>
> Predmet: Re: [Mingw-users] math.h fmod() problem
> Dátum: 06.11.2009 19:18:38
> ----------------------------------------
> On 2009-11-06 12:19Z, Michael T. wrote:
> [...]
> > However, couldn't the fmod() function problem be somehow connected to
> > this issue?
> >

Just in case anybody was interested both the fmod() and fmodf() functions don't work as they should be and I found out it's not
a MinGW problem but a MS Windows problem.

According to this http://msdn.microsoft.com/en-us/library/20dckbeh(VS.71).aspx
they should be working (I ran it on Win XP which matches the compatibility issue). But I tried to compile a simple application using MS Visual Studio and the result for

fmod(8, 0.05);

was 0.05, but should be zero because 8 is divisible by 0.05.

So I guess I'll have to write my own function for the purpose.

m.
 

> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> MinGW-users mailing list
> MinGW-users@...
>
> This list observes the Etiquette found at
> http://www.mingw.org/Mailing_Lists.
> We ask that you be polite and do the same.  Disregard for the list etiquette may
> cause your account to be moderated.
>
> _______________________________________________
> You may change your MinGW Account Options or unsubscribe at:
> https://lists.sourceforge.net/lists/listinfo/mingw-users
>
>
>

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
MinGW-users mailing list
MinGW-users@...

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users

Re: math.h fmod() problem

by Tor Lillqvist :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

>  But I tried to compile a simple application using MS Visual Studio and the result for
> fmod(8, 0.05);
>
> was 0.05, but should be zero because 8 is divisible by 0.05

Floating point doesn't always work as one would naïvely expect.

Visual Studio is in good company here. The same happens with gcc on
Linux. But actually, what you think happens, does not actually happen.
The result is *not* 0.05.

Print out the result with more precision and you will see that it
isn't 0.05 but 0.049999999999999947. Which is less than 0.05, so
fmod() works correctly according to its definition:

      "The fmod function calculates the floating-point remainder f of
      x / y such that x = i * y + f, where i is an integer, f has the
      same sign as x, and the absolute value of f is less than the
      absolute value of y."

Note especially the part after "such that"! It would be "correct" for
fmod() to return in this case any value >= 0 and < 0.5 here. Sure,
returning a value a tiny bit (pun intended) smaller than 0.5 is quite
counter-intuitive, but that's typical for floating point.

Try this test program:

#include <math.h>
#include <stdio.h>

int
main (int argc, char **argv)
{
  int i;

  for (i = 0; i < 5; i++)
    {
      double m;

#define TEST(y) \
      m = fmod(1 << i, y); \
      printf ("fmod(%d, "#y") = %.18f\n", 1 << i, m); \
      if (m >= y) \
        printf ("which is bogus!\n")

      TEST (0.05);
      TEST (0.1);
      TEST (0.5);
    }

  return 0;
}

--tml

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
MinGW-users mailing list
MinGW-users@...

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users