From: Eric Durant Subject: FLT_MIN: Excessive "Safety Margins"? Date: 15 Jul 2000 00:00:00 GMT Message-ID: <39711BF2.E3EB835E@engin.umich.edu> Content-Transfer-Encoding: 7bit X-Accept-Language: en,pdf Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@eecs.umich.edu X-Trace: news.eecs.umich.edu 963713952 1849 141.213.6.44 (16 Jul 2000 02:19:12 GMT) Organization: EECS Dept. Univ. of Michigan Mime-Version: 1.0 Newsgroups: comp.lang.c I'm confused by the definition of FLT_MIN in the standard library's . According to K&R 2ed., sec. B11, when a value is given in , it "represents the minimum magnitude for the corresponding quantity". This seems to mean that the smallest float greater than 0 in a particular implementation will be no greater than whatever FLT_MIN is defined as. They give 1E-37 as an example -- since this isn't exactly representable in binary (at least not when using a base 2 mantissa), it would seem to be a limit, not a definition of the actual minimum floating point value for any particular implementation. If that's true, why does from compilers such as MSVC6, egcs-2.91 and GNU C 2.95 define FLT_MIN to be a more precise value like 1.17549435e-38f (2^-126 truncated (or rounded) in base 10) and not something like 2e-38f or 1e-37f? The precision of the definition seems to imply that the number has some greater significance. Indeed, -126 is e_min for single precision in IEEE754, but this does not seem relevant to the architectures I'm testing on (i386 (MSVC6 and egcs), ppc603e (egcs) and hp9000/778 (gcc)). Incidentally, on all these architecture/compiler combinations, the minimum float greater than 0 seems to be 1.401...e-045 (2^-149), so an FLT_MIN of 2E-45 or 1E-44 seems more appropriate. Is 2^-126 a "safe value" for a larger class of architectures than I've considered? -- Eric Durant http://edurant.com/