In the case this gives some clue: perldl> print rint(3); 127 (the same for any integer in the range 0-255)
perldl> print rint(3.0); 6015 (the same for any other values -it seems) 127 = 0x7F , 6015 = 0x177F Hernán J. González http://hjg.com.ar/ On Mon, Feb 23, 2009 at 7:09 PM, Sisyphus <[email protected]> wrote: > > ----- Original Message ----- From: "hernan gonzalez" <[email protected]> > >> >> I installed the Uwinnipeg package. This hasnt the strange (and scary) >> bug, I get the correct answer now. >> >> perldl> print $w,"\n"; >> [0 0.25 0.5 0.75 1 1.25 1.5 1.75 2 2.25] >> >> >> perldl> print rint ($w) ,"\n"; >> [0 0 0 1 1 1 2 2 2 2] >> >> I wonder what happened with the other distribution, the issue does not >> seem minor... > > The ActiveState ppm is built using the MSVC++ 6.0 (Microsoft) compiler, > whereas the Uwinnipeg ppm is built using the MinGW port of gcc. > I don't have MSVC++ 6.0 to check, but I do have MSVC++ 7.0 and I can confirm > that PDL::rint() also produces garbage when PDL is built using MSVC++ 7.0. > (It produces slightly different garbage to what you got ... but it's > garbage, nonetheless.) > > Clearly there is something in the implementation of rint() that confuses > Microsoft compilers. > I think that most builds of PDL utilise the rint() function from the > compiler's own math > library, but Microsoft compilers don't have such a function, so rint() is > provided by Basic/Math/rint.c (which ships with the PDL source). It's not > readily apparent to me exactly how these garbage values are being produced - > I'll try to work through the code over the coming days and see if I can work > out what's going on. > > Does anyone else here build PDL with a compiler that doesn't have its own > rint() ? ... and therefore makes use of Basic/Math/rint.c. > > Incidentally, Basic/Math/rint.c is rather simplistic - it produces different > results to gcc's rint(). > The gcc implementation of rint() rounds 0.5, 2.5, 4.5, etc downwards, but > Math/Basic/rint.c always rounds "half way" values upwards. > > This bug has, until now, gone undetected, as there is > apparently no tests in the PDL test suite capable of detecting it. > > Cheers, > Rob > > -- _______________________________________________ Perldl mailing list [email protected] http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
