## mingw-users

 Re: [Mingw-users] math problem From: Daniel Raymond - 2005-02-21 20:44:32 ```I think I understand. You're saying: double -> float -> int (correct result) double -> int (incorrect result) Because in this particular case, the rounding from double to float eliminates the epsilon error before it can cause trouble in the truncation to int. So is there a way to force float -> int and double -> int conversions to round instead of truncate? ```
 Re: [Mingw-users] math problem From: HERNANDEZ CORDOBA RODRIGO JOSE - 2005-02-21 21:07:49 ```Probably because you are mixing floats,doubles and ints without explicitly casting anything, you're getting rounding errors. ----- Mensaje Original ----- De: Daniel Raymond Fecha: Lunes, Febrero 21, 2005 1:28 pm Asunto: [Mingw-users] math problem > \$ cat mathtest.c > int main(int argc, char *argv[]) > { > int pts = 31263; > int fields = 4; > float a = pts - fields * ((1 / (30.0 * 1000 / 1001)) / 2) * > 90000.0; int b = pts - fields * ((1 / (30.0 * 1000 / 1001)) / > 2) * 90000.0; > int c = a; > printf("%f %d %d\n", a, b, c); > } > \$ gcc mathtest.c -o mathtest.exe > \$ mathtest > 25257.000000 25256 25257 > \$ > > > Can someone explain why this is happening (why aren't a, b, and c > equal?). Is > this a bug in the compiler or am I doing something wrong? > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real > users.Discover which products truly live up to the hype. Start > reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > MinGW-users mailing list > MinGW-users@... > > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users > ```
 Re: [Mingw-users] math problem From: Daniel Raymond - 2005-02-21 21:14:45 ```>Probably because you are mixing floats,doubles and ints without >explicitly casting anything, you're getting rounding errors. You must be from the school of thought where you explicitly cast everything even when the implicit cast is the intended one. This doesn't help me here (unless code obfuscation is the goal). ```
 Re: [Mingw-users] math problem From: Earnie Boyd - 2005-02-21 22:12:04 ``` >>Probably because you are mixing floats,doubles and ints without >>explicitly casting anything, you're getting rounding errors. > > You must be from the school of thought where you explicitly cast > everything even when the implicit cast is the intended one. This > doesn't help me here (unless code obfuscation is the goal). > My ``school of thought'' teaches me that if I intend it then I must be explicit about it. Relying on others intentions (the implicit) is never the right thing to do when I want the result to be as I intended. Earnie -- http://www.mingw.org http://sourceforge.net/projects/mingw https://sourceforge.net/donate/index.php?user_id=15438 ```
 Re: [Mingw-users] math problem From: John Gaughan - 2005-02-21 23:47:26 ```Earnie Boyd wrote: > My ``school of thought'' teaches me that if I intend it then I must > be explicit about it. Relying on others intentions (the implicit) is > never the right thing to do when I want the result to be as I > intended. If you want something done right, you have to do it yourself. -- John Gaughan http://www.johngaughan.net/ john@... ```
 Re: [Mingw-users] math problem From: Daniel Raymond - 2005-02-21 22:19:03 ```>>>Probably because you are mixing floats,doubles and ints without >>>explicitly casting anything, you're getting rounding errors. >> >> You must be from the school of thought where you explicitly cast >> everything even when the implicit cast is the intended one. This >> doesn't help me here (unless code obfuscation is the goal). >> > >My ``school of thought'' teaches me that if I intend it then I must be >explicit about it. Relying on others intentions (the implicit) is never >the right thing to do when I want the result to be as I intended. > (noun)That (verb)is (adjective)extra (noun)work. ```
 Re: [Mingw-users] math problem From: Daniel Raymond - 2005-02-21 22:23:04 ```Or better yet: (adjective)Unnecessary (noun)casts (verb)make (noun)code (adjective)hard (conjunction)to (verb)read. ```
 [Mingw-users] Bullshit offtopic garbage messages From: Alex Perez - 2005-02-21 22:26:46 ```Daniel Raymond wrote: >Or better yet: > >(adjective)Unnecessary (noun)casts (verb)make (noun)code (adjective)hard >(conjunction)to (verb)read. > First of all, my extreme apologies for sending this to the list and not privately, but I think a point needs to be made. Or better yet, you both stop flooding our inboxes with USELESS TRIPE. (which, yes, I realize this message also is) ```
 Re: [Mingw-users] math problem From: Stephen Ray - 2005-02-21 22:29:34 ```Daniel Raymond wrote: > Or better yet: > > (adjective)Unnecessary (noun)casts (verb)make (noun)code (adjective)hard > (conjunction)to (verb)read. > But it does make the code do exactly what you meant it to do, and lets others know explicitly what you intended. Sometimes that's important. ```
 Re: [Mingw-users] math problem From: HERNANDEZ CORDOBA RODRIGO JOSE - 2005-02-21 22:37:34 ```> You must be from the school of thought where you explicitly cast > everything even when the implicit cast is the intended one. This > doesn't help me here (unless code obfuscation is the goal). Not really, but it just so happens that earlier today I was having problems setting up an Orthogonal projection in Direct3D, since I use MinGW, I avoid the D3DX functions and this code was giving me troubles: memset(&Ortho2D,0,sizeof(D3DMATRIX)); Ortho2D._11 =2.0f/viewport.Width; Ortho2D._22 =2.0f/-viewport.Height; // <- the problem was here Ortho2D._33 =1.0f; Ortho2D._41 =-1.0f; Ortho2D._42 =1.0f; Ortho2D._44 =1.0f; being that I was getting the wrong value, I tried Ortho2D._22 =2.0f/-float(viewport.Height); and problem fixed, was the other result wrong? maybe not, but it wasnt what I needed, so it was the wrong one for the situation, I dont know which of the values is the one you need, as for rounding, take a look at the ceil and floor functions, depending on what your needs are one of those will probably solve your problem. ```
 Re: [Mingw-users] math problem From: Rodrigo Hernandez - 2005-02-22 01:03:31 ```At 05:47 PM 21/02/2005, you wrote: > >memset(&Ortho2D,0,sizeof(D3DMATRIX)); > >Ortho2D._11 =2.0f/viewport.Width; > >Ortho2D._22 =2.0f/-viewport.Height; // <- the problem was here > >Ortho2D._33 =1.0f; > >Ortho2D._41 =-1.0f; > >Ortho2D._42 =1.0f; > >Ortho2D._44 =1.0f; > >These are examples of what I would call unnecessary casts. The presence of a >decimal point indicates a floating point constant. Correct me if I'm >wrong but >without the "f" these constants will be of type "double" and with the "f" >these >constants will be of type "float". In either case the result is the same >because it will end up being converted to whatever type the lvalue is. You are correct f means float, nothing means double, however, assigning a double to a float variable will yield a warning, a double takes 8 bytes where a float takes 4, when those extra bytes get truncated, you dont know what you're going to get, according to your logic, its completely safe to do unsigned int X = -1; because hey! X knows it should convert -1 to an unsigned int. > >being that I was getting the wrong value, I tried > > > >Ortho2D._22 =2.0f/-float(viewport.Height); > > > >This doesn't look like a cast. It looks like a function call. Do you >know what >float() does? Converts what's inside the parenthesis to a float, which in this case solves my problem. Rodrigo Hernandez, lonewolf programmer Aeon Games http://www.aeongames.com ```
 Re: [Mingw-users] math problem From: Wu Yongwei - 2005-02-22 04:55:24 ```I believe this slightly changed example shows something: \$ cat mathtest.c #include #include int main(int argc, char *argv[]) { int pts = 31263; int fields = 4; long double a = pts - fields * ((1 / (30.0 * 1000 / 1001)) / 2) * 90000.0; int b = pts - fields * ((1 / (30.0 * 1000 / 1001)) / 2) * 90000.0; int c = a; printf("%f %d %d\n", (double)floorl(a), b, c); } \$ gcc mathtest.c -o mathtest \$ ./mathtest 25256.000000 25256 25256 \$ Checking the assembler output of the orignal program shows that only the to-int conversion has the rounding mode of truncating to zero. Rounding mode between floating-point types is rounding to nearest (even). All these seem to conform to the C standard (rounding between FP types, and truncating between FP and INT types). So your result is really expected. The cast-to-double is just there to work around the printf limitation. Best regards, Yongwei Daniel Raymond To: mingw-users@... CC: Subject: [Mingw-users] math problem \$ cat mathtest.c int main(int argc, char *argv[]) { int pts = 31263; int fields = 4; float a = pts - fields * ((1 / (30.0 * 1000 / 1001)) / 2) * 90000.0; int b = pts - fields * ((1 / (30.0 * 1000 / 1001)) / 2) * 90000.0; int c = a; printf("%f %d %d\n", a, b, c); } \$ gcc mathtest.c -o mathtest.exe \$ mathtest 25257.000000 25256 25257 \$ Can someone explain why this is happening (why aren't a, b, and c equal?). Is this a bug in the compiler or am I doing something wrong? ```
 Re: [Mingw-users] math problem From: Joel Salomon - 2005-02-22 21:00:28 ```On Tue, 22 Feb 2005 12:48:08 +0800, Wu Yongwei wrote: > I believe this slightly changed example shows something: > long double a = pts - fields * ((1 / (30.0 * 1000 / 1001)) / 2) * 90000.0; > Interesting. Single-precision dropped just enough to be accidentally accurate, and double-extended-precision *kept* enough to stay accurate. Cute. --Joel ```
 Re: [Mingw-users] math problem From: Michael Gerdau - 2005-02-21 22:04:06 Attachments: application/pgp-signature ```Am Montag, 21. Februar 2005 21:44 schrieb Daniel Raymond: > I think I understand. You're saying: >=20 > double -> float -> int (correct result) > double -> int (incorrect result) Almost but not quite. Your assessment regarding correctness is true in this particular case. In general it might be different. > Because in this particular case, the rounding from double to float > eliminates the epsilon error before it can cause trouble in the > truncation to int. That's correct. > So is there a way to force float -> int and double -> int > conversions to round instead of truncate? There is. The quick and dirty method found in many legacy FORTRAN programs is to simply add 0.5 to the double/float result before truncating to int. That works correctly in most cases. However if you wish to have correct mathematical rounding (i.e. round .5 to the nearest even digit) then you'll have to apply a function. Note that round() doesn't round mathematically correct. Use nearbyint or rint() instead. But then your completely ignoring that your floating point math is inherently wrong due to representation limits of the numbers you deal with (including all intermediate results). Best, Michael =2D-=20 Vote against SPAM - see http://www.politik-digital.de/spam/ Michael Gerdau email: mgd@... GPG-keys available on request or at public keyserver ```