[Cfp-interest 3313] Re: ERANGE question

[Jim Thomas]

> [Cfp-interest 3311] Re: ERANGE question
> 
> Vincent Lefevre vincent at vinc17.net <mailto:cfp-interest%40oakapple.net?Subject=Re%3A%20%5BCfp-interest%203311%5D%20Re%3A%20ERANGE%20question&In-Reply-To=%3C20241012225844.GL4099%40qaa.vinc17.org%3E>
> Sat Oct 12 15:58:44 PDT 2024
> Previous message (by thread): [Cfp-interest 3309] Re: ERANGE question <http://mailman.oakapple.net/pipermail/cfp-interest/2024-October/003324.html>
> Next message (by thread): [Cfp-interest 3307] JTC1/SC22/WG14/CFP 2024/09/18 Meeting minutes v2 <http://mailman.oakapple.net/pipermail/cfp-interest/2024-October/003322.html>
> Messages sorted by: [ date ] <http://mailman.oakapple.net/pipermail/cfp-interest/2024-October/date.html#3326> [ thread ] <http://mailman.oakapple.net/pipermail/cfp-interest/2024-October/thread.html#3326> [ subject ] <http://mailman.oakapple.net/pipermail/cfp-interest/2024-October/subject.html#3326> [ author ] <http://mailman.oakapple.net/pipermail/cfp-interest/2024-October/author.html#3326>
> On 2024-10-12 14:29:07 -0700, Jim Thomas wrote:
> > On Oct 9, 2024, at 5:45 AM, Vincent Lefevre <vincent at vinc17.net <http://mailman.oakapple.net/mailman/listinfo/cfp-interest>> wrote:
> > > "the representation with full precision in the specified type" implies
> > > that the result is rounded. Otherwise I don't see how this can be
> > > interpreted.
> > > 
> > > But I'm wondering why the word "full" is used.
> > 
> > This is intended to accommodate double-double formats that can
> 
> I now remember, but for the double-double format, you'll get
> an infinity in such a case; see below.
> 
> > represent results with huge finite magnitude but not with the full
> > precision of the type, e.g. if both parts of a double-double number
> > are DBL_MAX. Such numbers are beyond the range of C model numbers.
> > Such results are overflows, per definition above.
> 
> No, such numbers are not possible in a double-double format. From
> the spec in GCC's libgcc/config/rs6000/ibm-ldouble-format file:
> 
>   Each long double is made up of two IEEE doubles.  The value of the
> long double is the sum of the values of the two parts (except for
> -0.0).  The most significant part is required to be the value of the
> long double rounded to the nearest double, as specified by IEEE.  For
> Inf values, the least significant part is required to be one of +0.0
> or -0.0.  No other requirements are made; so, for example, 1.0 may be
> represented as (1.0, +0.0) or (1.0, -0.0), and the low part of a NaN
> is don't-care.
> 
> See the condition on the most significant part.
How does GCC treat pairs of doubles that don’t have this property? 

Are you claiming that all double-double implementations adhere to this specification? Or that this is a convention that has so much agreement that C needn't accommodate other possibilities?
> 
> However, one can imagine other formats where there are "holes" in the
> ordinary accuracy
>  (a unum format can be such a case, BTW).
> 
> > > Ditto in 6.4.5.3p7
> > > about floating literals of decimal floating type. Is this because
> > > some representations are not normalized, thus are regarded as
> > > having less precision?
> > > 
> > >> Should errno be set to ERANGE, even if x^y rounds to DBL_MAX?
> > > 
> > > In rounding to nearest, I would say no.
> > > 
> > > But for the directed rounding modes, the definition seems wrong.
> > 
> > Note that the definition includes “ordinary accuracy” (defined by
> > the implementation). This is intended to cover IEEE 754 overflow
> > with directed rounding (as well as no nearest).
> 
> Well, the definition is wrong. But I may not have the latest version.
> The first thing is that in
> 
>   A floating result overflows if a finite result value with ordinary
>   accuracy […]
The full quote is

A floating result overflows if a finite result value with ordinary accuracy265) would have magnitude
(absolute value) too large for the representation with full precision in the specified type.
> 
> this does not say how "a floating result" relates to "a finite result
> value with ordinary accuracy”.
“A floating result” refers to a result of a function whose return type is a floating type. “A finite result value with ordinary accuracy” is a hypothetical result value, as indicated by “would have”. What do you think is “wrong”?

- Jim Thomas
> -- 
> Vincent Lefèvre <vincent at vinc17.net <http://mailman.oakapple.net/mailman/listinfo/cfp-interest>> - Web: <https://www.vinc17.net/>
> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
> Previous message (by thread): [Cfp-interest 3309] Re: ERANGE question <http://mailman.oakapple.net/pipermail/cfp-interest/2024-October/003324.html>
> Next message (by thread): [Cfp-interest 3307] JTC1/SC22/WG14/CFP 2024/09/18 Meeting minutes v2 <http://mailman.oakapple.net/pipermail/cfp-interest/2024-October/003322.html>
> Messages sorted by: [ date ] <http://mailman.oakapple.net/pipermail/cfp-interest/2024-October/date.html#3326> [ thread ] <http://mailman.oakapple.net/pipermail/cfp-interest/2024-October/thread.html#3326> [ subject ] <http://mailman.oakapple.net/pipermail/cfp-interest/2024-October/subject.html#3326> [ author ] <http://mailman.oakapple.net/pipermail/cfp-interest/2024-October/author.html#3326>
> More information about the Cfp-interest mailing list <http://mailman.oakapple.net/mailman/listinfo/cfp-interest>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20241014/89b4af97/attachment.htm>