Extract double in binary file

[Bengt Richter]

On Sat, 29 Nov 2003 00:30:42 GMT, Dennis Lee Bieber <wlfraed at ix.netcom.com> wrote:

>Francis Avila fed this fish to the penguins on Friday 28 November 2003 
>01:45 am:
>
>> 
>> 
>> That is a bizarre format, and of course I had to implement it. (Even C
>> is more pleasant in Python!).
>>
>        And I thought /I/ was the masochist...
>
>        I do have to confess that short tests with struct did reveal that, on 
>my system, regular doubles do have the same byte order as the original 
>data. I'm just more comfortable with seeing hex representations of 
>numbers with the MSB on the left.
> 
>> It works for the cases given, but do find out where the sign bit is
>> for the mantissa. (This code assumes it's the MSB of the mantissa.)
>>
>        I suspect most would consider the format my college computer used to 
>be weird... Xerox Sigma 6... Excess 64 (decimal) (as I recall) exponent 
>powers of sixteen! A "normalized" mantissa could have up to three 
>leading 0 bits, and there were no "hidden" bit.
>
>        S eeeeeee mmmmmmmmm mmmmmmmm mmmmmmmm ...
>
Does the OP have the ability ot generate example values at will,
or is it a matter of scrounging through some old recorded data with
no way of making more?

If he can make more, I'd suggest a number with most of the nybbles
of data individually numbered, e.g.,
    0xfedcba987654321
E.g., if it's a 64-bit format, a 64-bit integer converted would probably
tell the a lot about where the bits go (how many get shifted out, hidden,
how they're ordered). And then the same number negative. E.g.,

 >>> 0xfedcba987654321
 1147797409030816545L
 >>> -0xfedcba987654321
 -1147797409030816545L
 >>> hex(0xfedcba987654321)
 '0xFEDCBA987654321L'
 >>> hex(-0xfedcba987654321)
 '-0xFEDCBA987654321L'
 <grr>useless hex representation for looking at bits ...</grr>

 >>> hex(-0xfedcba987654321 +2**80)
 '0xFFFFF0123456789ABCDFL'

Regards,
Bengt Richter