[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

long conversion ...

Zach Dennis

4/25/2005 10:22:00 PM

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


6 Answers

Ara.T.Howard

4/25/2005 10:44:00 PM

0

Zach Dennis

4/26/2005 12:18:00 AM

0

Ara.T.Howard@noaa.gov wrote:

> 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

4/26/2005 12:48:00 AM

0

Vance A Heron

4/26/2005 3:35:00 AM

0

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')
> 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



Jos Backus

4/26/2005 5:22:00 AM

0

On Tue, Apr 26, 2005 at 10:04:31AM +0900, Ara.T.Howard@noaa.gov wrote:
> rows.each do |row|
> bytes = row.map{|value| value.to_i}
p bytes.pack("C4").unpack('N')
> end

--
Jos Backus
jos at catnook.com


Zach Dennis

4/26/2005 2:05:00 PM

0

Ara.T.Howard@noaa.gov wrote:

> look reasonable no?
>

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