Incorrect finfo from PPC longdouble (Trac #2077) #2669
Comments
|
@mwiebe wrote on 2012-03-12 I seem to recall that the finfo code is using an algorithm that automatically detects these parameters by manipulating values of the given dtype. I guess either there's something wrong with the algorithm, or the long double on that platform is extremely non-conformant. |
|
@charris wrote on 2012-03-12 The algorithm (which is kind of a mess) assumes an exponent/mantissa format, while the PPC long double is implemented using two doubles. I'm not even sure if eps really makes sense for it. I'd almost be inclined to hard code these values except that they may depend on compiler flags. |
|
#3125 has some useful information. |
|
Just started running tests on buildbot - failing on these double precision tests: http://nipy.bic.berkeley.edu/builders/numpy-py2.6-osx-10.5-ppc/builds/0/steps/shell_3/logs/stdio I wonder if something like a test for common precisions and backing off to hard coding would work. I'll have a think. |
|
I'd like that, actually. The current code for determining float precision is a mess. Basically there are two types we need to deal with: IEEE and IBM, hardcoding would be pretty easy to maintain, IMHO, work better, and be much easier to comprehend. There should be a check for IBM long doubles, like for the various IEEE types, and after that a way to expose that info. Or we could just combine endianess with the known specs for the IBM type. |
Hard-code the MachAr parameters for float64, float32, 80-bit extended precision, to save time, and provide skeleton for more difficult types such as the double double on PPC; see numpy#2669
* ENH: hard-code finfo parameters for known types Hard-code the MachAr parameters for float64, float32, 80-bit extended precision, to save time, and provide skeleton for more difficult types such as the double double on PPC; see #2669 * ENH: add PPC long double finfo Add parameters for PPC long double, fixing long-standing bug for finfo on PPC. * BF: use Python floats for float64 finfo For some reason (garrgh) np.exp2 with float64 gives a different answer on Windows than it does on other platforms; use Python floating point calculations instead, which do appear to be consistent. * DOC: add release notes for finfo fixes Add release note describing fixes for PPC long double ``finfo``. * RF: try using byte string to identify floats From suggestion by Chuck, and https//perl5.git.perl.org/perl.git/blob/3118d7d684b56cbeb702af874f4326683c45f045:/Configure * TST: add tests for reasonable finfo parameters Check that finfo returns somewhat reasonable parameters for all floating point types. * RF: add warning for not-recognized float type Warn if we don't have a signature for the float type. * NF: add IEEE float128 type signature Still needs test on platform with IEEE float128, to check MachAr-like parameters are correct.
|
Should be closed by #8504. |
Original ticket http://projects.scipy.org/numpy/ticket/2077 on 2012-03-10 by @matthew-brett, assigned to unknown.
I think the correct answers for nexp, nmant are 11, 106 respectively; see:
https://developer.apple.com/library/mac/#documentation/Darwin/Reference/Manpages/man3/float.3.html
The text was updated successfully, but these errors were encountered: