Reading a non-standard floating point format

Bengt Richter bokr at oz.net
Sun Apr 27 14:39:06 EDT 2003


On 27 Apr 2003 00:23:05 -0700, sjmachin at lexicon.net (John Machin) wrote:

>bokr at oz.net (Bengt Richter) wrote in message news:<b8fd9r$6fo$0 at 216.39.172.122>...
>> On Sat, 26 Apr 2003 19:41:43 -0400, "Tim Peters" <tim_one at email.msn.com> wrote:
>> [...]
>> >There's no way to guess without examples, though.  If you can, show us the
>> >48-bit byte strings for these numbers:
>> >
>> >    0.0
>> >    1.0
>> >    1.25
>> >    2.9e-39
>> >    1.7e38
>> >
>> >That should be enough to fill in the missing pieces.
>> >
>> Maybe include
>>     -1.25
>> also?
>> And can minus zero be generated?
>> Are numbers sign/magnitude or?
>> 
>
>I would ask for 1.125 as well as 1.25 (to be sure of bit order within
>a byte[*]) and also 1.03125 (1+1/32, 8 bits onwards from 1.25) to be
>sure of byte order within the 48-bit stucture.
>
That might be easier to interpret than Tim's numbers, but his do include
a bunch of bits in the values (for double):

 >>> prb(2.9e-39)
 '.0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
 000000000000000000000000000000000011111100101000000010100100111100010000100111011001011'
 >>> prb(1.7e+38)
 '11111111110010011001111000111100011001101111110101101000000000000000000000000000000000000000000
 00000000000000000000000000000000'
 >>> prb(1.25)
 '1.01'

Or just the significant ones
 >>> prb(1.7e+38).rstrip('0')
 '11111111110010011001111000111100011001101111110101101'
 >>> prb(2.9e-39)[1:].lstrip('0')
 '11111100101000000010100100111100010000100111011001011'

>The OP might also consider posting on alt.sys.alpha-micro -- surely
>somebody there will be able to provide better docs than the quoted
>excerpt from the AlphaBasic manual. You could ask about access to the
>AMs that are still running -- it could be very handy to mount a
>"chosen-plaintext" attack on the problem i.e. write an AlphaBasic
>program which wrote various chosen f.p. numbers to a "random access"
>(i.e. binary file) then ogle it with the aid of a hex dumper.
>
>* ... bit order within a byte: don't laugh, we're in 1980s
>microcomputer territory here; no f. p. h/ware, all done in ASM by
>heavy bit-bashing. I recall different variants of "standard" 32-bit
>CRCs -- the variants arising from whether the bits were shifted in
>from the left/right/high-end/low-end/east/west/...
>
ISTR a software variant that would postpone normalization also, to benefit
from things happening to be lined up already in intermediate results
of a computation ... back when we were happy if we could make all the ops
but floating point divide and square root under a millisecond.

So how do you feel about nixie tubes and biquinary ;-)

Regards,
Bengt Richter




More information about the Python-list mailing list