469,344 Members | 6,672 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,344 developers. It's quick & easy.

Mysterious -1.#INF without division!

Hi,

I wrote a program to translate a binary file (for which I have the text version) into another binary file (I needed a new format) and text file. There is no division involved, just some nested loops with data being transferred from one buffer to another, to simplify the creation of the desired output files.
The outer (main) loop functions properly 9,947 times and then 'something' happens in the middle of an interior loop, causing all subsequent output to the text file to be -1.#INF00 (i.e. negative infinity). All of the output prior to this point matches the original textfile exactly. I perform a static_cast from type double to type float for each transfer of data in this loop, and I realize that floating point errors can cause 1.#INF to occur, but I see no reason why this should afflict my program.
The input that trips the infinity bug is -1.356217...far from negative infinity. Could this be fixed with something like _fpreset or _control87? If anyone knows what is happening or how to fix/avoid this infinite mystery, I would appreciate the help. Thanks.

Phil
Aug 8 '07 #1
1 2167
gpraghuram
1,275 Expert 1GB
Hi,

I wrote a program to translate a binary file (for which I have the text version) into another binary file (I needed a new format) and text file. There is no division involved, just some nested loops with data being transferred from one buffer to another, to simplify the creation of the desired output files.
The outer (main) loop functions properly 9,947 times and then 'something' happens in the middle of an interior loop, causing all subsequent output to the text file to be -1.#INF00 (i.e. negative infinity). All of the output prior to this point matches the original textfile exactly. I perform a static_cast from type double to type float for each transfer of data in this loop, and I realize that floating point errors can cause 1.#INF to occur, but I see no reason why this should afflict my program.
The input that trips the infinity bug is -1.356217...far from negative infinity. Could this be fixed with something like _fpreset or _control87? If anyone knows what is happening or how to fix/avoid this infinite mystery, I would appreciate the help. Thanks.

Phil
Hi,
float cannot hold a double value and u are getting the error becos of this issue.
Try to use double itself to hold and print vale to new file if it is acceptable in your design.

Raghuram
Aug 9 '07 #2

Post your reply

Sign in to post your reply or Sign up for a free account.

Similar topics

6 posts views Thread by Gustav Lead | last post: by
55 posts views Thread by Martin Jřrgensen | last post: by
1 post views Thread by Peter Knörrich | last post: by
94 posts views Thread by krypto.wizard | last post: by
2 posts views Thread by Martin Manns | last post: by
4 posts views Thread by Joshua J. Kugler | last post: by
reply views Thread by zhoujie | last post: by
1 post views Thread by Marylou17 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.