x==NAN || x==INF ?
Martin Weghaus
wrong calculations
martin
Alan Bellingham
>how can I check for incorrect values like NAN or INF which will result on
>wrong calculations
Look at _isnan() in float.h
Alan Bellingham
--
Team Thai Kingdom
<url:http://www.borland.com/newsgroups/> Borland newsgroup descriptions
<url:http://www.borland.com/newsgroups/netiquette.html> netiquette
Chris Uzdavinis [TeamB]
> how can I check for incorrect values like NAN or INF which will result on
> wrong calculations
You can use _isnan, etc.
Note that you won't get NAN values by default in a VCL application.
You must first configure the runtime specifically to turn off floating
point exceptions. Otherwise, the invalid floating point numbers will
trigger hardward/OS exceptions that get converted into VCL exceptions
like EDivByZero, etc.
If you really want to turn off the exceptions, see my post here:
http://makeashorterlink.com/?B32E237C
(which expands to this:)
--
Chris(TeamB);
Daniel Pfeffer
news:3cce3f72$1_1@dnews...
> how can I check for incorrect values like NAN or INF which will result on
> wrong calculations
A method of limited portability would be to examine the bits making up the
floating-point number. The Borland compilers use the IEEE standard for
floating-point arithmetic, and numbers are defined as follows:
float (32 bits):
bit 31 - sign
bits 30..23 - (8 bits) biased exponent, bias = 0x7E
bits 22..0 - mantissa
double (64 bits):
bit 63 - sign
bits 62..52 - (11 bits) biased exponent, bias = 0x3FE
bits 51..0 - mantissa
long double (80 bits):
bit 79 - sign
bits 78..64 - (15 bits) biased exponent, bias = 0x3FFE
bits 63..0 - mantissa
The bits are arranged so that the lowest-numbered bits of the floating-point
value are at the lowest address ("little endian"). The bits within a byte
are also arranged in "little-endian" format, i.e. bit 0 of the 1st byte
corresponds to bit 0 of the floating-point value, etc.
The 'float' and 'double' formats gain an extra bit for the mantissa by
normalising the number and not storing the most significant bit of the
mantissa, which is always a '1'. This rule has an exception when the
exponent value is 0...0 - in this case only, the most significant bit is
assumed to be '0'.
The 'long double' format has no implicit most significant bit; what you see
is what you get.
Both NANs and INFs have an exponent field of 1...1. INFs have a mantissa
field of 0..0 (floats and doubles), or 10...0 (long doubles). NANs have any
other mantissa.
A special NAN is defined for each format - indefinite. This has a sign bit
of 1, and a mantissa of 10....0 (floats and doubles) or 110...0 (long
doubles). It is typically used in some languages to trap the use of
uninitialised variables.
If you define a union as follows:
union UFloat {
float f;
unsigned char uc[sizeof(float)];
};
you may then write C++ functions isnan(const float &); and isinf(const float
&); which cast the 'float' parameter to the UFloat union, then examine the
appropriate bits of the exponent and mantissa. Similar functions may, of
course, be written for 'double' and 'long double'.
If you are writing in C, the best you can do is write functions that accept
pointers - isnanf(const float *), isinff(const float *), and proceed as
before.
Daniel Pfeffer