> I have some code that reads and displays these as ehenoctes which makes life
> easier...
>
> 11111111 11110101 01010101 01010101 01010101 01010101 01010101 01010101
> I don't know if the spaces help much. As the mantehenissa is from 0-51,
> the exponent from 52-62, and the sign bit is at position 63, wouldn't
> the best place for spaces be to separate out the components of the
> IEEE-754 float, e.g.:
>
> 1 1111111111 10101010101010101010101010101010101010101010101010101
>
> ieee754 doesn't seem to be an octet based system.
>
>
this is true ieee754 breaks the mantissa and exponent at a nibble boundary
however it is good to have an easily read structure that is less
monolithic....
and the underlying structure of
numbers on computers is octet based, most computer programmers think
in octets/bytes at
the basic level and when you manipulate the contents of nans you will tend
to
split in to octets for bit manipulation. so octets seem a good idea...
one (ugly) suggestion would be
0bs1 e111111 1111 m1010 10101010 10101010 10101010 10101010 10101010 101010101
Yikes. Maybe if we have a function which returns a string bit pattern
representation of the given float, then the octes representation could
be an option to that function (as well as functions for converting the
representative string into the float). Otherwise for in docstrings,
the spaces can be added by hand.
and then strip all leading 0b's all spaces and all letters. the addition of 0b
would allow you to use hex as well if you wanted (i would add that most system
programmers much prefer hex to bit patterns. if you look at many programs they
don't have binary constants but hex constants, and languages such as
python and c
support hex constants but not binary ones [most programmers find them
too wordy]
Internally yes, but the user may like the bit pattern as well.
> and then add an assert effectivley of the form endian..tolower() in
> ('little','big')
>
>
I think you need to assert that big and little are passed in endian if this is
a public function. The
general way to think about these things is that you should test all data for
validity at public interfaces. Then if you have internal functions you don't
have to test for validity (as you will slow down to repeated
testing). Its a bit like testing messages at a firewall before they
enter the dmz. However,
it is still a wise decision to check argument validity in all functions in
debugging mode e.g. with assert as this will catch errors early
Do you think that for all the public functions, being able to specify
the endianness through an argument would be useful? Asserting that
the argument must be either 'big' or 'little' could be implemented for
these.
as to the to lower it just gives a bit more generality if you don'
have to worry
about case
also you asked about using > and <. I personally much prefer big and
little they are much more obvious and intuitive </> are open to
interpretation
The strings 'big' and 'little' are easier to compare with
'sys.byteorder' as that variable is either 'big' or 'little'.
Edward
Re: Re(2): r2801 - /branches/test_suite/float.py