I am reading in more binary data. This time I get 4 bytes with the following ASCII character values:
63
2
250
240
I believe this is a set of 4 bytes that correspond to a unsigned long. The input number is 50. Can anyone make sense of this, or am I way off here. Thanks,
Zach
hi zach-
so you wan't a word that look like this:
harp:~ > irb
irb(main):001:0> printf "%32.32b\n", 50
00000000000000000000000000110010
=> nil
but you have these four bytes:
irb(main):002:0> printf "%8.8b\n", 63
00111111
=> nil
irb(main):003:0> printf "%8.8b\n", 2
00000010
=> nil
irb(main):004:0> printf "%8.8b\n", 250
11111010
=> nil
irb(main):005:0> printf "%8.8b\n", 240
11110000
=> nil
so, not matter what order you put them in, you aren't going to get the bits for
50 out of 'em i'm afraid ;-( in fact, since you know 50 fits into one byte
four bytes of a 'long' 50 will have to have three zero filled bytes for most
archs.
how is the data being written/read?
cheers.
-a
On Tue, 26 Apr 2005, Zach Dennis wrote:
I am reading in more binary data. This time I get 4 bytes with the
following ASCII character values:63
2
250
240I believe this is a set of 4 bytes that correspond to a unsigned long.
The input number is 50. Can anyone make sense of this, or am I way off
here. Thanks,
email :: ara [dot] t [dot] howard [at] noaa [dot] gov
phone :: 303.497.6469
although gold dust is precious, when it gets in your eyes, it obstructs
your vision. --hsi-tang
===============================================================================
so, not matter what order you put them in, you aren't going to get the bits for 50 out of 'em i'm afraid ;-( in fact, since you know 50 fits into one byte
four bytes of a 'long' 50 will have to have three zero filled bytes for most
archs.
I was afraid of that...I was hoping there was something I was missing...
how is the data being written/read?
The data is being written from another application to a binary file. I have isolated and confirmed that 4 bytes correspond to a certain number input (a maximum folder size is what the number means). I am reading the file and parsing it's information. I have every field working except for this max folder size.
It appears that my numbers for 50 were wrong in my original post, although with the logic you applied Ara my wishful thinking was still way off base.
Here is a sample of the first 50 rows of data. Each row signifies the # of Megabytes defined for max storage. Each column signifies a byte in the position they are in the file. The first column and the first row are labels in this email.
This is another numbers/patterns/algorithms things similar to what I posted a few weeks ago, but this time it appears slighly more difficult.
If anyone has the time, the patience and the know-how to make sense of this, any help would greatly be appreciated. If not then I will keep thinking about ways to attack this problem. Thanks in advance,
Zach
1 2 3 4
0 0 0 0 0
1 0 15 66 64
2 0 30 132 128
3 0 45 198 192
4 0 61 9 0
5 0 76 75 64
6 0 91 141 128
7 0 106 207 192
8 0 122 18 0
9 0 137 84 64
10 0 152 150 128
11 0 167 216 192
12 0 183 27 0
13 0 198 93 64
14 0 213 159 128
15 0 228 225 192
16 0 244 36 0
17 1 3 102 64
18 1 18 168 128
19 1 33 234 192
20 1 49 45 0
21 1 64 111 64
22 1 79 177 128
23 1 94 243 192
24 1 109 54 0
25 1 125 120 64
26 1 140 186 128
27 1 155 252 192
28 1 171 63 0
29 1 186 129 64
30 1 202 195 128
31 1 217 5 192
32 1 232 72 0
33 1 247 138 64
34 2 6 204 128
35 2 22 14 192
36 2 37 81 0
37 2 52 147 64
38 2 67 213 128
39 2 83 23 192
40 2 98 90 0
41 2 113 156 64
42 2 128 222 128
43 2 144 32 192
44 2 159 99 0
45 2 174 165 64
46 2 189 231 128
47 2 205 41 192
48 2 220 108 0
49 2 235 174 64
50 2 250 240 128
Ara.T.Howard@noaa.gov wrote:
network ordered longs?
harp:~ > cat a.rb
rows = [
%w[ 0 0 0 0 ] ,
%w[ 0 15 66 64 ] ,
%w[ 0 30 132 128 ] ,
%w[ 0 45 198 192 ] ,
%w[ 0 61 9 0 ] ,
%w[ 0 76 75 64 ] ,
%w[ 0 91 141 128 ] ,
%w[ 0 106 207 192 ] ,
%w[ 0 122 18 0 ] ,
%w[ 0 137 84 64 ] ,
%w[ 0 152 150 128 ] ,
%w[ 0 167 216 192 ] ,
%w[ 0 183 27 0 ] ,
%w[ 0 198 93 64 ] ,
%w[ 0 213 159 128 ] ,
%w[ 0 228 225 192 ] ,
%w[ 0 244 36 0 ] ,
%w[ 1 3 102 64 ] ,
%w[ 1 18 168 128 ] ,
%w[ 1 33 234 192 ] ,
%w[ 1 49 45 0 ] ,
%w[ 1 64 111 64 ] ,
%w[ 1 79 177 128 ] ,
%w[ 1 94 243 192 ] ,
%w[ 1 109 54 0 ] ,
%w[ 1 125 120 64 ] ,
%w[ 1 140 186 128 ] ,
%w[ 1 155 252 192 ] ,
%w[ 1 171 63 0 ] ,
%w[ 1 186 129 64 ] ,
%w[ 1 202 195 128 ] ,
%w[ 1 217 5 192 ] ,
%w[ 1 232 72 0 ] ,
%w[ 1 247 138 64 ] ,
%w[ 2 6 204 128 ] ,
%w[ 2 22 14 192 ] ,
%w[ 2 37 81 0 ] ,
%w[ 2 52 147 64 ] ,
%w[ 2 67 213 128 ] ,
%w[ 2 83 23 192 ] ,
%w[ 2 98 90 0 ] ,
%w[ 2 113 156 64 ] ,
%w[ 2 128 222 128 ] ,
%w[ 2 144 32 192 ] ,
%w[ 2 159 99 0 ] ,
%w[ 2 174 165 64 ] ,
%w[ 2 189 231 128 ] ,
%w[ 2 205 41 192 ] ,
%w[ 2 220 108 0 ] ,
%w[ 2 235 174 64 ] ,
%w[ 2 250 240 128 ] ,
]
rows.each do |row|
bytes = row.map{|value| value.to_i}
word = bytes.inject(''){|s,byte| s << byte.chr}
p word.unpack('N')
end
harp:~ > ruby a.rb
[0]
[1000000]
[2000000]
[3000000]
[4000000]
[5000000]
[6000000]
[7000000]
[8000000]
[9000000]
[10000000]
[11000000]
[12000000]
[13000000]
[14000000]
[15000000]
[16000000]
[17000000]
[18000000]
[19000000]
[20000000]
[21000000]
[22000000]
[23000000]
[23934464]
[25000000]
[26000000]
[27000000]
[28000000]
[29000000]
[30065536]
[31000000]
[32000000]
[33000000]
[34000000]
[35000000]
[36000000]
[37000000]
[38000000]
[39000000]
[40000000]
[41000000]
[42000000]
[43000000]
[44000000]
[45000000]
[46000000]
[47000000]
[48000000]
[49000000]
[50000000]
look reasonable no?
cheers.
-a
On Tue, 26 Apr 2005, Zach Dennis wrote:
The data is being written from another application to a binary file. I have
isolated and confirmed that 4 bytes correspond to a certain number input (a
maximum folder size is what the number means). I am reading the file and
parsing it's information. I have every field working except for this max
folder size.It appears that my numbers for 50 were wrong in my original post, although
with the logic you applied Ara my wishful thinking was still way off base.Here is a sample of the first 50 rows of data. Each row signifies the # of
Megabytes defined for max storage. Each column signifies a byte in the
position they are in the file. The first column and the first row are labels
in this email.This is another numbers/patterns/algorithms things similar to what I posted
a few weeks ago, but this time it appears slighly more difficult.If anyone has the time, the patience and the know-how to make sense of this,
any help would greatly be appreciated. If not then I will keep thinking
about ways to attack this problem. Thanks in advance,
email :: ara [dot] t [dot] howard [at] noaa [dot] gov
phone :: 303.497.6469
although gold dust is precious, when it gets in your eyes, it obstructs
your vision. --hsi-tang
===============================================================================
Or - with the same rows array...
rows.each{|r|
puts r.inject(0){|sum, v| sum = (sum*0x100) + v.to_i}
}
Vance
On Tue, 2005-04-26 at 10:04 +0900, Ara.T.Howard@noaa.gov wrote:
On Tue, 26 Apr 2005, Zach Dennis wrote:
> The data is being written from another application to a binary file. I have
> isolated and confirmed that 4 bytes correspond to a certain number input (a
> maximum folder size is what the number means). I am reading the file and
> parsing it's information. I have every field working except for this max
> folder size.
>
> It appears that my numbers for 50 were wrong in my original post, although
> with the logic you applied Ara my wishful thinking was still way off base.
>
> Here is a sample of the first 50 rows of data. Each row signifies the # of
> Megabytes defined for max storage. Each column signifies a byte in the
> position they are in the file. The first column and the first row are labels
> in this email.
>
> This is another numbers/patterns/algorithms things similar to what I posted
> a few weeks ago, but this time it appears slighly more difficult.
>
> If anyone has the time, the patience and the know-how to make sense of this,
> any help would greatly be appreciated. If not then I will keep thinking
> about ways to attack this problem. Thanks in advance,network ordered longs?
harp:~ > cat a.rb
rows = [
%w[ 0 0 0 0 ] ,
%w[ 0 15 66 64 ] ,
%w[ 0 30 132 128 ] ,
%w[ 0 45 198 192 ] ,
%w[ 0 61 9 0 ] ,
%w[ 0 76 75 64 ] ,
%w[ 0 91 141 128 ] ,
%w[ 0 106 207 192 ] ,
%w[ 0 122 18 0 ] ,
%w[ 0 137 84 64 ] ,
%w[ 0 152 150 128 ] ,
%w[ 0 167 216 192 ] ,
%w[ 0 183 27 0 ] ,
%w[ 0 198 93 64 ] ,
%w[ 0 213 159 128 ] ,
%w[ 0 228 225 192 ] ,
%w[ 0 244 36 0 ] ,
%w[ 1 3 102 64 ] ,
%w[ 1 18 168 128 ] ,
%w[ 1 33 234 192 ] ,
%w[ 1 49 45 0 ] ,
%w[ 1 64 111 64 ] ,
%w[ 1 79 177 128 ] ,
%w[ 1 94 243 192 ] ,
%w[ 1 109 54 0 ] ,
%w[ 1 125 120 64 ] ,
%w[ 1 140 186 128 ] ,
%w[ 1 155 252 192 ] ,
%w[ 1 171 63 0 ] ,
%w[ 1 186 129 64 ] ,
%w[ 1 202 195 128 ] ,
%w[ 1 217 5 192 ] ,
%w[ 1 232 72 0 ] ,
%w[ 1 247 138 64 ] ,
%w[ 2 6 204 128 ] ,
%w[ 2 22 14 192 ] ,
%w[ 2 37 81 0 ] ,
%w[ 2 52 147 64 ] ,
%w[ 2 67 213 128 ] ,
%w[ 2 83 23 192 ] ,
%w[ 2 98 90 0 ] ,
%w[ 2 113 156 64 ] ,
%w[ 2 128 222 128 ] ,
%w[ 2 144 32 192 ] ,
%w[ 2 159 99 0 ] ,
%w[ 2 174 165 64 ] ,
%w[ 2 189 231 128 ] ,
%w[ 2 205 41 192 ] ,
%w[ 2 220 108 0 ] ,
%w[ 2 235 174 64 ] ,
%w[ 2 250 240 128 ] ,
]rows.each do |row|
bytes = row.map{|value| value.to_i}
word = bytes.inject(''){|s,byte| s << byte.chr}
p word.unpack('N')
endharp:~ > ruby a.rb
[0]
[1000000]
[2000000]
[3000000]
[4000000]
[5000000]
[6000000]
[7000000]
[8000000]
[9000000]
[10000000]
[11000000]
[12000000]
[13000000]
[14000000]
[15000000]
[16000000]
[17000000]
[18000000]
[19000000]
[20000000]
[21000000]
[22000000]
[23000000]
[23934464]
[25000000]
[26000000]
[27000000]
[28000000]
[29000000]
[30065536]
[31000000]
[32000000]
[33000000]
[34000000]
[35000000]
[36000000]
[37000000]
[38000000]
[39000000]
[40000000]
[41000000]
[42000000]
[43000000]
[44000000]
[45000000]
[46000000]
[47000000]
[48000000]
[49000000]
[50000000]look reasonable no?
cheers.
-a
rows.each do |row|
bytes = row.map{|value| value.to_i}
p bytes.pack("C4").unpack('N')
On Tue, Apr 26, 2005 at 10:04:31AM +0900, Ara.T.Howard@noaa.gov wrote:
end
--
Jos Backus
jos at catnook.com
Awesome, thank you so much Ara!! After you mentioned that I have been reading up on the big endian/little endian and things are starting to make sense. Thanks again!
Zach
Ara.T.Howard@noaa.gov wrote:
look reasonable no?