Floating Point: Overflow on interactive input
Andy Tanhauser
I hope someone can help...I have Turbo C++ for Windows loaded (version
4.5). I can not read a float value via interactive input. It always
gives me "Floating Point : Overflow". However, I can read floating
point values from an external file OK.
Thanks for your help,
Andy Tanhauser
a...@fast.net
Matthew Ratcliff
#include <stdio.h>
#include <string.h>
void main( void )
{
char Instr[180];
double FloatNum;
printf("Input a pretty floating point # please ? ");
gets(Instr);
FloatNum = atof( Instr ); // convert string to float #
FloatNum = 3.141592653589793 * FloatNum;
printf("Pi times %s is %lf\n", Instr, FloatNum );
}
Matthew
Andy Tanhauser
#include <iostream.h>
int main()
{
float andy;
cout << " Enter a float number: ";
cin >> andy;
cout << andy;
return 0;
}
Thank again,
Andy
J.B.Gaffney
The problem you are having might be addressed by
http://www.inprise.com/devsupport/borlandcpp/ti_list/TI3308.html
or by
http://www.inprise.com/devsupport/bcppbuilder/faq/QNA210.html
--
John Gaffney
jbga...@hotmail.com
Wayne A. King
>If this program gives me the error:
"If" ??
Try adding the following two lines:
>#include <iostream.h>
#include <float.h>
>int main()
>{
_fpreset();
> float andy;
> cout << " Enter a float number: ";
> cin >> andy;
> cout << andy;
> return 0;
>}
--
Wayne A. King
(ba...@torfree.net, wayne...@ablelink.org,
wak...@idirect.com, Wayne_...@compuserve.com)
Andy Tanhauser
I looked at the 2nd http location and this is exactly my
problem. I loaded Windows 95 Service Pack 1 and also made user the
System Agent was turned off. However, I still have the problem. Help!!!
Andy
Andy Tanhauser
I tried this and it did not work. I still got the same overflow message.
Thanks,
Andy
Greg Chicares
the first gives important extra information.
I was surprised to see your report that Wayne's _fpreset()
suggestion didn't work. That's so strange that I'd suggest
trying it again. If it still doesn't work, take a look at
the FPU control word and compare it to the values in TI3308.
> I looked at the 2nd http location and this is exactly my
> problem. I loaded Windows 95 Service Pack 1 and also made user the
> System Agent was turned off. However, I still have the problem. Help!!!
>
Andy Tanhauser
I tried it again and I still have the problem....I am really confused,
because for the last 2.5 years this worked without a problem. I installed
some software (netscape communicator 4.5 for one) and now I have this
problem. If you can think of anything else to try, I would really appreciate
it.
Thanks,
Andy
Greg Chicares
control word are being reset between your call to _fpreset()
and the interactive input.
Load your progam in Turbo Debugger. Use TD instead of the
IDE debugger because TD shows the FPU state (View|Numeric).
Put breakpoints on
the call to _fpreset()
the line immediately preceding this call
the place where you accept interactive input
and run the program, watching the FPU (PC at the side
is Precision Control).
The values according to my Intel 80287 (yes 287) manual are
00 - 24 bit significand
01 - reserved
10 - 53 bit significand
11 - 64 bit significand
I see the value 2 (10 binary) when the program starts up, then
3 right after the startup code calls _fpreset().
One of two things will happen:
1. PC is 3 after you explicitly call _fpreset(), but is 2 when
you accept input. It changed somewhere in between; find out
where and set it back, or (less elegantly) call _fpreset()
again before asking for input.
2. PC is 3 when you accept input, and you still get the error.
In this case, you've found a new bug.
3. PC is 2 right after calling _fpreset(). This "can't happen."
I'm betting on 1, but I'd like to know what you find.
> I tried it again and I still have the problem....I am really confused,
> because for the last 2.5 years this worked without a problem. I installed
> some software (netscape communicator 4.5 for one) and now I have this
> problem. If you can think of anything else to try, I would really appreciate
> it.
> > It looks like those two URLs discuss the same problem, but
Andy Tanhauser
I do not think I have turbo debugger because I can not find it. I checked
through
the online books and could find no references.
Andy
BRIAN BOWLING
WIN95. I find it very frustrating to try to teach high school students a language
that gives me trouble at every turn. I would love to know the solution to this
dilemma.
Greg Chicares
> works fine at my home with WIN95. I find it very frustrating
> to try to teach high school students a language
> that gives me trouble at every turn.
Wait...it's not the language that's giving you trouble, or
even the compiler. It's the OS. My Intel manual says
"The default setting, and the one that is best suited for
most applications, is the full 64 bits of significance
provided by the temporary-real format. The other settings
are required by the proposed IEEE standard, and are
provided to obtain compatibility with the specifications
of certain existing programming languages. Specifying
less precision nullifies the advantages of the temporary
real format's extended fraction length, and does not
increase execution speed.... Because no speed advantage
results from this option, its only use is for strict
compatibility with the IEEE standard, and with other
computer systems."
Greg Chicares
> find it. I checked through
> the online books and could find no references.
OK, maybe Turbo C++ for Windows doesn't have TD, but no
matter. You can still inspect the FPU control word with
_control87(), and display it with printf() or cout <<
or MessageBox().
Is is possible that your puter doesn't have FPU hardware?
With Win95, try looking at System Properties|Device Manager|
System Devices|Numeric Data Processor, I guess. The old
braindead 386SX lacked hardware FPU support.
Andy Tanhauser
Thanks for your help....I checked through system properties etc and
could not find anything on FPU. However, I played around and remembered
that I recently downloaded a new version of McAfee Virus Scan. I
removed the process that constantly moniters the diskette drive and now
I can again read in float numbers. I restarted the scan process after
testing C++ and again tried and I still could read in floats. So it
must be something that occurs when the virus scan loads on boot.
Anyways....thanks for your help.
Andy
Greg Chicares
Quite a few people have posted problems like this here,
and this information might help them.
My copy of vscan32.exe contains the string
"Microsoft Visual C++ Runtime Library"
I just wonder why a virus scan program would use
floating point.
Inprise folks: can you add Andy's findings to these URLs?
http://www.inprise.com/devsupport/borlandcpp/ti_list/TI3308.html
http://www.inprise.com/devsupport/bcppbuilder/faq/QNA210.html
J. Wesley Cleveland
Greg Chicares wrote:
>
> Wow. Thanks for digging deep enough to discover that.
> Quite a few people have posted problems like this here,
> and this information might help them.
>
> My copy of vscan32.exe contains the string
> "Microsoft Visual C++ Runtime Library"
> I just wonder why a virus scan program would use
> floating point.
>
The problem is that the Microsoft Visual C++ Runtime Library changes the
fp control word on dll startup. I suspect that the virus program has a
hook which is mapped into the process space and resets the control word
after program init
Greg Chicares
J. Wesley Cleveland
Greg Chicares wrote:
>
> Thanks. Any idea why on earth they'd do such a thing? MS I mean.
>
1. MS thinks it is their computer and they can do what they want.
2. It breaks borland programs.
3. Someone did it for some reason, and they don't bother fixing it
because it doesn't bother them.
Take your pick (or add your own ;).
Jerry Bloomfield [TeamB]
wrote:
> Thanks for your help....I checked through system properties etc and
>could not find anything on FPU. However, I played around and remembered
>that I recently downloaded a new version of McAfee Virus Scan. I
>removed the process that constantly moniters the diskette drive and now
>I can again read in float numbers. I restarted the scan process after
>testing C++ and again tried and I still could read in floats. So it
>must be something that occurs when the virus scan loads on boot.
Here is another possibility for you to consider... When you re-ran
your tests, you may well have been accessing the data from the cache,
so the problem may have been hidden from you, but still present...
Another consideration is that he newer MMX instructions use the FP
registers (IIRC), so that may be what was causing problems for you.
If you are running on an MMX based CPU, then if the new virus scanner
uses the MMX instructions, that could potentially cause FPU problems
for you...
Jerry Bloomfield (TeamB)
--
Jerry Bloomfield Jers...@wwa.com
Proud Member of Inprise's TeamB
"We'll do anything if you don't pay us."