By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
432,441 Members | 979 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 432,441 IT Pros & Developers. It's quick & easy.

Mysterious -1.#INF without division!

P: 1
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
Share this Question
Share on Google+
1 Reply


gpraghuram
Expert 100+
P: 1,275
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.