Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo
Close
From: Greg Chicares <chicares@co...>  20070124 12:59:07

On 2007124 7:52 UTC, Aron Rubin wrote: > I have been pulling my hair out for several weeks here trying to > figure out why there are strange artifacts in my software. Tonight I > finally figured it out. The math library is broken (in my install). But MinGW has no real 'libm'no math library per se; it gets C math functions from the msvc runtime library provided as part of the operating system. A few functions are overridden by 'libmingwex', but by no means all. > All math functions return bogus numbers. It would help to have a testcase so we can see which math functions you're using, the options you use for compiling, and a copy of the results you see. > Just to get it out of the > way, yes I am including math.h. I have the latest mingwruntime > installed (11/18/06). > > For the moment I have made macro versions of some functions and > ffastmath seems to take care of the rest (I hope). What could be > causing this? It depends on the sort of bogosity you're observing. 
From: Aron Rubin <aronrubin@gm...>  20070124 07:52:13

I have been pulling my hair out for several weeks here trying to figure out why there are strange artifacts in my software. Tonight I finally figured it out. The math library is broken (in my install). All math functions return bogus numbers. Just to get it out of the way, yes I am including math.h. I have the latest mingwruntime installed (11/18/06). For the moment I have made macro versions of some functions and ffastmath seems to take care of the rest (I hope). What could be causing this? Aron 
From: Greg Chicares <chicares@co...>  20070124 12:59:07

On 2007124 7:52 UTC, Aron Rubin wrote: > I have been pulling my hair out for several weeks here trying to > figure out why there are strange artifacts in my software. Tonight I > finally figured it out. The math library is broken (in my install). But MinGW has no real 'libm'no math library per se; it gets C math functions from the msvc runtime library provided as part of the operating system. A few functions are overridden by 'libmingwex', but by no means all. > All math functions return bogus numbers. It would help to have a testcase so we can see which math functions you're using, the options you use for compiling, and a copy of the results you see. > Just to get it out of the > way, yes I am including math.h. I have the latest mingwruntime > installed (11/18/06). > > For the moment I have made macro versions of some functions and > ffastmath seems to take care of the rest (I hope). What could be > causing this? It depends on the sort of bogosity you're observing. 
From: Aron Rubin <aronrubin@gm...>  20070124 14:33:09
Attachments:
Message as HTML

On 1/24/07, Greg Chicares <chicares@...> wrote: > On 2007124 7:52 UTC, Aron Rubin wrote: > > I have been pulling my hair out for several weeks here trying to > > figure out why there are strange artifacts in my software. Tonight I > > finally figured it out. The math library is broken (in my install). > > But MinGW has no real 'libm'no math library per se; it gets > C math functions from the msvc runtime library provided as > part of the operating system. A few functions are overridden > by 'libmingwex', but by no means all. I realize this but lets say for example that the actual functions in msvc were single precision float but the prototypes in math.h were double it would cause behavior like this. > > > All math functions return bogus numbers. > > It would help to have a testcase so we can see which math > functions you're using, the options you use for compiling, > and a copy of the results you see. <pre>/*  Function: geo_geod_to_utm_hifi Transform a geographic (<latitude> <longitude>) coordinate to <UTM>. Parameters: ellipsoid_id  [in] the identifier for the ellipsoid to use found by <geo_ellipsoid_by_name> lat  [in] <latitude> (degrees) lon  [in] <longitude> (degrees) utm_zone  [out] <UTM> zone name consists of a numerical longitude zone and a letter identifying the latitude zone. The zone number actually specifies the reference meridian for <easting>. easting  [out] <easting> (meters) northing  [out] <northing> (meters) Notes:  Equations from USGS Bulletin 1532  East Longitudes are positive, West longitudes are negative.  North latitudes are positive, South latitudes are negative.  Lat and lon are in decimal degrees.  Originally written by Chuck Gantz <chuck.gantz@...> with no stated license.  */ void geo_geod_to_utm_hifi( int ellipsoid_id, double lat, double lon, char *utm_zone, double *easting, double *northing ) { double a = geo_ellipsoid_table[ellipsoid_id].equatorial_radius; double eccSquared = geo_ellipsoid_table[ellipsoid_id].eccentricity_squared; double k0 = 0.9996; double lon_origin; double eccPrimeSquared; double N, T, C, A, M; //Make sure the longitude is between 180.00 .. 179.9 double lontmp = (lon + 180.0)  floor( (lon + 180.0)*(1.0/360.0) )*360.0  180.0; double lat_rad = lat*DEGTORAD; double lon_rad = lontmp*DEGTORAD; double lon_origin_rad; int zone_num; printf( "floor val = %g\n", floor( (lon + 180.0)*(1.0/360.0) ) ); zone_num = (int)((lontmp + 180.0)*(1.0/6.0) + 1.0); if( lat >= 56.0 && lat < 64.0 && lontmp >= 3.0 && lontmp < 12.0 ) zone_num = 32; // Special zones for Svalbard if( lat >= 72.0 && lat < 84.0 ) { if( lontmp >= 0.0 && lontmp < 9.0 ) zone_num = 31; else if( lontmp >= 9.0 && lontmp < 21.0 ) zone_num = 33; else if( lontmp >= 21.0 && lontmp < 33.0 ) zone_num = 35; else if( lontmp >= 33.0 && lontmp < 42.0 ) zone_num = 37; } lon_origin = (zone_num  1)*6  180 + 3; //+3 puts origin in middle of zone lon_origin_rad = lon_origin*DEGTORAD; // set the UTM Zone from the latitude and longitude sprintf( utm_zone, "%d%c", zone_num, geo_utm_lat_zone_by_lat( lat ) ); eccPrimeSquared = (eccSquared)/(1eccSquared); N = a/sqrt(1  eccSquared*sin(lat_rad)*sin(lat_rad)); T = tan(lat_rad)*tan(lat_rad); C = eccPrimeSquared*cos(lat_rad)*cos(lat_rad); A = cos(lat_rad)*(lon_rad  lon_origin_rad); M = a*((1  eccSquared/4  3*eccSquared*eccSquared/64  5*eccSquared*eccSquared*eccSquared/256)*lat_rad  (3*eccSquared/8 + 3*eccSquared*eccSquared/32 + 45*eccSquared*eccSquared*eccSquared/1024)*sin(2*lat_rad) + (15*eccSquared*eccSquared/256 + 45*eccSquared*eccSquared*eccSquared/1024)*sin(4*lat_rad)  (35*eccSquared*eccSquared*eccSquared/3072)*sin(6*lat_rad)); *easting = (k0*N*(A+(1T+C)*A*A*A/6 + (518*T+T*T+72*C58*eccPrimeSquared)*A*A*A*A*A/120) + 500000.0); *northing = (k0*(M+N*tan(lat_rad)*(A*A/2+(5T+9*C+4*C*C)*A*A*A*A/24 + (6158*T+T*T+600*C330*eccPrimeSquared)*A*A*A*A*A*A/720))); if( lat < 0 ) *northing += 10000000.0; //10,000,000 meter offset for southern hemisphere } </pre> > > > Just to get it out of the > > way, yes I am including math.h. I have the latest mingwruntime > > installed (11/18/06). > > > > For the moment I have made macro versions of some functions and > > ffastmath seems to take care of the rest (I hope). What could be > > causing this? > > It depends on the sort of bogosity you're observing. > >  > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys  and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Mingwmsys mailing list > Mingwmsys@... > https://lists.sourceforge.net/lists/listinfo/mingwmsys > 
From: Earnie Boyd <earnie@us...>  20070124 15:31:20

Quoting Aron Rubin <aronrubin@...>: > I have been pulling my hair out for several weeks here trying to > figure out why there are strange artifacts in my software. Tonight I > finally figured it out. The math library is broken (in my install). > All math functions return bogus numbers. Just to get it out of the > way, yes I am including math.h. I have the latest mingwruntime > installed (11/18/06). > > For the moment I have made macro versions of some functions and > ffastmath seems to take care of the rest (I hope). What could be > causing this? > How would I be able to know? You haven't provided samples of the issue. All you have done is ranted about the issue and wasted several hundreds of peoples time who might have been able to answer. And this question belongs to mingwusers as it isn't MSYS specific. Earnie Boyd  Please post responsibly: * Use text posts instead of html; many list members just trash mail with html. * Do not use multipart mime to send both text and html versions. * Do not top post replies; post inline with the parts you are responding to. * Trim the post replies; remove irrelevant information from the quoted article. * Original posters: ** Provide small complete examples of the problem. ** Provide the full command that produced errors. ** Provide the versions of the software used. 
From: Aron Rubin <aronrubin@gm...>  20070124 15:51:45

My apologies. If you check the time stamp on the original that may explain some. Also I am trying to be careful to not release any proprietary code. So I will have to spend time coming up with a test case. Not sure I really deserve the spite, it is possible that someone else had seen this behavior and would have a simple remedy without we needing to provide any code. I will now transfer the discussion to mingwusers. Aron On 1/24/07, Earnie Boyd <earnie@...> wrote: > Quoting Aron Rubin <aronrubin@...>: > > > I have been pulling my hair out for several weeks here trying to > > figure out why there are strange artifacts in my software. Tonight I > > finally figured it out. The math library is broken (in my install). > > All math functions return bogus numbers. Just to get it out of the > > way, yes I am including math.h. I have the latest mingwruntime > > installed (11/18/06). > > > > For the moment I have made macro versions of some functions and > > ffastmath seems to take care of the rest (I hope). What could be > > causing this? > > > > How would I be able to know? You haven't provided samples of the > issue. All you have done is ranted about the issue and wasted several > hundreds of peoples time who might have been able to answer. And this > question belongs to mingwusers as it isn't MSYS specific. > > Earnie Boyd >  > Please post responsibly: > * Use text posts instead of html; many list members just trash mail with > html. > * Do not use multipart mime to send both text and html versions. > * Do not top post replies; post inline with the parts you are responding to. > * Trim the post replies; remove irrelevant information from the quoted > article. > * Original posters: > ** Provide small complete examples of the problem. > ** Provide the full command that produced errors. > ** Provide the versions of the software used. > >  > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys  and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Mingwmsys mailing list > Mingwmsys@... > https://lists.sourceforge.net/lists/listinfo/mingwmsys > 
From: Aron Rubin <aronrubin@gm...>  20070128 19:17:24
Attachments:
Message as HTML

Last post on the matter. I figured out the puzzle. I had installed a few GnuWin32 packages to get libpng and libjpeg. Apparently one of these packages came with a bogus libm. Aron PS #include <stdio.h> #include <math.h> #include <stdlib.h> int main( int argc, char *argv[] ) { double number, result; if( argc > 1 ) { strtod( argv[0], NULL ); } else { srand( time( NULL ) ); number = ((double)rand())/(double)RAND_MAX; } result = floor( number ); printf( "floor( %g ) => %g\n\n", number, result ); result = ceil( number ); printf( "ceil( %g ) => %g\n\n", number, result ); result = sqrt( number ); printf( "sqrt( %g ) => %g\n\n", number, result ); result = sin( number ); printf( "sin( %g ) => %g\n\n", number, result ); result = cos( number ); printf( "cos( %g ) => %g\n\n", number, result ); result = atan( number ); printf( "atan( %g ) => %g\n\n", number, result ); return( 0 ); } $ ./mathtest.exe floor( 0.393353 ) => 0.393353 ceil( 0.393353 ) => 0.393353 sqrt( 0.393353 ) => 6.90468e+137 sin( 0.393353 ) => 1 cos( 0.393353 ) => 0 atan( 0.393353 ) => 1.5708 