----- 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
