471,887 Members | 1,471 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,887 software developers and data experts.

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 2252
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 zermasroor | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.