float or double's two's complement representation.

[Rajesh.Rapaka]

Hi,

I need to copy a float value into a byte array. For which I used to do
the left and right shiftings in case of int.

I believe there is no 2's compliment defined for float.

but then how can we write a float value to a network? I need to get the
bytes of a float value to store it into a byte array and then write the
whole array to the network.
(the array contains various other datatypes. thus the byte array
format).

any help?

Thanks in advance.
Rajesh rapaka.

 

[Gordon Beaton]

I need to get the bytes of a float value to store it into a byte
array and then write the whole array to the network.

You could start by reading about Float.floatToIntBits(), for example.

/gordon

 

[Rajesh.Rapaka]

Well, I tried this out. But it doesnt give me the correct output.

 

[Thomas Weidenfeller]

Do not top-post. Reordered for readability.

Well, I tried this out. But it doesnt give me the correct output.

You never specified what you would consider as "correct".
floatToIntBits() does give you the bit pattern of the float value. It is
correct in that sense. If this is not what you want, rephrase your question.

/Thomas

 

[Rajesh.Rapaka]

Do not top-post. Reordered for readability.

what does this mean? (i am using this from google groups).

You never specified what you would consider as "correct".

This could be correct but as i said, I need to dissolve it into the
byte format and reconstruct the same to float. ( as I said i'll need to
store it into a byte array).

floatToIntBits() does give you the bit pattern of the float value. It is
correct in that sense. If this is not what you want, rephrase your question.

hope this simple example may show my problem clearly...

float f = 102.3f;
// making a byte array of the float value (the other method in
discussion is also giving the same result as this.)

ByteArrayOutputStream bas = new ByteArrayOutputStream();
DataOutputStream das = new DataOutputStream(bas);
das.writeFloat(f);
byte[] barr = bas.toByteArray();

// making the float again from the byte arrays.
BigInteger bi = new BigInteger(barr);
float ff = bi.floatValue();
System.out.println("float val is " + ff);

-------------------------------------

output = 1.1207049E9
--------------------------------------
Am I going wrong somewhere?

thanks in advance.

regards,
Rajesh rapaka.

 

[Gordon Beaton]

hope this simple example may show my problem clearly...

float f = 102.3f;
// making a byte array of the float value (the other method in
discussion is also giving the same result as this.)

ByteArrayOutputStream bas = new ByteArrayOutputStream();
DataOutputStream das = new DataOutputStream(bas);
das.writeFloat(f);
byte[] barr = bas.toByteArray();

// making the float again from the byte arrays.
BigInteger bi = new BigInteger(barr);
float ff = bi.floatValue();
System.out.println("float val is " + ff);

Yes, you are using completely unrelated operations to encode and
decode the value.

Since you use DataOutputStream.writeFloat() to write the float, you
should read it back with DataInputStream.readFloat().

/gordon

 

[Patricia Shanahan]

Do not top-post. Reordered for readability.

what does this mean? (i am using this from google groups).

You never specified what you would consider as "correct".

This could be correct but as i said, I need to dissolve it into the
byte format and reconstruct the same to float. ( as I said i'll need to
store it into a byte array).

floatToIntBits() does give you the bit pattern of the float value. It is
correct in that sense. If this is not what you want, rephrase your question.

hope this simple example may show my problem clearly...

float f = 102.3f;
// making a byte array of the float value (the other method in
discussion is also giving the same result as this.)

ByteArrayOutputStream bas = new ByteArrayOutputStream();
DataOutputStream das = new DataOutputStream(bas);
das.writeFloat(f);
byte[] barr = bas.toByteArray();

// making the float again from the byte arrays.
BigInteger bi = new BigInteger(barr);
float ff = bi.floatValue();
System.out.println("float val is " + ff);

-------------------------------------

output = 1.1207049E9
--------------------------------------
Am I going wrong somewhere?

thanks in advance.

regards,
Rajesh rapaka.

You actually have two options, but regardless of which you choose, as
Gordon Beaton has pointed out, you MUST make decoding exactly reverse
the encoding.

1. Write the bit pattern. The float will take exactly four bytes,
regardless of its value. The float will look meaningless in the file
unless you also study the internal structure of float.

2. Use Float.toString(float) and Float.valueOf(String). The length of
the string will depend on the value of the float, and will often be
longer than four bytes. It will be human readable in the file.

Patricia

 

[Rajesh.Rapaka]

You actually have two options, but regardless of which you choose, as
Gordon Beaton has pointed out, you MUST make decoding exactly reverse
the encoding.

This means that I make and a server and it would not support clients
from different platforms?? or I make a server with java and a 3rd party
client made with java would not work even though everyting is correct
just because it used a different technique?

Though as you've said exactly the reverse is working, but isnt it
technique dependent?

Plz do suggest me any docs in case I am missing the whole point.

thanks in advance,
Rajesh Rapaka.

 

[Gordon Beaton]

This means that I make and a server and it would not support clients
from different platforms?? or I make a server with java and a 3rd party
client made with java would not work even though everyting is correct
just because it used a different technique?

If you want to use clients from different technologies, you need to
agree on a standard way of representing your data.

Float.floatToIntBits() gives you the starting point you need, it
returns the contents of the float in a well-defined format. Once you
have those bits, you can shift and mask until you've massaged the data
into a format you like. Did you read the documentation for that
method?

/gordon

 

[Patricia Shanahan]

If you want to use clients from different technologies, you need to
agree on a standard way of representing your data.

Float.floatToIntBits() gives you the starting point you need, it
returns the contents of the float in a well-defined format. Once you
have those bits, you can shift and mask until you've massaged the data
into a format you like. Did you read the documentation for that
method?

In non-java environments, you may need to know that Float.floatToIntBits
gives the bit pattern representing the float as a 32-bit IEEE 754 binary
floating point number.

For java-to-java, even across platforms, it will all just work as long
as the code doing the decoding is consistent with the encoding method.

Patricia

 

[Chris Smith]

I need to copy a float value into a byte array. For which I used to do
the left and right shiftings in case of int.

I believe there is no 2's compliment defined for float.

It is true that floating point numbers don't use two's complement.
However, you seem to be a little unclear about what two's complement is.
The two's complement representation for integers is a way to assign a
specific MEANING to a sequence of bits. Although floating point numbers
don't use the two's complement scheme, there ARE specifications that
define representations of floating point numbers as a sequence of bits.

One of these, and the easiest to use from Java, is IEEE 754. To write
or read IEEE 754 format floating point numbers, you can do any number of
things. For example, you could use java.io.DataOutputStream to write to
a ByteArrayOutputStream.

 

[jmcgill]

One of these, and the easiest to use from Java, is IEEE 754. To write
or read IEEE 754 format floating point numbers, you can do any number of
things. For example, you could use java.io.DataOutputStream to write to
a ByteArrayOutputStream.

I never figured out how to do the normalizing step without using a loop.

 

[Dale King]

You actually have two options, but regardless of which you choose, as
Gordon Beaton has pointed out, you MUST make decoding exactly reverse
the encoding.

1. Write the bit pattern. The float will take exactly four bytes,
regardless of its value. The float will look meaningless in the file
unless you also study the internal structure of float.

2. Use Float.toString(float) and Float.valueOf(String). The length of
the string will depend on the value of the float, and will often be
longer than four bytes. It will be human readable in the file.

As Patricia knows there is another method as well that might come into
play if you possibly want to communicate the exact value of the floating
point value. This is important when you will be going from Java to
another system that may have larger floating point values (e.g. 128-bit
floating point values).

That method is to convert it to BigDecimal and then call toString. This
will give you the string for the *exact* value represented by the float
or double. Float.toString and Double.toString do not usually give you
the *exact* string. They give you the shortest string that when fed to
the parseFloat or parseDouble routine give you the same float or double
value.

 

[Patricia Shanahan]

As Patricia knows there is another method as well that might come into
play if you possibly want to communicate the exact value of the floating
point value. This is important when you will be going from Java to
another system that may have larger floating point values (e.g. 128-bit
floating point values).

That method is to convert it to BigDecimal and then call toString. This
will give you the string for the *exact* value represented by the float
or double. Float.toString and Double.toString do not usually give you
the *exact* string. They give you the shortest string that when fed to
the parseFloat or parseDouble routine give you the same float or double
value.

I agree. I skipped that one in this thread because I was trying to get
across the basics, the importance of picking a definite method and using
it consistently.

Note that the string resulting from the BigDecimal approach may be very
long, especially if the double is large or small. There are tricks to
get around that, if it becomes a problem.

Patricia