converting a character array to a float (newbie)

[Matthew R. Dempsky]

char buffer[128];
int n;

bzero(buffer,128)
n=read(myFD,buffer,127);

printf("You read in a value of %f\n",buffer); /*strange output here*/

buffer is a char pointer here, not a floating point value. Try:

printf ("You read in a value of %f\n", *(float *)buffer);

 

[Jim Bancroft]

Hi everyone,

Trying to figure something out...I have a character buffer that I fill up
using read(). I know that what's coming back is in fact a float, but I
can't seem to convert and print it out correctly. Here's a snippet:

char buffer[128];
int n;

bzero(buffer,128)
n=read(myFD,buffer,127);

printf("You read in a value of %f\n",buffer); /*strange output here*/


....pretty straightforward I guess. I should mention the buffer is 128 bytes
long because sometimes I'm reading in text. But in the circumstance above I
know for a fact it'll be a float that's coming in.

I've tried a few things but no luck so far. Could someone point me in the
right direction? Thanks very much.

 

[jmcgill]

char buffer[128];
int n;

bzero(buffer,128)
n=read(myFD,buffer,127);

printf("You read in a value of %f\n",buffer); /*strange output here*/

I've tried a few things but no luck so far. Could someone point me in the
right direction? Thanks very much.

You are getting 32 bits of IEEE-754 float, and the byteorder is correct
for your platform?


Have you tested that strategy with known values in your buffer, in that
printf?

I think a better approach to this problem might be with a union,
something like this (from my rusty memory):

union {
float f;
unsigned char buf[MAX_WIDTH];
} u;

Then you could read the value into u.buf and reference it as u.f
But byteorder will still be a problem.

Look at the source on this page:
http://www.answers.com/topic/ieee-floating-point-standard

They are explicitly putting each character in place, masking out the
sign, exponent, and mantissa, and returning the result as a float.

 

[Jim Bancroft]

Thanks for your help. Unfortunately, when I do that I always get a result
of 0.000000, no matter what the actual value being read back?

I don't know if this makes any difference but the "myFD" descriptor
referenced below is actually a socket. It's being filled by a java socket
server using java's PrintWriter class. In this instance the PrintWriter is
constructed from a Socket's getOutputStream() method. I know this isn't a
java newsgroup but I thought I'd toss that in, for purposes of full
disclosure.

char buffer[128];
int n;

bzero(buffer,128)
n=read(myFD,buffer,127);

printf("You read in a value of %f\n",buffer); /*strange output here*/

buffer is a char pointer here, not a floating point value. Try:

printf ("You read in a value of %f\n", *(float *)buffer);

 

[Ancient_Hacker]

Hi everyone,

Trying to figure something out...I have a character buffer that I fill up
using read(). I know that what's coming back is in fact a float, but I
can't seem to convert and print it out correctly.

Exactly what is being sent by the other end? Are they characters:
"3.14159",
or binary float values?

If binary, how will you ensure the float format on the sending end is
the same on the receiveing end?

If they're characters, you must do a atof() or sscanf() to convert the
characters to a float.

If you're receiving binary, you have to be sure the sending and
receiving formats are identical. Not just both IEEE standard, but sent
in the same byte ordering.

 

[Keith Thompson]

Trying to figure something out...I have a character buffer that I fill up
using read(). I know that what's coming back is in fact a float, but I
can't seem to convert and print it out correctly. Here's a snippet:

char buffer[128];
int n;

bzero(buffer,128)
n=read(myFD,buffer,127);

printf("You read in a value of %f\n",buffer); /*strange output here*/


...pretty straightforward I guess. I should mention the buffer is 128 bytes
long because sometimes I'm reading in text. But in the circumstance above I
know for a fact it'll be a float that's coming in.

I've tried a few things but no luck so far. Could someone point me in the
right direction? Thanks very much.

bzero() and read() are not standard C functions. For maximal
portability (and if you want advice in this newsgroup), use memset()
and fread() instead.

It probably makes more sense for buffer to be an array of unsigned
char rather than plain (possibly signed) char.

Try displaying the elements of buffer as integers:

/* untested code */
for (i = 0; i < sizeof(float); i ++) {
printf("buffer[%d] = %d\n", i, buffer);
}

If the results aren't what you expect, then the problem is probably
somewhere outside the scope of standard C.

You mention elsewhere that you're reading from a socket. Look at
whatever is on the other end of that socket. (Sockets are off-topic
here.)

 

[jmcgill]

Thanks for your help. Unfortunately, when I do that I always get a result
of 0.000000, no matter what the actual value being read back?

I would do this; Put a known float value on this I/O. Evaluate it by
hand to see that it is indeed what you are expecting.

You are using java.io.PrintWriter to create the input. Are you
controlling the character encoding? That is, are you sure it's plain
bytes, not UTF-16?

 

[Thomas J. Gritzan]

Thanks for your help.

Please don't top-post. See my signature.

Unfortunately, when I do that I always get a result
of 0.000000, no matter what the actual value being read back?

Did you check the return value of read()? If read() didn't read something
and returns an error, the buffer would still be zero-filled.

I don't know if this makes any difference but the "myFD" descriptor
referenced below is actually a socket. It's being filled by a java socket
server using java's PrintWriter class.

http://java.sun.com/j2se/1.4.2/docs/api/java/io/PrintWriter.html

"Print formatted representations of objects to a text-output stream. This
class implements all of the print methods found in PrintStream. It does not
contain methods for writing raw bytes, for which a program should use
unencoded byte streams."

It seems that this class is not designed to write binary output. But since
that is offtopic here, I won't go further into this.

 

[jmcgill]

If binary, how will you ensure the float format on the sending end is
the same on the receiveing end?

He mentioned that it's java.io.PrintWriter, which has a print(float)
method which stringifies the number and puts it on the output stream as
text, in whatever character encoding is applicable to the locale.

Even if he's lucky, and that character encoding is UTF-8, he is
basically trying to cast a string of characters as a C float, which
won't work.

If they're characters, you must do a atof() or sscanf() to convert the
characters to a float.

Based on the info so far, I'm sure that's the answer. However, it is
not necessarily in a single-byte character set!

 

[Barry Schwarz]

char buffer[128];
int n;

bzero(buffer,128)
n=read(myFD,buffer,127);

printf("You read in a value of %f\n",buffer); /*strange output here*/

buffer is a char pointer here, not a floating point value. Try:

printf ("You read in a value of %f\n", *(float *)buffer);

And then pray that buffer is properly aligned for a float.


Remove del for email

 

[Jim Bancroft]

You are using java.io.PrintWriter to create the input. Are you
controlling the character encoding? That is, are you sure it's plain
bytes, not UTF-16?

I'm pretty sure it's UTF-8 encoding. At least, when I write an integer to
the PrintWriter I can recover it from the C program, after using atoi().
_That_ works fine. It's trying to write/read/print a float that my trouble
comes. So I'm thinking the character encoding is ok at least?

 

[jmcgill]

I'm pretty sure it's UTF-8 encoding. At least, when I write an integer to
the PrintWriter I can recover it from the C program, after using atoi().
_That_ works fine. It's trying to write/read/print a float that my trouble
comes. So I'm thinking the character encoding is ok at least?

I don't think you understand the basic problem.

If you use java.io.PrintWriter.print() to print a float, you literally
get a textual representation of that numeric value on the output stream.
You do not get the binary representation of that numeric value, IEEE754
or otherwise. You get a series of characters, and not only that, it is
up to the *runtime system* whether that series of characters consists of
the nice one character-per-8-bit-byte that you are expecting.

But your problem is even worse. You are now passing these bytes, which
are the character representations of your number: "3.14" to printf()'s
%f formatter.

So for the example of "3.14" you'd be getting a float that's like:
33 2E 31 34

Which, if evaluated as an IEEE754 single precision 32-bit value,
works out to be 4.0557282e-8

Note that if you feed that to printf("%f", ...) you can generally expect
to get 0.0000000

In fact, anything that begins with an ASCII digit is going to fall well
outside the range of %f's default precision, since even "9999" leads to
an exponent of -13 so you're *always* going to see zeros...


If you insist on taking this approach for data interchange, you will
need to use an output mechanism that actually puts binary
representations of the data in the output. But I would actually try to
convince you that some kind of markup format for the data would be
preferable. Although if you cannot change the sender of the data,
then sscanf(), atoi(), strtod(), and friends may help you.

I notice you're getting a 127 byte buffer. Do you have some kind of
delimiter that tells you where to stop parsing?

If this were a java forum I would have some specific advice about object
serialization.

 

[Jim Bancroft]

I've tried atof() and strtod(), but no luck so far. All zeros no matter
what. I'll keep digging. Man, this is tough.

 

[jmcgill]

I've tried atof() and strtod(), but no luck so far. All zeros no matter
what. I'll keep digging. Man, this is tough.

Have you simply looked at the bytes in the input stream?

Consider the mystery for us out here!

 

[russell kym horsell]

I've tried atof() and strtod(), but no luck so far. All zeros no matter
what. I'll keep digging. Man, this is tough.

Don't forget #include <math.h> otherwise result of atof may be
unexpectedly int.

 

[russell kym horsell]

} > I've tried atof() and strtod(), but no luck so far. All zeros no matter
} > what. I'll keep digging. Man, this is tough.
} Don't forget #include <math.h> otherwise result of atof may be
} unexpectedly int.


Ahem! Maybe that should be stdlib.h. :}

 

[CBFalconer]

I've tried atof() and strtod(), but no luck so far. All zeros no
matter what. I'll keep digging. Man, this is tough.

Yes, it is. What did you try in what? Do you expect us to read
minds? Without adequate quotes your article is totally
meaningless. Read the following URLs:

<http://cfaj.freeshell.org/google/>
<http://www.safalra.com/special/googlegroupsreply/>

 

[Jim Bancroft]

Yes, it is. What did you try in what? Do you expect us to read
minds? Without adequate quotes your article is totally
meaningless.

Oh for crying out loud. I "tried" what I mentioned in my first post and
subsequent ones. Just making an observation, not asking for a mind reading.
Man, are there some stiffs on this newsgroup.

 

[Keith Thompson]

The above was written by CBFalconer. Please don't snip attribution
lines.

Oh for crying out loud. I "tried" what I mentioned in my first post and
subsequent ones. Just making an observation, not asking for a mind reading.
Man, are there some stiffs on this newsgroup.

If you post a followup, you need to provide enough context so each
article makes sense on its own. There are dozens of current threads
in this newsgroup. Some of us try to keep up with all of them. I
can't remember the details of every thread.

<http://cfaj.freeshell.org/google/> has some good information on how
to post followups.

 

[jmcgill]

Man, are there some stiffs on this newsgroup.

Some of them, like the one you just told off, are extremely well-known
and experienced programmers. It might be wise to be nice to them and
follow their advice.

Did you take my advice? I was hoping you would post some examples of of
your data at each end of your IO.