Re: Binary floating point format
Re: Binary floating point format
- Subject: Re: Binary floating point format
- From: Greg Parker <email@hidden>
- Date: Thu, 30 Mar 2017 20:10:50 -0700
> On Mar 30, 2017, at 7:09 PM, Carl Hoefs <email@hidden> wrote:
>
>
>> On Mar 30, 2017, at 6:40 PM, Steve Bird <email@hidden> wrote:
>>
>>
>>> On Mar 30, 2017, at 8:25 PM, Carl Hoefs <email@hidden> wrote:
>>>
>>> I have megabytes of raw legacy science datasets that I'm trying to read into my app and ingest into an array of doubles. The data is supposed to be organized as a stream of 8-byte doubles. I do not know how these datasets were generated, so I don't know what format (big/little endian, byte swapped, etc) they are in.
>>> Here is a hex dump of 4 binary doubles:
>>>
>>> 49BF7DE372533C05 A8C02FE3135B4F09 86C22FE37E630B05 27C2C4E3E258BA08
>>
>> A few minutes of LabVIEW work shows some semi-reasonable values if you swap bytes:
>> BF49E37D5372053C = -0.000790058
>> C0A8E32F5B13094F = -3185.59
>>
>> Do you know that those values are wrong?
>
> Hmm, the -3185.59 doesn't look right. The data is _supposed_ to be:
>
> 1st double: Time value, monotonically increasing, usually starting near 0.00000
> 2nd double: Sensor value, oscillating waveform, centered about some arbitrary value
>
> So I'm expecting data like:
>
> 0.011 0.57525634765625
> 0.012 0.45166015625000
> 0.013 0.29907226562500
> 0.014 0.13275146484375
> 0.015 -0.03173828125000
> 0.016 -0.18218994140625
> 0.017 -0.29602050781250
> 0.018 -0.38055419921875
> ...etc.
>
> or even:
>
> 0.018 2089.66467285156250
> 0.020 2087.57525634765625
> 0.022 2085.45166015625000
> 0.024 2083.29907226562500
> 0.026 2082.13275146484375
> 0.028 2081.03173828125000
> 0.030 2080.18218994140625
> 0.032 2080.29602050781250
> 0.034 2079.38055419921875
> 0.036 2079.43060302734375
> 0.038 2078.44738769531250
> 0.040 2076.43640136718750
> ...etc
>
> When I manually swap the bytes in my program, I still end up with invalid values.
> -Carl
>
> 26 C3 E9 E2 6C 6A 38 0C 46 C3 E9 E2 6C 6A 40 0B 46 C3 E9 E2 83 6A DC 0A 66 C3 E9 E2 83 6A 0E 0B
> A5 C3 EF E2 AF 6A 40 0B A5 C3 EF E2 C6 6A 40 0B C5 C3 F5 E2 C6 6A 16 0A C5 C3 F5 E2 DC 6A 0E 0B
> 26 C3 3C E3 9E 62 B2 09 26 C3 3C E3 9E 62 B2 09 26 C3 36 E3 B4 62 BA 08 06 C3 36 E3 CB 62 C2 07
> 45 C4 76 E3 44 6C 38 0C 25 C4 76 E3 5A 6C 06 0C 25 C4 76 E3 5A 6C DC 0A 05 C4 7D E3 70 6C DC 0A
Byte-swapped VAX type D might be right, but it's so easy to be off by a factor of 2 here that it's hard to trust any guess.
Using CFSwapInt64() from CoreFoundation/CFByteOrder.h and from_vax_d8() from https://pubs.usgs.gov/of/2005/1424/ <https://pubs.usgs.gov/of/2005/1424/>, your bytes above are:
-41.7215935353
-49.7215935353
-49.7215935353
-49.7215935366
-49.7215935366
-57.7215935366
-57.7215935366
-82.9432328547
-82.9432328547
-82.9432328574
-82.9432328574
-98.9432786338
-98.9432786338
-98.9432786363
-98.9432786363
-41.7219100388
--
Greg Parker email@hidden <mailto:email@hidden> Runtime Wrangler
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden