mailRe: r2777 - /branches/test_suite/test_suite/unit_tests/test_float.py


Others Months | Index by Date | Thread Index
>>   [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Header


Content

Posted by Edward d'Auvergne on November 13, 2006 - 15:01:
On 11/13/06, Gary S. Thompson <garyt@xxxxxxxxxxxxxxx> wrote:
Edward d'Auvergne wrote:

> Gary, in these tests you have been using the 'float()' function for
> creating numbers.  Would it be better to create a large number of
> IEEE-754 bit patterns (as strings) covering all number types (and
> possibly multiple +/- NaNs with different bits in the mantissa) and
> then convert these to 64 bit floats taking endianness into account?
> This should be more portable than using the 'float()' function and
> give us much better control of the floats.
>
The logic here was that we should use the in-built float function for
anything other than special values as they will always be more
rigourously tested than anything we produce ;-)

That makes sense. I have created an exact value for FLOAT_EPSILON in the constants I added to the bottom of 'float.py'.


as to testing multiple nan patterns that is a good idea, and I was
planning to add that at a later date. There is just a single nan
pattern  in float.py here so that we can create a constant...

I tried to keep the float.py module containing just  the constants &
functions which are used to check the contents of floats and to give
values for the special floats inf, zero,and nan

I have another file which I haven't submitted to svn yet which contains
utility functions and information about the float capabilites of a
platform. However, it is extremley ropey in places....

It also has functions for printing floats as bit patterns of hex and
binary ;-)

I'll talk about the the 'float' and 'ieeefloatcapabilities' modules in the next post. You should commit this unfinished code though - the repository is designed for managing works in progress. I'd only develop this stuff in the 1.3 line. I can port back bug fixes, improvements, etc. to the 1.2 if necessary. The utility functions shouldn't really go into the 1.2 line as that line is now reserved solely for bug fixes (and a few minor improvements to documentation etc).

Cheers,

Edward



Related Messages


Powered by MHonArc, Updated Mon Nov 13 17:00:35 2006