Hello, could there be an error in the values of the numeric_limits<double> specification? It gives me (Intel, RH9) the following values <snip> TYPE = double is_specialized = 1 radix = 2 digits = 53 digits10 = 15 is_signed = 1 is_integer = 0 is_exact = 0 min = 2.22507e-308 max = 1.79769e+308 epsilon = 2.22045e-16 round_error = 1 min_exponent = -1021 max_exponent = 1024 min_exponent10 = -307 max_exponent10 = 308 is_iec559 = 0 is_bounded = 1 is_modulo = 0 traps = 0 tinyness_before = 0 </snip> I found some documentation on the "numeric_limits" class which states that <snip> max_exponent = Maximum positive integer such that the radix raised to that power is in range. min_exponent = Minimum negative integer such that the radix raised to that power is in range. </snip> This would mean that both values are wrong according to both the IEEE 854 standard as well as the definitions given above. Using the definition, min_exponent should for instance be -1022 - 52 or -1074 for the double type, whilst using the standard it should be just -1022. max_exponent should in both cases be 1023. Also, is_iec559 is false, which would mean that the type is not IEEE 854 compliant?
Subject: Re: New: wrong values for numeric_limits<double> "franky.backeljauw@ua.ac.be" <gcc-bugzilla@gcc.gnu.org> writes: [...] | Using the definition, | min_exponent should for instance be -1022 - 52 or -1074 for the double type, ^^^^^ Where is that coming from? -- Gaby
Subject: Re: wrong values for numeric_limits<double> On Fri, 6 Jun 2003, gdr@integrable-solutions.net wrote: > PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org. > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11099 > > ------- Additional Comments From gdr@integrable-solutions.net 2003-06-06 13:29 ------- > Subject: Re: New: wrong values for numeric_limits<double> > > "franky.backeljauw@ua.ac.be" <gcc-bugzilla@gcc.gnu.org> writes: > > [...] > > | Using the definition, > | min_exponent should for instance be -1022 - 52 or -1074 for the double type, > ^^^^^ > > Where is that coming from? > > -- Gaby Well, that's actually because a double has 53 bits. So, the smaller number you can represent is of the form 0.00..001e-1022, i.e. the number for which all bits are 0 except the last one, and with the minimum exponent, which should be -1022 according to the IEEE 854 standard. This is off course a denormalized number, so it is stored in the form 1.00..001e-1023, where -1023 = L - 1 where L is the largest negative exponent for normalized numbers. The first 1 in the bitpattern has to be ignored; it is supposed to always be 1 so it is not stored and therefore also called the hidden bit. The exponent -1023 is just an indication for the fact that the number itself is either a denormal or zero (if all bits would be zero); for the case of denormals it has to be read as -1022. To get a normalized representation out of the above number, one has to shift the . 52 places to the right. Together with reading the exponent as -1022, we get 1e-1074; so the smallest representable number for the double type is 2^-1074. All this is if take into account the denormalized numbers. If you only take into account the normalized numbers, then the exponent should just be -1022, according to the IEEE 854 standard. But not I just found a site titled "Enquire: Everything you wanted to know about your C Compiler and Machine, but didn't know who to ask" - Google's cache for this site is http://www.google.be/search?q=cache:2PBXiodn1ekJ:www.cwi.nl/ftp/steven/enquire/enquire.html+&hl=nl&ie=UTF-8 - which basically deals with finding the right values for creating your own float.h, if this file should be missing or if it contains errors. In the article I found that <snip> /* Minimum int x such that FLT_RADIX**(x-1) is a normalised double */ #define DBL_MIN_EXP (-1021) /* Minimum normalised double */ #define DBL_MIN 2.2250738585072014e-308 /* Minimum int x such that 10**x is a normalised double */ #define DBL_MIN_10_EXP (-307) /* Maximum int x such that FLT_RADIX**(x-1) is a representable double */ #define DBL_MAX_EXP 1024 /* Maximum double */ </snip> which are the same values as in the numeric_limits case. Maybe this is just not stated correctly in the manual - but then again, the same values and the same information are also found in Microsoft's Visual Studio documentation. So, what should it be? One small question to end my e-mail: where can I find a complete reference for the libstdc++ standard library? -- Best regards, ---------------------------------------------------------------------- Franky Backeljauw (e-mail) franky.backeljauw@ua.ac.be Departement Wiskunde-Informatica (jabber) fbackelj@amessage.de Universiteit Antwerpen (RUCA) (tel) (0032|0)3/218.08.55 ----------------------------------------------------------------------
Subject: Re: wrong values for numeric_limits<double> "franky.backeljauw@ua.ac.be" <gcc-bugzilla@gcc.gnu.org> writes: [...] | > | Using the definition, | > | min_exponent should for instance be -1022 - 52 or -1074 for the double type, | > ^^^^^ | > | > Where is that coming from? | > | > -- Gaby | | Well, that's actually because a double has 53 bits. You didn't get the arithmetic and the model right. [...] | which are the same values as in the numeric_limits case. Maybe this is | just not stated correctly in the manual I can't see in which ways they are not stated correctly in the manual. | - but then again, the same values | and the same information are also found in Microsoft's Visual Studio | documentation. So, what should it be? | | One small question to end my e-mail: where can I find a complete reference | for the libstdc++ standard library? The C++ standard is the normative reference. You might also want to consult LIA-1 and the C standard. -- Gaby
Subject: Re: wrong values for numeric_limits<double> On Fri, 6 Jun 2003, gdr@integrable-solutions.net wrote: > | Well, that's actually because a double has 53 bits. > > You didn't get the arithmetic and the model right. > > | which are the same values as in the numeric_limits case. Maybe this is > | just not stated correctly in the manual > > I can't see in which ways they are not stated correctly in the manual. > > The C++ standard is the normative reference. You might also want to > consult LIA-1 and the C standard. Dear Gaby, I do have the model right, but I did not have the correct documentation. Now I found the correct documentation at http://gcc.gnu.org/onlinedocs/libstdc++/latest-doxygen/limits-source.html which indeed states (e.g.) : <snip> /** The minimum negative integer such that @c radix raised to the power of (one less than that integer) is a normalized floating point number. */ static const int min_exponent = 0; </snip> It seems I submitted a non-existing bug ... my apologies for that. I will try to be more careful in the future. -- Regards, ---------------------------------------------------------------------- Franky Backeljauw (e-mail) franky.backeljauw@ua.ac.be Departement Wiskunde-Informatica (jabber) fbackelj@amessage.de Universiteit Antwerpen (RUCA) (tel) (0032|0)3/218.08.55 ----------------------------------------------------------------------
Submitter says "not a bug". W.