<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">This is a message I sent to Rajan as background information and response possibilities for the WG14 discussion this coming week about the issues Joseph Myers raised about our recent proposals and support for double-double formats (see Cfp-interest 2247, 2254, and 2259).<div class=""><br class=""></div><div class="">- Jim Thomas<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">Begin forwarded message:</div><br class="Apple-interchange-newline"><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;" class=""><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif; color:rgba(0, 0, 0, 1.0);" class=""><b class="">From: </b></span><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif;" class="">Jim Thomas <<a href="mailto:jaswthomas@sbcglobal.net" class="">jaswthomas@sbcglobal.net</a>><br class=""></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;" class=""><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif; color:rgba(0, 0, 0, 1.0);" class=""><b class="">Subject: </b></span><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif;" class=""><b class="">Re: [SC22WG14.20798] Overflow, normalized numbers, N2805 and N2806</b><br class=""></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;" class=""><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif; color:rgba(0, 0, 0, 1.0);" class=""><b class="">Date: </b></span><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif;" class="">November 12, 2021 at 4:08:45 PM PST<br class=""></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;" class=""><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif; color:rgba(0, 0, 0, 1.0);" class=""><b class="">To: </b></span><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif;" class="">Rajan Bhakta <<a href="mailto:rbhakta@us.ibm.com" class="">rbhakta@us.ibm.com</a>><br class=""></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;" class=""><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif; color:rgba(0, 0, 0, 1.0);" class=""><b class="">Cc: </b></span><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif;" class="">Joseph Myers <<a href="mailto:joseph@codesourcery.com" class="">joseph@codesourcery.com</a>>, "Fred J. Tydeman" <<a href="mailto:tydeman.fred@gmail.com" class="">tydeman.fred@gmail.com</a>><br class=""></span></div><br class=""><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div class=""><p class="MsoNormal"><span style="font-family: Arial, sans-serif;" class="">Rajan,</span></p><p class="MsoNormal"><span style="font-family: Arial, sans-serif;" class="">Here are some thoughts about presenting CFP proposals N2805, N2806, N2842, and N2843, in the context of the issues Joseph raised.</span></p><div class="">Note that Joseph is CCed, in hopes he will correct any misrepresentations of his concerns and review the suggestions.</div><div class=""><br class=""></div><div class="">- Jim</div><p class="MsoNormal"><span style="font-family: Arial, sans-serif;" class="">Background<o:p class=""></o:p></span></p><p class="MsoNormal"><font face="Arial, sans-serif" class="">C99 and C18 have no explicit requirement about which model numbers are in a type. However, there are implicit requirements. For example, the definitions of the characteristics macros include formulas referring to the model parameters. The type_MAX formula (1 – b^(−p ))*b^emax implies the maximum representable finite number in the type is the maximum normalized floating-point number in the model and the type_MIN formula b^(emin−1) implies the minimum normalized positive floating-point number in the type is the minimum positive normalized floating-point number in the model.</font></p><p class="MsoNormal"><span style="font-family: Arial, sans-serif;" class="">C99 or C18 don’t have an explicit requirement for floating types to include all normalized floating-point numbers in the model. However, the type_DIG formula is derived assuming the density of floating-type representations that is given by the model. Users might make the same assumption.</span></p><p class="MsoNormal"><span style="font-family: Arial, sans-serif;" class="">This C99/C18 specification is ok for IEC 60559 formats and others whose internal representations correspond (close enough) to the C model, but can be problematic for others, notably double-double formats. (Double-double formats represent numbers as pairs of doubles, but implementations put different constraints on what pairs constitute valid representations -- there isn’t a standard double-double format.)</span></p><p class="MsoNormal"><span style="font-family: Arial, sans-serif;" class="">The current C23 draft includes changes intended to accommodate double-double formats, e.g. revised type_MAX and new type_NORM_MAX.</span></p><p class="MsoNormal"><span style="font-family: Arial, sans-serif;" class="">The current C23 draft includes (what is intended to be) an explicit requirement for floating types to include all normalized floating-point numbers in the model. It also clarifies that the model parameters are fixed for each floating type. Thus (referring to the model formula) all x with f1 > 0, with any f2 … fp, and with any e such that emin <= e <= emax, are the normalized floating-point numbers for the given parameters, and all must be representable in the type.</span></p><p class="MsoNormal"><span style="font-family: Arial, sans-serif;" class="">The CFP proposals<o:p class=""></o:p></span></p><p class="MsoNormal"><span style="font-family: Arial, sans-serif;" class=""> </span><span style="font-family: Arial, sans-serif;" class="">N2805</span></p><p class="MsoNormal"><span style="font-family: Arial, sans-serif;" class=""> </span><span style="font-family: Arial, sans-serif;" class="">Joseph’s concern (for double-double formats) is that this definition requires overflows in cases where the result is in the range of full precision representations. A possible replacement for #5:</span></p><p class="MsoNormal" style="margin-left: 0.5in;"><span style="font-family: Arial, sans-serif;" class="">A floating result overflows if a finite result value with ordinary accuracy would have magnitude (absolute value) too large to represent with full precision in the specified type. A result that is an exact infinity does not overflow. …</span></p><p class="MsoNormal"><span style="font-family: Arial, sans-serif;" class="">A problem with this is definition (and others) is the requirement in the next sentence:</span></p><p class="MsoNormal" style="margin-left: 0.5in;"><span style="font-family: Arial, sans-serif;" class="">If a floating result overflows and default rounding is in effect, then the function returns the value of the macro HUGE_VAL, HUGE_VALF, or HUGE_VALL according to the return type, with the same sign as the correct value of the function.</span></p><p class="MsoNormal"><span style="font-family: Arial, sans-serif;" class="">(This requirement seems to be the only definition for the value of the HUGE_VAL macros. Vincent recently raised issues with HUGE_VAL, which are on the agenda for the next CFP meeting.)</span></p><p class="MsoNormal"><span style="font-family: Arial, sans-serif;" class="">A possible solution might be to append after the second sentence in #5:</span></p><p class="MsoNormal" style="margin-left: 0.5in;"><span style="font-family: Arial, sans-serif;" class="">Alternatively, for types with reduced-precision representations of values beyond the overflow threshold, the function may return a representation of the result with less than full precision for the type.</span></p><p class="MsoNormal"><span style="font-family: Arial, sans-serif;" class="">N2806</span></p><p class="MsoNormal"><span style="font-family: Arial, sans-serif;" class="">I suggest (see background above) you present this paper as-is. See if the committee wants a rewording of the definition of normalized floating-point number and/or the requirement that all normalized floating-point numbers in the model be represented in the type. Ask the committee if they would like #4 expanded into separate paragraphs as Joseph suggests (with normalized, subnormal, and unnormalized being defined in separate paragraphs).</span></p><p class="MsoNormal"><span style="font-family: Arial, sans-serif;" class="">N2842</span></p><p class="MsoNormal"><font face="Arial, sans-serif" class="">Joseph’s concern (for double-double formats) is that this proposal does not classify as normal (or as anything else) numbers that are in the range of full precision representations but beyond the range for normalized floating-point numbers. A possible change would be to insert before the last sentence in new paragraph 0:</font></p><p class="MsoNormal" style="margin-left: 0.5in;"><span style="font-family: Arial, sans-serif;" class="">Larger magnitude finite numbers represented with full precision in the type may also be classified as normal.*)</span></p><p class="MsoNormal" style="margin-left: 0.5in;"><span style="font-family: Arial, sans-serif;" class="">*) Double-double formats can provide full precision representations of numbers greater than the maximum normalized floating-point number (5.2.4.2.2).</span></p><p class="MsoNormal"><span style="font-family: Arial, sans-serif;" class="">N2843</span></p><p class="MsoNormal"><span style="font-family: Arial, sans-serif;" class="">Joseph’s concern (for double-double) is that the change requires LDBL_MAX_EXP to be smaller than the exponent for the largest-magnitude full-precision values in the type. A possible change would be to add a qualification (as was done for FLT_MAX, etc.) to the formula:</span></p><p class="MsoNormal" style="margin-left: 0.5in;"><span style="font-family: Arial, sans-serif;" class=""> - maximum integer such that FLT_RADIX raised to one less than that power is a representable finite floating-point number. If that representable finite floating-point number is normalized, emax<o:p class=""></o:p></span></p><div class=""><span style="font-family: Arial, sans-serif;" class=""> </span><br class="webkit-block-placeholder"></div><div class=""><span style="font-family: Arial, sans-serif;" class=""> </span><br class="webkit-block-placeholder"></div></div></div></div></blockquote></div><br class=""></div></body></html>