Re: Binary floating point format

2017-03-30 Thread Carl Hoefs 

> On Mar 30, 2017, at 9:06 PM, Greg Parker  wrote:
> 
> 
>> On Mar 30, 2017, at 9:03 PM, Carl Hoefs > > wrote:
>> 
>>> On Mar 30, 2017, at 8:10 PM, Greg Parker >> > wrote:
>>> 
 On Mar 30, 2017, at 7:09 PM, Carl Hoefs >>> > wrote:
 
 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/ 
>>> , 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
>>> 
>> 
>> Enticing results!  When I use CFSwapInt64(), it does this to the bytes:
>> 
>> - raw bytes: 69BF5DE3 9F530306
>> - swp bytes: 0603539F E35DBF69
>> * [04] time_base: 
>> 2400969845129752384725738662412037010364031309686872696685853017835577483033453697155629104443247189829603912142488904070729903714756009814926441089319983058422454699494905107871645497808138444180815872.00
>>  
>> 
>> The 'time_base' value is what I get when I printf the swapped-bytes value 
>> with a %f formatter.
>> Not sure why you're getting good results...
> 
> CFSwapInt64() is not sufficient. I used CFSwapInt64() followed by 
> from_vax_d8() from the USGS URL above. The latter is what performs the real 
> floating-point format transformation from VAX to IEEE.

Thanks, I overlooked that. CFSwapInt64() + from_vax_d8() don't seem to be able 
to handle the attached byte stream. It does a raise(SIGPFE) at line 540 in 
convert_vax_data.c:

27 C2 36 E3 05 64 85 02 07 C2 3C E3 1C 64 E9 02 07 C2 3C E3 1C 64 22 02 07 C2 
3C E3 32 64 B7 02 E7 C1 3C E3 49 64 85 02

-Carl

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Binary floating point format

2017-03-30 Thread Greg Parker 

> On Mar 30, 2017, at 9:03 PM, Carl Hoefs  
> wrote:
> 
>> On Mar 30, 2017, at 8:10 PM, Greg Parker > > wrote:
>> 
>>> On Mar 30, 2017, at 7:09 PM, Carl Hoefs >> > wrote:
>>> 
>>> 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/ , 
>> 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
>> 
> 
> Enticing results!  When I use CFSwapInt64(), it does this to the bytes:
> 
> - raw bytes: 69BF5DE3 9F530306
> - swp bytes: 0603539F E35DBF69
> * [04] time_base: 
> 2400969845129752384725738662412037010364031309686872696685853017835577483033453697155629104443247189829603912142488904070729903714756009814926441089319983058422454699494905107871645497808138444180815872.00
>  
> 
> The 'time_base' value is what I get when I printf the swapped-bytes value 
> with a %f formatter.
> Not sure why you're getting good results...

CFSwapInt64() is not sufficient. I used CFSwapInt64() followed by from_vax_d8() 
from the USGS URL above. The latter is what performs the real floating-point 
format transformation from VAX to IEEE.


-- 
Greg Parker gpar...@apple.com  Runtime 
Wrangler


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Binary floating point format

2017-03-30 Thread Carl Hoefs 

> On Mar 30, 2017, at 8:10 PM, Greg Parker  wrote:
> 
>> 
>> On Mar 30, 2017, at 7:09 PM, Carl Hoefs > > wrote:
>> 
>> 
>>> On Mar 30, 2017, at 6:40 PM, Steve Bird >> > wrote:
>>> 
>>> 
 On Mar 30, 2017, at 8:25 PM, Carl Hoefs >>> > 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.0
>> 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.0182089.66467285156250
>> 0.0202087.57525634765625
>> 0.0222085.45166015625000
>> 0.0242083.29907226562500
>> 0.0262082.13275146484375
>> 0.0282081.03173828125000
>> 0.0302080.18218994140625
>> 0.0322080.29602050781250
>> 0.0342079.38055419921875
>> 0.0362079.43060302734375
>> 0.0382078.44738769531250
>> 0.0402076.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/ , 
> 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
> 

Enticing results!  When I use CFSwapInt64(), it does this to the bytes:

- raw bytes: 69BF5DE3 9F530306
- swp bytes: 0603539F E35DBF69
* [04] time_base: 
2400969845129752384725738662412037010364031309686872696685853017835577483033453697155629104443247189829603912142488904070729903714756009814926441089319983058422454699494905107871645497808138444180815872.00
 

The 'time_base' value is what I get when I printf the swapped-bytes value with 
a %f formatter.
Not sure why you're getting good results...
-Carl

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Binary floating point format

2017-03-30 Thread Greg Parker 

> On Mar 30, 2017, at 7:09 PM, Carl Hoefs  
> wrote:
> 
> 
>> On Mar 30, 2017, at 6:40 PM, Steve Bird  wrote:
>> 
>> 
>>> On Mar 30, 2017, at 8:25 PM, Carl Hoefs  
>>> 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.0
> 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.0182089.66467285156250
> 0.0202087.57525634765625
> 0.0222085.45166015625000
> 0.0242083.29907226562500
> 0.0262082.13275146484375
> 0.0282081.03173828125000
> 0.0302080.18218994140625
> 0.0322080.29602050781250
> 0.0342079.38055419921875
> 0.0362079.43060302734375
> 0.0382078.44738769531250
> 0.0402076.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/ , 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 gpar...@apple.com  Runtime 
Wrangler


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Binary floating point format

2017-03-30 Thread Carl Hoefs 

> On Mar 30, 2017, at 7:04 PM, Greg Parker  wrote:
> 
> Simply shuffling VAX bytes and interpreting as an IEEE double would be 
> misleadingly close but still wrong.

You are right. Without anything to go on, it's a hopeless task. I really need 
to bump this back and try to get a hold of somebody that knows something about 
this (the only person who did has left, not on good terms). I was hoping that I 
could at least get 'reasonable' looking data to buy time so I could proceed 
with the rest of the processing. But not knowing what values the data will 
actually take is kind of a road block for now...
-Carl

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Binary floating point format

2017-03-30 Thread Carl Hoefs 

> On Mar 30, 2017, at 6:40 PM, Steve Bird  wrote:
> 
> 
>> On Mar 30, 2017, at 8:25 PM, Carl Hoefs  
>> 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.0
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.0182089.66467285156250
0.0202087.57525634765625
0.0222085.45166015625000
0.0242083.29907226562500
0.0262082.13275146484375
0.0282081.03173828125000
0.0302080.18218994140625
0.0322080.29602050781250
0.0342079.38055419921875
0.0362079.43060302734375
0.0382078.44738769531250
0.0402076.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

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Binary floating point format

2017-03-30 Thread Greg Parker 

> On Mar 30, 2017, at 6:40 PM, Steve Bird  wrote:
> 
>> On Mar 30, 2017, at 8:25 PM, Carl Hoefs  
>> 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?

Alternating byte-swapping is a good hint that you're looking at a PDP-11 / VAX 
format. There are two different 64-bit VAX formats, though, and neither is 
identical to IEEE even after correcting for the byte order. Simply shuffling 
VAX bytes and interpreting as an IEEE double would be misleadingly close but 
still wrong.


-- 
Greg Parker gpar...@apple.com  Runtime 
Wrangler


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Binary floating point format

2017-03-30 Thread Pascal Bourguignon 

> On 31 Mar 2017, at 02:25, Carl Hoefs  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. 
> 
> If I read the data directly into double variables, they evaluate as very 
> small (E-92, etc).
> 
> I've tried all of these functions:
> 
>  NSSwapDouble()
>  NSSwapBigDoubleToHost()
>  NSSwapLittleDoubleToHost()
>  NSConvertSwappedDoubleToHost()
>  CFConvertDoubleSwappedToHost()
> 
> The above functions generally return invalidly large values (E+87, etc).
> 
> Here is a hex dump of 4 binary doubles:
> 
> 49BF7DE372533C05 A8C02FE3135B4F09 86C22FE37E630B05 27C2C4E3E258BA08
> 
> It seems there's some structure to them, as the last byte is always in the 
> range of 03 to A0, so maybe they somehow correspond to IEEE 754 
> double-precision binary floating point format? 
> 
> Is there yet another function I could use to parse this binary data?

Do these values look more sensible?

Perhaps it’s IBM floating points?

cl-user> (let ((ds  '(#x1122334455667788 #x49BF7DE372533C05 
  #xA8C02FE3135B4F09 #x86C22FE37E630B05 
#x27C2C4E3E258BA08)))
   (dolist (swap '(identity swap64/8 swap64/32 swap-32-32))
 (dolist (n ds (terpri))
  (format t "~8,'0X ~~> ~8,'0X -> ~A~%" n (funcall swap n)
 (ibm-to-double-float (funcall swap n))

1122334455667788 ~> 1122334455667788 -> 2.3754432874621412D-67
49BF7DE372533C05 ~> 49BF7DE372533C05 -> 5.202153205871582D0
A8C02FE3135B4F09 ~> A8C02FE3135B4F09 -> -1.0481728277757355D-39
86C22FE37E630B05 ~> 86C22FE37E630B05 -> -1.3051642321919604D-80
27C2C4E3E258BA08 ~> 27C2C4E3E258BA08 -> 6.365827421850181D-41

1122334455667788 ~> 8877665544332211 -> -1.7249758893089965D-78
49BF7DE372533C05 ~> 53C5372E37DBF49 -> 1.0356655888799012D-81
A8C02FE3135B4F09 ~> 94F5B13E32FC0A8 -> 2.5774949195090032D-77
86C22FE37E630B05 ~> 50B637EE32FC286 -> 3.933545844594491D-82
27C2C4E3E258BA08 ~> 8BA58E2E3C4C227 -> 6.637651455481117D-78

1122334455667788 ~> 5566778811223344 -> 6.01657272434688D+14
49BF7DE372533C05 ~> 72533C0549BF7DE3 -> 2.798654988457155D+50
A8C02FE3135B4F09 ~> 135B4F09A8C02FE3 -> 1.1405782651894492D-64
86C22FE37E630B05 ~> 7E630B0586C22FE3 -> 7.98839220202526D+64
27C2C4E3E258BA08 ~> E258BA0827C2C4E3 -> -1.5431197015853318D+31

1122334455667788 ~> 4433221188776655 -> 7.11677876097383D-6
49BF7DE372533C05 ~> E37DBF49053C5372 -> -7.647223718743149D+31
A8C02FE3135B4F09 ~> E32FC0A8094F5B13 -> -1.0059537510577916D+32
86C22FE37E630B05 ~> E32FC286050B637E -> -1.4436818052519877D+31
27C2C4E3E258BA08 ~> E3C4C22708BA58E2 -> -2.3622313801204285D+32


Or perhaps it’s Microsoft floating points?

cl-user> (let ((ds  '(#x1122334455667788 #x49BF7DE372533C05 
  #xA8C02FE3135B4F09 #x86C22FE37E630B05 
#x27C2C4E3E258BA08)))
   (dolist (swap '(identity swap64/8 swap64/32 swap-32-32))
 (dolist (n ds (terpri))
  (format t "~8,'0X ~~> ~8,'0X -> ~A~%" n (funcall swap n) 
(ibm-to-double-float (funcall swap n))

1122334455667788 ~> 1122334455667788 -> 1.2202591425418212D-34
49BF7DE372533C05 ~> 49BF7DE372533C05 -> -1.0380788666241747D-17
A8C02FE3135B4F09 ~> A8C02FE3135B4F09 -> -4.1271856580565436D+11
86C22FE37E630B05 ~> 86C22FE37E630B05 -> -24.273383128545337D0
27C2C4E3E258BA08 ~> 27C2C4E3E258BA08 -> -6.145829211972407D-28

1122334455667788 ~> 8877665544332211 -> 123.69986928104575D0
49BF7DE372533C05 ~> 53C5372E37DBF49 -> 3.4590018121487237D-38
A8C02FE3135B4F09 ~> 94F5B13E32FC0A8 -> 6.093638471033148D-37
86C22FE37E630B05 ~> 50B637EE32FC286 -> 2.5601652562851923D-38
27C2C4E3E258BA08 ~> 8BA58E2E3C4C227 -> -2.7381261883853355D-37

1122334455667788 ~> 5566778811223344 -> 5.117393619226236D-14
49BF7DE372533C05 ~> 72533C0549BF7DE3 -> 2.5181109391411485D-5
A8C02FE3135B4F09 ~> 135B4F09A8C02FE3 -> 6.5995823691006745D-34
86C22FE37E630B05 ~> 7E630B0586C22FE3 -> 0.11086086575985371D0
27C2C4E3E258BA08 ~> E258BA0827C2C4E3 -> 1.3414732167249665D+29

1122334455667788 ~> 4433221188776655 -> 3.034632414629399D-19
49BF7DE372533C05 ~> E37DBF49053C5372 -> 3.1412382858272243D+29
A8C02FE3135B4F09 ~> E32FC0A8094F5B13 -> 2.175711360216376D+29
86C22FE37E630B05 ~> E32FC286050B637E -> 2.1758016487161476D+29
27C2C4E3E258BA08 ~> E3C4C22708BA58E2 -> -2.4357511146913354D+29


You have to choose the byte swapping. 

https://en.wikipedia.org/wiki/IBM_Floating_Point_Architecture#Double-precision_64-bit
 

If that’s the case, then the first (big-endian) byte order is probably the 
right one, 
but the example data you gave may be wrong.  Instead of dumping the file 8 
octets by 8 octets, you should dump it octet by octet to preserve the byte

Re: Binary floating point format

2017-03-30 Thread Steve Bird 

> On Mar 30, 2017, at 8:25 PM, Carl Hoefs  
> 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?


Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
www.Culverson.com (toll free) 1-877-676-8175





___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Binary floating point format

2017-03-30 Thread Greg Parker 

> On Mar 30, 2017, at 5:25 PM, Carl Hoefs  
> 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. 
> 
> If I read the data directly into double variables, they evaluate as very 
> small (E-92, etc).
> 
> I've tried all of these functions:
> 
>  NSSwapDouble()
>  NSSwapBigDoubleToHost()
>  NSSwapLittleDoubleToHost()
>  NSConvertSwappedDoubleToHost()
>  CFConvertDoubleSwappedToHost()
> 
> The above functions generally return invalidly large values (E+87, etc).
> 
> Here is a hex dump of 4 binary doubles:
> 
> 49BF7DE372533C05 A8C02FE3135B4F09 86C22FE37E630B05 27C2C4E3E258BA08
> 
> It seems there's some structure to them, as the last byte is always in the 
> range of 03 to A0, so maybe they somehow correspond to IEEE 754 
> double-precision binary floating point format? 
> 
> Is there yet another function I could use to parse this binary data?

There are lots of pre-IEEE floating-point formats. Here is a list of a few 
dozen of them:
Floating-Point Formats
http://www.quadibloc.com/comp/cp0201.htm 


I doubt you will be able to guess your floating-point format unless you have a 
collection of known values in both IEEE format and your format. Many of the 
historical formats are similar enough that misinterpretation could give 
incorrect values that look reasonable by eye.


-- 
Greg Parker gpar...@apple.com  Runtime 
Wrangler


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Binary floating point format

2017-03-30 Thread Carl Hoefs 
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. 

If I read the data directly into double variables, they evaluate as very small 
(E-92, etc).

I've tried all of these functions:

  NSSwapDouble()
  NSSwapBigDoubleToHost()
  NSSwapLittleDoubleToHost()
  NSConvertSwappedDoubleToHost()
  CFConvertDoubleSwappedToHost()

The above functions generally return invalidly large values (E+87, etc).

Here is a hex dump of 4 binary doubles:

49BF7DE372533C05 A8C02FE3135B4F09 86C22FE37E630B05 27C2C4E3E258BA08

It seems there's some structure to them, as the last byte is always in the 
range of 03 to A0, so maybe they somehow correspond to IEEE 754 
double-precision binary floating point format? 

Is there yet another function I could use to parse this binary data?
-Carl


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Can't use +initialize, now what?

2017-03-30 Thread Saagar Jha 
+1 to this idea as well. This works for cases where stuff like awakeFromNib and 
didFinishLaunching aren’t available, like plugins.

Saagar Jha

> On Mar 30, 2017, at 03:39, Jonathan Hull  wrote:
> 
> 
>> On Mar 29, 2017, at 4:24 PM, Charles Srstka  wrote:
>> 
>>> On Mar 29, 2017, at 3:41 PM, Greg Parker  wrote:
>>> 
 On Mar 29, 2017, at 9:02 AM, Charles Srstka >>> > wrote:
 
> On Mar 29, 2017, at 10:51 AM, Jens Alfke  > wrote:
> 
>> On Mar 29, 2017, at 6:57 AM, Daryle Walker >  > >> wrote:
>> 
>> Now the new Xcode release notes say that “• Swift now warns when an 
>> NSObject subclass attempts to override the initialize class method, 
>> because Swift can't guarantee that the Objective-C method will be 
>> called. (28954946)”
> 
> Huh, I haven’t heard of that. And I’m confused by “the Objective-C 
> method” — what’s that? Not the +initialize method being compiled, because 
> that’s in Swift. The superclass method?
> 
> Guess I’ll follow that Radar link and read the bug report myself. Oh, 
> wait. :(
 
 You actually can this time, since Swift’s bug reporter is actually open to 
 the public. https://bugs.swift.org/browse/SR-3114 
 >
 
 Basically, with Whole Module Optimization turned on, +initialize wasn’t 
 getting called. Their solution was to just get rid of +initialize.
>>> 
>>> You don't even need WMO. Many arrangements of Swift code can bypass ObjC 
>>> +initialize.
>>> 
>>> Invocation of +initialize is a feature of objc_msgSend(). Swift code does 
>>> not always use objc_msgSend() when calling methods: some methods are 
>>> inlined, some are called via virtual table, some are called directly. None 
>>> of these paths will provoke +initialize. 
>>> 
>>> Changing Swift's generated code to guarantee +initialize would be 
>>> prohibitively expensive. Imagine an is-initialized check in front of every 
>>> inlined call. It would be more expensive than +initialize in ObjC because 
>>> +initialize checking is free once you pay the cost of objc_msgSend(). (The 
>>> ObjC runtime checks +initialize on uncached dispatch, and never caches 
>>> anything until +initialize completes. Most dispatches are cached so they 
>>> pay nothing for +initialize support.)
>>> 
>>> +initialize in Swift isn't safe and is too expensive to make safe, so we're 
>>> taking it away instead.
>> 
>> I wonder if an equivalent Swift-native feature could be added, something 
>> like a typeInit block? If the block weren’t there, nothing special would 
>> happen, and if the block were present, the compiler could basically generate 
>> the code in the example I gave, but add the static var access to the front 
>> of every initializer and static/class member. That shouldn’t impact 
>> performance too much, and wouldn’t impact at all in the case that there’s no 
>> type initializer.
> 
> I hope so as well.  My favorite candidate so far would be a reflection 
> capability to get a list of all classes/structs/enums adhering to a protocol. 
>  Then you could build your own initializable protocol fairly easily (and can 
> even build whatever facility you want to guarantee a particular ordering or 
> timing). The reason, I favor it over a specific method, is that it also 
> enables a bunch of other cool patterns like extensible factories, and easy 
> plug-ins.
> 
> 
> 
> 
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> 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:
> https://lists.apple.com/mailman/options/cocoa-dev/saagar%40saagarjha.com
> 
> This email sent to saa...@saagarjha.com

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Rect for centered text in UILabel?

2017-03-30 Thread Eric E. Dolecki 
I have a very wide UILabel that will take different text over time. Single
line. No attributed.

I would like to position an image to the left of the first character in the
label any time it's updated. So I need to get a CGRect or something of the
text within the UILabel itself. I know I did this years ago, but I can't
remember how I did it.

Looking to do this in Swift. Any ideas or things I'm blanking on?

Thanks,
Eric
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Unicode filenames with Apple File System and UIManagedDocument

2017-03-30 Thread davelist 



> On Mar 23, 2017, at 8:01 PM, davel...@mac.com wrote:
> 
> 
>> On Mar 23, 2017, at 12:24 PM, David Duncan  wrote:
>> 
>> I just want to remind everyone I’m *not* a file system’s engineer – I’m just 
>> trying to help Dave (and anyone else caught in this) make sure their app can 
>> find their files.
>> 
>>> On Mar 23, 2017, at 1:53 AM, Alastair Houghton 
>>>  wrote:
>>> 
>>> On 22 Mar 2017, at 18:00, David Duncan  wrote:
 
 So there was another explanation posted on the bug that I’m not certain 
 you got, but which I think may explain.
 
 Basically the concept is that since APFS doesn’t normalize file names, if 
 you store file names in some other storage (say in your preferences) then 
 what could happen is this:
 
 10.2: File is saved with a file name handed to the file system in NFC 
 form. File system converts the file name to NFD. You store it as NFC.
 10.3: File system is converted to APFS, and the file name is NFD. You try 
 to look up the file as NFC, and it fails.
>>> 
>>> This is going to cause problems, though, when things migrate from HFS+ to 
>>> APFS, because the HFS normalisation *isn’t* a standard one.  In particular, 
>>> it certainly *isn’t* NFD for the current version of Unicode.
>> 
>> Yes, that is the crux of Dave’s issue – HFS+ => APFS only translated the 
>> file names (from UTF-16 to UTF-8), it did not re-normalize them.
>> 
>>> The only obvious solution for that would be to have the HFS+ to APFS 
>>> migration tool *re-normalise* the filenames (maybe it does?), but that’s 
>>> bound to break things in the (presumably quite common) case where the 
>>> filename stored in e.g. a plist was originally obtained from the filesystem.
>> 
>> Arguably there is no way for the file system converter to know how it should 
>> renormalize file names. This is akin to case sensitive vs case insensitive 
>> file systems. If you ran a converter from a case insensitive file system to 
>> a case sensitive one, you could preserve the capitalization during the 
>> conversion, but file lookups that used the wrong case would fail after the 
>> conversion. But the converter can’t know you want to look up “foo” via “FOO” 
>> or “Foo” to do any kind of normalization. The difference here is that for 
>> the most part unicode normalization is invisible to the developer.
>> 
>>> 
>>> Kind regards,
>>> 
>>> Alastair.
>>> 
>>> --
>>> http://alastairs-place.net
>>> 
>> 
>> --
>> David Duncan
> 
> 
> I appreciate the help you (and everyone else) has given. I should be able to 
> add an option to rescan what files are there. And I'll make time this weekend 
> to submit a DTS incident and see what answer I can get and share it here. I 
> do suspect I won't be the only one bit by this.
> 
> Thanks,
> Dave Reed


I received a reply from DTS with lots of information and references. The 
suggestion for me was to store both the name the user enters and a filename 
that won't have the issue in my plist file with the list of "courses" (I assume 
they mean use a ASCII name such as GUID). The other suggestion was to iterate 
over the files and apply the same decomposition to the filename and the user 
entered string to find the match - that's what I did over the weekend and the 
update is now available in the App Store.

Dave Reed


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Can't use +initialize, now what?

2017-03-30 Thread Jonathan Hull 

> On Mar 29, 2017, at 4:24 PM, Charles Srstka  wrote:
> 
>> On Mar 29, 2017, at 3:41 PM, Greg Parker  wrote:
>> 
>>> On Mar 29, 2017, at 9:02 AM, Charles Srstka >> > wrote:
>>> 
 On Mar 29, 2017, at 10:51 AM, Jens Alfke >>> > wrote:
 
> On Mar 29, 2017, at 6:57 AM, Daryle Walker    >> wrote:
> 
> Now the new Xcode release notes say that “• Swift now warns when an 
> NSObject subclass attempts to override the initialize class method, 
> because Swift can't guarantee that the Objective-C method will be called. 
> (28954946)”
 
 Huh, I haven’t heard of that. And I’m confused by “the Objective-C method” 
 — what’s that? Not the +initialize method being compiled, because that’s 
 in Swift. The superclass method?
 
 Guess I’ll follow that Radar link and read the bug report myself. Oh, 
 wait. :(
>>> 
>>> You actually can this time, since Swift’s bug reporter is actually open to 
>>> the public. https://bugs.swift.org/browse/SR-3114 
>>> >>  >
>>> 
>>> Basically, with Whole Module Optimization turned on, +initialize wasn’t 
>>> getting called. Their solution was to just get rid of +initialize.
>> 
>> You don't even need WMO. Many arrangements of Swift code can bypass ObjC 
>> +initialize.
>> 
>> Invocation of +initialize is a feature of objc_msgSend(). Swift code does 
>> not always use objc_msgSend() when calling methods: some methods are 
>> inlined, some are called via virtual table, some are called directly. None 
>> of these paths will provoke +initialize. 
>> 
>> Changing Swift's generated code to guarantee +initialize would be 
>> prohibitively expensive. Imagine an is-initialized check in front of every 
>> inlined call. It would be more expensive than +initialize in ObjC because 
>> +initialize checking is free once you pay the cost of objc_msgSend(). (The 
>> ObjC runtime checks +initialize on uncached dispatch, and never caches 
>> anything until +initialize completes. Most dispatches are cached so they pay 
>> nothing for +initialize support.)
>> 
>> +initialize in Swift isn't safe and is too expensive to make safe, so we're 
>> taking it away instead.
> 
> I wonder if an equivalent Swift-native feature could be added, something like 
> a typeInit block? If the block weren’t there, nothing special would happen, 
> and if the block were present, the compiler could basically generate the code 
> in the example I gave, but add the static var access to the front of every 
> initializer and static/class member. That shouldn’t impact performance too 
> much, and wouldn’t impact at all in the case that there’s no type initializer.

I hope so as well.  My favorite candidate so far would be a reflection 
capability to get a list of all classes/structs/enums adhering to a protocol.  
Then you could build your own initializable protocol fairly easily (and can 
even build whatever facility you want to guarantee a particular ordering or 
timing). The reason, I favor it over a specific method, is that it also enables 
a bunch of other cool patterns like extensible factories, and easy plug-ins.





___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Can't use +initialize, now what?

2017-03-30 Thread Alastair Houghton 
On 29 Mar 2017, at 21:17, Jens Alfke  wrote:
> 
>> On Mar 29, 2017, at 10:52 AM, Quincey Morris 
>>  wrote:
>> 
>> If willFinishLaunching is not early enough, then you can put code in your 
>> “main” function, but I don’t know how feasible that is in Swift.
> 
> Another trick to run stuff earlier at launch is to add an -awakeFromNib 
> method to your app delegate, or any other object in your main nib. This can 
> be dangerous, though, because you can’t count on any other object in the nib 
> already being awoken, since the -awakeFromNib methods are called in random 
> order. (I once had a very hard to debug intermittent crash due to an ordering 
> dependency between two -awakeFromNib methods.)

It’s also important to note that your -awakeFromNib method may be invoked more 
than once, in particular if the object is the owner of a nib file, *and* it can 
sometimes be invoked at surprising moments (for instance, a recent auto layout 
problem in iDefrag turned out to be caused by the initial layout pass 
triggering -outlineView:viewForTableColumn:item:, which in turn caused a nib to 
load for the view, triggering an -awakeFromNib call *before the “normal” 
-awakeFromNib for the object in question* and worse, that -awakeFromNib was 
called *during layout*, and did things that triggered re-layout; the resulting 
layout glitch was quite hard to track down).  The upshot is that it isn’t 
necessarily even sufficient to ensure that your -awakeFromNib remembers whether 
you’ve initialised your object; you need to be very careful about what can 
trigger it and under what circumstance.

Kind regards,

Alastair.

--
http://alastairs-place.net


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com