On 11/13/06, Gary S. Thompson <garyt@xxxxxxxxxxxxxxx> wrote:
Edward d'Auvergne wrote:
> I've just noticed an important name clash with 'float.py'. The module
> name clashes with the inbuilt function 'float()'. Hence if you import
> float rather than it's functions, you will no longer have access to
> the 'float()' function. Gary, do you think the module should be
> renamed to something like 'ieee_754.py'? Or maybe 'fp_754.py'?
my original name was ieeefloat if that is any help!
IEEE-754 isn't the only IEEE floating point standard, there's also
other no so widely used ones like IEEE 854-1987. I'll let you take
the time to come up with a memorable, descriptive name. This name
will be quite important once the code is complete and if it is to
considered to become a standard Python module.
> I was also wondering if there was an advantage working with bytes and
> hexadecimal rather than plain bits (as a string or array of 1 and 0's)
> in 'float.py'? Is this necessary because of the 'struct' module
> functions 'pack()' and 'unpack()'? Does it help with the endianness
> issues?
>
It doesn't help with endianness issues I worked in hex and documented in
bits as well because many computer scientists think in hex and writer
constants in hex and hex is supported by python whereas binary strings
of the form 0001000 etc aren't
Endianness is on the bit level rather than byte level isn't it?
> Another question I have is in the docstring of the SIGNBIT byte, you
> say the sign bit in bytes is '0b00000001'. Did you mean '0b10000000'?
If I remember correcly I am using little endian representations for
bytes and that gives this format. I would quite like to convert to big
endian as this is easier to read (if not to debug on a little endian
machine) but was leaving it until afetr the unit test suite was complete ;-)
> Or are you representing position 63 of the double precision float bit
> pattern on the far right? Oh and one last thing, does 'packed[::-1]'
> properly reverse the byte order? For example:
>
> packed = pack('d', 1.0e-25) -> '\xd9}\xda\xf5\xd0\xf2\xbe:',
> packed[::-1] -> ':\xb3\xf2\xd0\xf5\xda}\xd9'.
>
yes it does! The :} and other gumph will just be the ascii
representation of the relevant hex (n.b. how did you print out these
strings.... the last bit on one of the seems strange, I will investigate)
After the import in the Python prompt, I typed something like:
pack('d', 1e-25)
'\xd9}\xda\xf5\xd0\xf2\xbe:'
pack('d', 1e-25)[::-1]
':\xb3\xf2\xd0\xf5\xda}\xd9'
Print statements do the same thing.
To print hex I use
packed = pack('d', 1.0e-25)
for elem in unpack('8B',packed):
print hex(elem)
That looks better! And the packed[::-1] when printed in proper hex is
reversed properly. It's that C struct format that got me. What is
that anyway? Forget about what I said then.
> I have no idea what the ':' or '}' mean here, but should the string be
> '\xbe:\xf2\xd0\xf5\xda\xd9}'? Would using the first characters '<'
> and '>' be a better way of supporting little and big endianness?
can you point me to a relevant line where you want to use < or make a
suggestion of what you want to do I wasn't clear on this
It looks like it's the first character of that C struct format.
According to the 'struct' module docstring, the '>' and '<' represent
big and little endian respectively. But as I'm unfamiliar with this C
struct string representation, I can't say where you would use it. As
you can get the endianness of the current system from 'sys.byteorder',
I can't see a need for it.
Cheers,
Edward
Re: The name clash of 'float.py' with the builtin function 'float()' and bits vs. bytes.