On 11/15/06, gary thompson <garyt@xxxxxxxxxxxxxxx> wrote:
> edward.dauvergne@xxxxxxxxx wrote:
>
> >Author: bugman
> >Date: Sat Nov 11 10:57:35 2006
> >New Revision: 2801
> >
> >URL: http://svn.gna.org/viewcvs/relax?rev=2801&view=rev
> >Log:
> >Two functions for converting a string bit pattern to a float and a number
of
> IEEE-754 constants.
> >
> >The fucntions 'bitpatternToFloat()' and 'bitpatternToInt()' have been added
> to 'float.py'. The
> >first converts a 64 bit IEEE-754 bit pattern in the form of a string into a
> 64 bit Python float.
> >The second converts an arbitrary bit pattern into its integer
> representation. By looping over each
> >8 characters of the string (1 byte), 'bitpatternToFloat()' calls
> 'bitpatternToInt()' to create an
> >array of integers. Then 'packBytesAsPyFloat()' is called to convert the
> byte array into the float.
> >These two functions convert between big and little endian when necessary.
> >
> >
> Nice functions! However, I would suggest that these should go in utility
> functions or the test suite.... I am trying to keep float.py as the
> bare minimum file for testing floating point numbers and floating point
> constants
>
>
> I agree - these string to float conversions are auxiliary to intended
> purpose of the IEEE-754 module. Unfortunately as you hadn't committed
> the utility function code yet - I wasn't able to put the functions
> there :).
>
> This is true but certainly at this stage the product is just too half cut
for
anyone else and I wanted to concentrate on the primary problem (i.e.
float.py)
and complete that first unit, test it etc before I did some work on
the capabilities
Maybe it's time to soon merge the 'test_suite' branch (once the first
unit tests are running). The integration of the unit tests and
systems tests into a modified test suite framework could be done
within the main 1.3 line. Then you could create a new private branch
from the 1.3 line for all the rough floating point code you are
working on. You could then work on this branch while others work on
the data model redesign. As the floating point code won't be affected
by the data model redesign, merging changes would be trivial. If you
want to see some really half cut code, look at the history of the
'tensor_pdb' branch. In a large number of revisions, relax wouldn't
even run!
> How would you like to design the ieee754 module? Have you searched
> for documentation describing how to create standard Python modules,
> i.e. the format and structure of the modules? Should the utility
> functions be part of the module? Or should the be their own module?
Something I have to thing about and read python in a nutshell. basically if
the
utility functions are private they shouldn't be part of the public interface.
Otherwise it is just a question of keeping the utility of the module
focused...
Would a user ever find these functions useful though?
> The 'bitpatternToFloat()' function I added is 100% specific to
> IEEE-754 though. Do you think it would be a good idea, for future
> Python inclusion and to improve on 'fpconst', to create a module which
> includes as many IEEE-754 related functions as possible?
>
>
I would try to keep the number of functions to the minimum and maintain
fpconst
compatabilty. all other functions can go in separate modules if needed.
Although using hex internally is good, would it not be useful for a
user unfamiliar with hex to have access to a set of functions which
convert bit pattern strings into the corresponding floating point
number and vice versa? In addition inputting hex and hex strings (eg
'FFFFFFFF') to get the floating point number and vice versa?
Again I think that functions a user would find useful should be
accessible to the user. All the other functions can be hidden. Have
you had a look at Distutils? I would assume that turning the ieee754
code into site-packages using Distutils would be an important step in
the process of getting this into Python.
> A couple of other matters as well
>
> 1. the constants are not much use at the end of the file as if anything
> else in the file wants to refer to them they won't be able to
At the moment, the 'float.py' file is very difficult to navigate due
to the seemingly random ordering of the functions and constants.
Would it be OK to bring some order into this code? Could the
functions be sorted alphabetically?
And where would constants go? I think the end is perfectly ok as
these are intended for the user (and possibly unit tests) and none of
the functions in 'float.py' use them (including the 'nan', 'pos_inf',
'neg_inf', 'NAN_BYTES', and 'INF_BYTES' you have defined in the
middle). The other point is that to generate the constants, calls to
functions in 'float.py' are required and hence these functions must be
located above the constants.
I think we should implement all the constants in the '64-bit Double
Precision' table located at
http://babbage.cs.qc.edu/courses/cs341/IEEE-754references.html. This
would be about 5 min worth of work. They could use
'bitpatternToFloat()', although ideally they should use
'packBytesAsPyFloat()'. They should each have a docstring describing
what the constant is. In that docstring there should be the
bitpattern (probably in big endian), and the hexadecimal
representation. For the IEEE-754 numbers with ranges we could have
Max and Min versions to delimit the range. Hence we could have the
following constants (in big endian hex):
NegQuiteNaNMin = 'FFFFFFFFFFFFFFFF'
NegQuiteNaNMax = 'FFF8000000000001'
NegQuiteNaN = NegQuiteNaNMin
Indeterminate = 'FFF8000000000000'
NegSigNaNMin = 'FFF7FFFFFFFFFFFF'
NegSigNaNMax = 'FFF0000000000001'
NegSigNaN = NegSigNaNMin
NegInf = 'FFF0000000000000'
NegNormMin = 'FFEFFFFFFFFFFFFF'
NegNormMax = '8010000000000000'
NegEpsilonNorm = NegNormMax
NegMin = NegNormMin
NegDenormMin = '800FFFFFFFFFFFFF'
NegDenormMax = '8000000000000001'
NegEpsilonDenorm = NegDenormMax
NegZero = '8000000000000000'
NegUnderflow = NegZero
PosZero = '0000000000000000'
PosUnderflow = PosZero
PosDenormMin = '0000000000000001'
PosDenormMax = '000FFFFFFFFFFFFF'
PosEpsilonDenorm = PosDenormMin
PosNormMin = '0010000000000000'
PosNormMax = '7FEFFFFFFFFFFFFF'
PosEpsilonNorm = PosNormMin
PosMax = PosNormMax
PosInf = '7FF0000000000000'
PosSigNaNMin = '7FF0000000000001'
PosSigNaNMax = '7FF7FFFFFFFFFFFF'
PosSigNaN = PosSigNaNMin
PosQuiteNaNMin = '7FF8000000000000'
PosQuiteNaNMax = '7FFFFFFFFFFFFFFF'
PosQuiteNaN = PosQuiteNaNMin
> I didn't expect anything in 'float.py' to use them. I just expanded
> the constants proposed in PEP-754
> (http://www.python.org/dev/peps/pep-0754/) into a complete list of all
> the IEEE-754 special numbers. That was pretty simple to do. They can
> be imported into the unit tests as an accurate replacement for
> FLOAT_EPSILON, etc. Their main usage would be by the users of the
> module.
>
fair enough still the top is the place to put them (this is also where users
would expect to search for constants...)
This isn't possible as they call functions in 'float.py'. Hence I
think the bottom would be better as they wouldn't then break up the
order of the functions. All the stuff like 'MANTISSA_NIBBLE_MASK'
etc. which will need to be later hidden from the user could be located
at the start (or possibly in another user non-accessible module).
The three NaN just give the users of the module a
> few different NaN numbers to play with. I can't stand the way I've
> named them though!
>
I would suggest that we don't want to have multiple nans. decide on one good
bit
pattern that is easy to identify and then use it everywhere.
This will make debugging a lost easier. One suggestion is to have a
memorable hex
pattern e.g. 'deadara' or something similar
The constants above borrowed from
http://babbage.cs.qc.edu/courses/cs341/IEEE-754references.html have
multiple NaNs (quite, signalling, neg, pos, min, max, etc.). The ones
I've added can be deleted or moved to the unit tests.
as an aside from my (limited) reading of the ieee spec it seems that
the extra patterns
are just there to give the designers of fpus some flexibility
now when we come round to unit testing thats a different matter here we want
lots of nans and if the names are ugly who cares as long as they don't change!
I'll respond to the rest in a second post.
Cheers,
Edward
Re: Re(2): r2801 - /branches/test_suite/float.py