Path: csiph.com!news.mixmin.net!eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.lang.c Subject: Re: bart again (UCX64) Date: Sun, 01 Oct 2023 11:03:33 -0700 Organization: A noiseless patient Spider Lines: 83 Message-ID: <86a5t2dxu2.fsf@linuxsc.com> References: <1262755563@f172.n1.z21.fsxnet> <678354ed-d89c-4d45-adfd-1ded3d22eecan@googlegroups.com> <87ttrzo1zm.fsf@bsb.me.uk> <5e098055-c3bd-4f9c-984c-b4fdaf610adbn@googlegroups.com> <647ac7a4-fb14-4072-b65f-5b20290a4b7bn@googlegroups.com> <1ad9d75b-48bb-4b3a-93f0-92900479280en@googlegroups.com> <60jMM.5116$quJ8.2754@fx18.iad> <861qevmfym.fsf@linuxsc.com> <87edivkyfu.fsf@nosuchdomain.example.com> <86zg1gjlf5.fsf@linuxsc.com> <87il84158n.fsf@nosuchdomain.example.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: dont-email.me; posting-host="5df80bfa77615176987b6091c1d3373e"; logging-data="2562712"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18R0miaQrjkLRypyI8BWLS71P8qh6vRJi8=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:/PtY6vDKAvU43GLH6k+2e+AB6fU= sha1:7biggMmY1+J8zz510vJxbfgRGGA= Xref: csiph.com comp.lang.c:176878 Keith Thompson writes: > Tim Rentsch writes: > >> Keith Thompson writes: >> >>> Tim Rentsch writes: >>> >>>> scott@slp53.sl.home (Scott Lurndal) writes: >>>> >>>>> NaN is a term of art referring specifically to the IEEE >>>>> floating point standard. I've never seen "NaN" used in any >>>>> other context (albeit some use it to refer to their grandmother :-). >>>> >>>> The C standard uses (and also defines) the word NaN as a generic >>>> term applicable to floating-point representations in general. In >>>> section 5.2.4.2.2 paragraph 3, the C standard says this >>>> >>>> A /NaN/ is an encoding signifying Not-a-Number. >>>> >>>> with the slant characters meaning italics, which indicates a >>>> definition. The same paragraph gives generic definitions for >>>> the more specialized terms "quiet NaN" and "signaling NaN". >>>> >>>> There is a footnote that mentions the IEEE floating-point >>>> standard, but makes clear that terms for the various kinds of NaN >>>> can refer to values in other floating-point systems that have >>>> similar behavior. >>> >>> Agreed, the C standard is careful not to assume that floating-point >>> systems other than IEEE do or do not have NaNs. >>> >>> In the real world, as far as I can tell, IEEE happens to be the >>> only floating-point system that has NaNs. >> >> That question is best left to a different newsgroup. In any >> case it makes no difference to my statement, which is only >> about how the term NaN is used. > > You'll note that I started by saying I agreed with you. > > I'd say that since the C standard has a lot to say about floating-point, > including NaNs and optional support for IEEE (IEC 60559) floating-point, > it's a relevant issue. I don't know what it is you think your comments are relevant to. I don't see how they are relevant to what I said in my earlier posting. >>> IEEE introduced NaNs >>> in 1985, and the introduction of the IEEE standard inhibited the >>> creation of other floating-point formats. (That's not *quite* >>> true; apparently at least some implementations of "posits" provide >>> NaNs. But I don't think any C implementation uses posits as its >>> floating-point representation, and it might not be possible for a >>> conforming implementation to do so.) >> >> A surprising statement. What is it about posits that make >> them impossible for a conforming C implementation? TTBOMK >> the C standard allows nearly unlimited latitude for how >> floating-point numbers and operations work in C. For the >> record I know very little about posits. > > Posits, as I understand them, have a dynamically varying number of > exponent bits. That seems inconsistent with the floating point model > described in N1570 5.2.4.2.2 (). The model you mention is used to define "the characteristics of floating types", where "characteristics" is understood to be the preprocessor-symbol numerical limits defined in that section. There is nothing in the C standard that requires the representation of floating types to match the description outlined in model, or to "be consistent" with it. There is a footnote in the first paragraph of 5.2.4.2.2; it says The floating-point model is intended to clarify the description of each floating-point characteristic and does not require the floating-point arithmetic of the implementation to be identical. So I still don't know why you think a conforming C implementation couldn't use posits, or some other similar scheme where the number of significand bits varies depending on the exponent, as its representation for floating types.