Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #32888 > unrolled thread

number to byte[]

Back to article view | Back to comp.lang.java.programmer

Contents

  number to byte[] Askfor <askfor@nowhere.net> - 2015-10-17 10:02 +0200
    Re: number to byte[] Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-10-17 08:03 -0400
      Re: number to byte[] Askfor <askfor@nowhere.net> - 2015-10-17 23:03 +0200
        Re: number to byte[] Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-10-17 17:45 -0400
          Re: number to byte[] Askfor <askfor@nowhere.net> - 2015-10-18 12:13 +0200
            Re: number to byte[] Askfor <askfor@nowhere.net> - 2015-10-18 12:44 +0200
              Re: number to byte[] Lew <lewbloch@gmail.com> - 2015-11-29 23:07 -0800
            Re: number to byte[] Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-10-18 08:40 -0400
        Re: number to byte[] Nigel Wade <nmw@ion.le.ac.uk> - 2015-10-19 10:43 +0100
          Re: number to byte[] Wayne <nospam@all.invalid> - 2015-10-20 00:45 -0400
          Re: number to byte[] Kevin McMurtrie <mcmurtrie@pixelmemory.us> - 2015-10-20 13:35 -0700
    Re: number to byte[] Lothar Kimmeringer <news200709@kimmeringer.de> - 2015-10-25 10:22 +0100

#32888 — number to byte[]

I am trying to get 4 byte[] representation of an integer, which might be 
32 bit long.

Obviously, I could AND with 255 and take byteValue(), then shift 8 times 
to the right and repeat the process 3 times. Is there any more elegant way ?

[toc] | [next] | [standalone]

#32889

On 10/17/2015 4:02 AM, Askfor wrote:
> I am trying to get 4 byte[] representation of an integer, which might be
> 32 bit long.
>
> Obviously, I could AND with 255 and take byteValue(), then shift 8 times
> to the right and repeat the process 3 times. Is there any more elegant
> way ?

     I can't think of one, off-hand.

     But *why* do you want this four-byte array?  Are you planning to
write it to some output destination?  If so, perhaps you should use a
DataOutputStream (or other DataOutput implementation) and call its
writeInt() method.  Or, perhaps you should use an IntBuffer.  What
are you trying to do?

-- 
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM

[toc] | [prev] | [next] | [standalone]

#32891

On 10/17/2015 02:03 PM, Eric Sosman wrote:
> On 10/17/2015 4:02 AM, Askfor wrote:
>> I am trying to get 4 byte[] representation of an integer, which might be
>> 32 bit long.
>>
>> Obviously, I could AND with 255 and take byteValue(), then shift 8 times
>> to the right and repeat the process 3 times. Is there any more elegant
>> way ?
>
>      I can't think of one, off-hand.
>
>      But *why* do you want this four-byte array?  Are you planning to
> write it to some output destination?  If so, perhaps you should use a
> DataOutputStream (or other DataOutput implementation) and call its
> writeInt() method.  Or, perhaps you should use an IntBuffer.  What
> are you trying to do?
>

It is going to be a part of a data header, which needs to be of fixed 
length. Also it will contain a value of an offset which cabn't be longer 
than 32-bits. So, I don't care how big int actually is, as long as it is 
big enough to hold 32 bit unsigned value.

I started with serialization, too, but I realized it won't work.

Thanks.

[toc] | [prev] | [next] | [standalone]

#32892

On 10/17/2015 5:03 PM, Askfor wrote:
> On 10/17/2015 02:03 PM, Eric Sosman wrote:
>> On 10/17/2015 4:02 AM, Askfor wrote:
>>> I am trying to get 4 byte[] representation of an integer, which might be
>>> 32 bit long.
>>>
>>> Obviously, I could AND with 255 and take byteValue(), then shift 8 times
>>> to the right and repeat the process 3 times. Is there any more elegant
>>> way ?
>>
>>      I can't think of one, off-hand.
>>
>>      But *why* do you want this four-byte array?  Are you planning to
>> write it to some output destination?  If so, perhaps you should use a
>> DataOutputStream (or other DataOutput implementation) and call its
>> writeInt() method.  Or, perhaps you should use an IntBuffer.  What
>> are you trying to do?
>>
>
> It is going to be a part of a data header, which needs to be of fixed
> length. Also it will contain a value of an offset which cabn't be longer
> than 32-bits. So, I don't care how big int actually is, as long as it is
> big enough to hold 32 bit unsigned value.

     It's probably simplest just to read and write the int directly,
letting the stream (or buffer) take care of assembling and disassembling
the bytes.  Classes that implement DataOutput and DataInput already have
the necessary machinery, provided you want BigEndian byte order.  If you
need LittleEndian, I think you can manage it with a Buffer.

     (I didn't mention it before, but RandomAccessFile can also read and
write BigEndian integers.)

> I started with serialization, too, but I realized it won't work.

     I didn't suggest serialization.  Perhaps you've confused DataOutput
with ObjectOutput; they are not the same.

-- 
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM

[toc] | [prev] | [next] | [standalone]

#32894

On 10/17/2015 11:45 PM, Eric Sosman wrote:
> On 10/17/2015 5:03 PM, Askfor wrote:
>> On 10/17/2015 02:03 PM, Eric Sosman wrote:
>>> On 10/17/2015 4:02 AM, Askfor wrote:
>>>> I am trying to get 4 byte[] representation of an integer, which
>>>> might be
>>>> 32 bit long.
>>>>
>>>> Obviously, I could AND with 255 and take byteValue(), then shift 8
>>>> times
>>>> to the right and repeat the process 3 times. Is there any more elegant
>>>> way ?
>>>
>>>      I can't think of one, off-hand.
>>>
>>>      But *why* do you want this four-byte array?  Are you planning to
>>> write it to some output destination?  If so, perhaps you should use a
>>> DataOutputStream (or other DataOutput implementation) and call its
>>> writeInt() method.  Or, perhaps you should use an IntBuffer.  What
>>> are you trying to do?
>>>
>>
>> It is going to be a part of a data header, which needs to be of fixed
>> length. Also it will contain a value of an offset which cabn't be longer
>> than 32-bits. So, I don't care how big int actually is, as long as it is
>> big enough to hold 32 bit unsigned value.
>
>      It's probably simplest just to read and write the int directly,
> letting the stream (or buffer) take care of assembling and disassembling
> the bytes.  Classes that implement DataOutput and DataInput already have
> the necessary machinery, provided you want BigEndian byte order.  If you
> need LittleEndian, I think you can manage it with a Buffer.
>
>      (I didn't mention it before, but RandomAccessFile can also read and
> write BigEndian integers.)
>
>> I started with serialization, too, but I realized it won't work.
>
>      I didn't suggest serialization.  Perhaps you've confused DataOutput
> with ObjectOutput; they are not the same.
>

I understand that, but then I will have to what the int is 32 bit. I am 
not sure that int is 32-bit on all platforms and all VM's . I need 
exactly 4 bytes to be written and read. Endian-ness wouldn't matter if
I could only be sure that int is 32-bit always. Java tutorial at 
Oracle's site says that int is 32-bi 'by default', which I understand
as 'unless someone has different implementation'.

[toc] | [prev] | [next] | [standalone]

#32895

On 10/18/2015 12:13 PM, Askfor wrote:
> On 10/17/2015 11:45 PM, Eric Sosman wrote:
>> On 10/17/2015 5:03 PM, Askfor wrote:
>>> On 10/17/2015 02:03 PM, Eric Sosman wrote:
>>>> On 10/17/2015 4:02 AM, Askfor wrote:
>>>>> I am trying to get 4 byte[] representation of an integer, which
>>>>> might be
>>>>> 32 bit long.
>>>>>
>>>>> Obviously, I could AND with 255 and take byteValue(), then shift 8
>>>>> times
>>>>> to the right and repeat the process 3 times. Is there any more elegant
>>>>> way ?
>>>>
>>>>      I can't think of one, off-hand.
>>>>
>>>>      But *why* do you want this four-byte array?  Are you planning to
>>>> write it to some output destination?  If so, perhaps you should use a
>>>> DataOutputStream (or other DataOutput implementation) and call its
>>>> writeInt() method.  Or, perhaps you should use an IntBuffer.  What
>>>> are you trying to do?
>>>>
>>>
>>> It is going to be a part of a data header, which needs to be of fixed
>>> length. Also it will contain a value of an offset which cabn't be longer
>>> than 32-bits. So, I don't care how big int actually is, as long as it is
>>> big enough to hold 32 bit unsigned value.
>>
>>      It's probably simplest just to read and write the int directly,
>> letting the stream (or buffer) take care of assembling and disassembling
>> the bytes.  Classes that implement DataOutput and DataInput already have
>> the necessary machinery, provided you want BigEndian byte order.  If you
>> need LittleEndian, I think you can manage it with a Buffer.
>>
>>      (I didn't mention it before, but RandomAccessFile can also read and
>> write BigEndian integers.)
>>
>>> I started with serialization, too, but I realized it won't work.
>>
>>      I didn't suggest serialization.  Perhaps you've confused DataOutput
>> with ObjectOutput; they are not the same.
>>
>
> I understand that, but then I will have to what the int is 32 bit. I am
> not sure that int is 32-bit on all platforms and all VM's . I need
> exactly 4 bytes to be written and read. Endian-ness wouldn't matter if
> I could only be sure that int is 32-bit always. Java tutorial at
> Oracle's site says that int is 32-bi 'by default', which I understand
> as 'unless someone has different implementation'.
>
>
The same source states firmly that writeInt methods write 4 bytes, 
always... I think I am going to isolate it in a separate method, so if
any VM proves to be different, I am going to modify the method.

[toc] | [prev] | [next] | [standalone]

#33243

On Sunday, October 18, 2015 at 4:01:18 AM UTC-7, Askfor wrote:
> On 10/18/2015 12:13 PM, Askfor wrote:
> > On 10/17/2015 11:45 PM, Eric Sosman wrote:
> >> On 10/17/2015 5:03 PM, Askfor wrote:
> >>> On 10/17/2015 02:03 PM, Eric Sosman wrote:
> >>>> On 10/17/2015 4:02 AM, Askfor wrote:
> >>>>> I am trying to get 4 byte[] representation of an integer, which
> >>>>> might be
> >>>>> 32 bit long.
> >>>>>
> >>>>> Obviously, I could AND with 255 and take byteValue(), then shift 8
> >>>>> times
> >>>>> to the right and repeat the process 3 times. Is there any more elegant
> >>>>> way ?
> >>>>
> >>>>      I can't think of one, off-hand.
> >>>>
> >>>>      But *why* do you want this four-byte array?  Are you planning to
> >>>> write it to some output destination?  If so, perhaps you should use a
> >>>> DataOutputStream (or other DataOutput implementation) and call its
> >>>> writeInt() method.  Or, perhaps you should use an IntBuffer.  What
> >>>> are you trying to do?
> >>>>
> >>>
> >>> It is going to be a part of a data header, which needs to be of fixed
> >>> length. Also it will contain a value of an offset which cabn't be longer
> >>> than 32-bits. So, I don't care how big int actually is, as long as it is
> >>> big enough to hold 32 bit unsigned value.
> >>
> >>      It's probably simplest just to read and write the int directly,
> >> letting the stream (or buffer) take care of assembling and disassembling
> >> the bytes.  Classes that implement DataOutput and DataInput already have
> >> the necessary machinery, provided you want BigEndian byte order.  If you
> >> need LittleEndian, I think you can manage it with a Buffer.
> >>
> >>      (I didn't mention it before, but RandomAccessFile can also read and
> >> write BigEndian integers.)
> >>
> >>> I started with serialization, too, but I realized it won't work.
> >>
> >>      I didn't suggest serialization.  Perhaps you've confused DataOutput
> >> with ObjectOutput; they are not the same.
> >>
> >
> > I understand that, but then I will have to what the int is 32 bit. I am
> > not sure that int is 32-bit on all platforms and all VM's . I need
> > exactly 4 bytes to be written and read. Endian-ness wouldn't matter if
> > I could only be sure that int is 32-bit always. Java tutorial at
> > Oracle's site says that int is 32-bi 'by default', which I understand
> > as 'unless someone has different implementation'.
> >
> >
> The same source states firmly that writeInt methods write 4 bytes, 
> always... I think I am going to isolate it in a separate method, so if
> any VM proves to be different, I am going to modify the method.

Dude, the JLS specifies the size of 'int', 'long', etc. If a JVM varies from the spec, it is not a JVM.
 
Read the JLS (Java Language Specification).

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#32896

On 10/18/2015 6:13 AM, Askfor wrote:
> [...]
> I understand that, but then I will have to what the int is 32 bit. I am
> not sure that int is 32-bit on all platforms and all VM's . I need
> exactly 4 bytes to be written and read. Endian-ness wouldn't matter if
> I could only be sure that int is 32-bit always. Java tutorial at
> Oracle's site says that int is 32-bi 'by default', which I understand
> as 'unless someone has different implementation'.

     A Java `int' is defined as having the value range -2147483648 to
2147483647, inclusive.

http://docs.oracle.com/javase/specs/jls/se8/html/jls-4.html#jls-4.2.1

We cannot know how a particular JVM chooses to represent this range
of values internally, because Java has no way to examine or fiddle
with the representation: You can look at an `int' and determine its
value, but you cannot "see" the individual pieces of that value.  (Not
even by bit-wise operations like shifting and masking: The results of
these operations are defined in terms of the values of their operands,
not their physical structure.)  So, it is possible -- highly unlikely,
but possible -- that a particular JVM might encode `int' values as
96-bit Gray-coded objects, but there's no way you could tell.

     ... which makes no difference at all to you, because you don't
care even one little bit (sorry) about what the JVM does in private.
You care only about what the JVM does when it "exports" the `int'
value, making it visible to the gaze of the outside world.  When
that happens, the bytes produced by DataOutput and the like *are*
specified, and are independent of whatever the JVM does internally.

     Conclusion: Regardless of what the JVM does in the privacy of its
own bedroom, the observable behavior is *always* "as if" an `int' had
exactly 32 bits.

-- 
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM

[toc] | [prev] | [next] | [standalone]

#32898

On 17/10/15 22:03, Askfor wrote:
> It is going to be a part of a data header, which needs to be of fixed length. Also it will contain a value of an offset
> which cabn't be longer than 32-bits. So, I don't care how big int actually is, as long as it is big enough to hold 32
> bit unsigned value.

int is signed, as are all Java integers.
int won't hold a 32bit unsigned integer.

It will hold a 4-byte value as long as you don't attempt to interpret that value as a number, for example by performing 
any arithmetic on the value. If the MSB of the MSbyte is 1, it will be interpreted as being a negative number. Don't 
forget that byte is also signed, so the MSbyte would also be negative.
If you need a 32bit unsigned value then you must promote it to 64bit, without sign extension.

Of course, you could write your own UnsignedInteger class, with appropriate storage, and input/output methods.
In the long run it might cause you the least surprises.

For storing/retrieving values in byte[] arrays ByteBuffer is one way to go.

[toc] | [prev] | [next] | [standalone]

#32903

On 10/19/2015 5:43 AM, Nigel Wade wrote:
> On 17/10/15 22:03, Askfor wrote:
>> It is going to be a part of a data header, which needs to be of fixed length. Also
>> it will contain a value of an offset
>> which cabn't be longer than 32-bits. So, I don't care how big int actually is, as
>> long as it is big enough to hold 32
>> bit unsigned value.
> 
> int is signed, as are all Java integers.
> int won't hold a 32bit unsigned integer.
> 
> ...
> 

Actually, in Java 8 a number of methods were added to java.lang.Integer,
to work with unsigned integers that take 32 bits of storage.

-- 
Wayne

[toc] | [prev] | [next] | [standalone]

#32910

In article <d8jsa9Fi4ifU1@mid.individual.net>,
 Nigel Wade <nmw@ion.le.ac.uk> wrote:

> On 17/10/15 22:03, Askfor wrote:
> > It is going to be a part of a data header, which needs to be of fixed 
> > length. Also it will contain a value of an offset
> > which cabn't be longer than 32-bits. So, I don't care how big int actually 
> > is, as long as it is big enough to hold 32
> > bit unsigned value.
> 
> int is signed, as are all Java integers.
> int won't hold a 32bit unsigned integer.
> 
> It will hold a 4-byte value as long as you don't attempt to interpret that 
> value as a number, for example by performing 
> any arithmetic on the value. If the MSB of the MSbyte is 1, it will be 
> interpreted as being a negative number. Don't 
> forget that byte is also signed, so the MSbyte would also be negative.
> If you need a 32bit unsigned value then you must promote it to 64bit, without 
> sign extension.
> 
> Of course, you could write your own UnsignedInteger class, with appropriate 
> storage, and input/output methods.
> In the long run it might cause you the least surprises.
> 
> For storing/retrieving values in byte[] arrays ByteBuffer is one way to go.

Only multiplication, division, and sign extension will damage an 
unsigned number.  Comparison doesn't work.  Addition, subtraction, and 
serialization don't matter in Java. (In assembly they toggle 
underflow/overflow flags differently)

Special unsigned operations can be performed by expansion to long and 
truncating the sign extension.  It's only tricky when you need to 
multiply, divide, and compare unsigned longs.

-- 
I will not see posts from astraweb, theremailer, dizum, or google
because they host Usenet flooders.

[toc] | [prev] | [next] | [standalone]

#32935

Askfor wrote:

> I am trying to get 4 byte[] representation of an integer, which might be 
> 32 bit long.
> 
> Obviously, I could AND with 255 and take byteValue(), then shift 8 times 
> to the right and repeat the process 3 times. Is there any more elegant way ?

You could use BigInteger.toByteArray but I think you should stick
with the ANDing (put it in a helper method), since the mentioned
returns a byte-array of variable size (with five elements for
values > 0x0fffffff).


Cheers, Lothar
-- 
Lothar Kimmeringer                E-Mail: spamfang@kimmeringer.de
               PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81)

Always remember: The answer is forty-two, there can only be wrong
                 questions!

--- news://freenews.netfront.net/ - complaints: news@netfront.net ---

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web