<HTML>
<div><style> BODY { font-family:Arial, Helvetica, sans-serif;font-size:12px; }</style>Re: "What I meant to ask was if any implementations have infinity in double but not float, or in long double but not double.</div><div><br>
</div><div><br>
</div><div>"IBM's CELL had a PPE processor and 8 SPE processors.</div><div><br>
</div><div>The SPE processors had fully compliant IEEE double precision, but single precision deviated in a number of ways including no subnormals (flush to zero) and rounding deviations. I haven't found anything about single precision infinities, but I don't think they existed. The SP performance was approximately 10x the DP.<br>
</div><div><br>
</div><div>Here's what https://web.archive.org/web/20150830002041/<a href="http://www.realworldtech.com/cell/ ">http://www.realworldtech.com/cell/ </a> says:</div><blockquote><div>As described previously, the prototype CELL processor’s claim to fame is
its ability to sustain a high throughput rate of floating point
operations. The peak rating of 256 GFlops for the prototype CELL
processor is unmatched by any other device announced to date. However,
the SPE’s are designed for speed rather than accuracy, and the 8
floating point operations per cycle are single precision (SP)
operations. Moreover, these SP operations are not fully IEEE754
compliant in terms of rounding modes. In particular, the SP FPU in the
SPE rounds to zero. In this manner, the CELL processor reveals its roots
in Sony’s Emotion Engine. Similar to the Emotion Engine, the SPE’s
single precision FPU also eschewed rounding mode trivialities for speed.
Unlike the Emotion Engine, the SPE contains a double precision (DP)
unit. According to IBM, the SPE’s double precision unit is fully IEEE854
compliant. This improvement represents a significant capability, as it
allows the SPE to handle applications that require DP arithmetic, which
was not possible for the Emotion Engine.
</div></blockquote><div>The PPE processor was fully PowerPC compatible with IEEE compliant floating-point.</div><div><br>
</div><div> - Ian<br>
</div> <br>
<br>
<span style="font-weight: bold;">On Mon 21/10/11 1:36 PM , Jim Thomas jaswthomas@sbcglobal.net sent:<br>
</span><blockquote style="BORDER-LEFT: #F5F5F5 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px"><br>
<br>
<span style="color: red;">> On Oct 11, 2021, at 7:01 AM, Vincent Lefevre <<a href="javascript:top.opencompose('vincent@vinc17.net','','','')">vincent@vinc17.net</a>> wrote:</span><br>
<span style="color: red;">> </span><br>
<span style="color: red;">> On 2021-10-10 17:06:54 -0700, Jim Thomas wrote:</span><br>
<span style="color: red;">>> It is allowed for a wider standard floating type to have infinity</span><br>
<span style="color: red;">>> (or NaN) but not a narrower type. C doesn’t have infinity and NaN</span><br>
<span style="color: red;">>> macros for that. Is this an issue for some implementation?</span><br>
<span style="color: red;">> </span><br>
<span style="color: red;">> Programs that use INFINITY with double would be incorrect with such</span><br>
<span style="color: red;">> hypothetical implementations.</span><br>
<br>
Right. What I meant to ask was if any implementations have infinity in double but not float, or in long double but not double..<br>
<br>
For the example below, where apparently HUGE_VAL would be acceptable, the code could have just used HUGE_VAL instead of INFINITY. (There are float and long double analogs of double HUGE_VAL.) Annex F requires the HUGE_VAL macros to expand to a positive infinity of the indicated type.<br>
<br>
Requiring INFINITY to be defined if and only if infinity is supported does seem simpler and less error prone. It would be a substantive change, coming late in the process. Breakage resulting from the change would be seen at translation time (which would be better than later). At the CFP meeting this week we can talk about adding that option to our proposal to WG14.<br>
<br>
- Jim Thomas<br>
<br>
<span style="color: red;">> For instance, cairo does that in src/cairo-default-context.c:</span><br>
<span style="color: red;">> </span><br>
<span style="color: red;">> static cairo_status_t</span><br>
<span style="color: red;">> _cairo_default_context_clip_extents (void *abstract_cr,</span><br>
<span style="color: red;">> double *x1, double *y1, double *x2, double *y2)</span><br>
<span style="color: red;">> {</span><br>
<span style="color: red;">> cairo_default_context_t *cr = abstract_cr;</span><br>
<span style="color: red;">> </span><br>
<span style="color: red;">> if (! _cairo_gstate_clip_extents (cr->gstate, x1, y1, x2, y2)) {</span><br>
<span style="color: red;">> *x1 = -INFINITY;</span><br>
<span style="color: red;">> *y1 = -INFINITY;</span><br>
<span style="color: red;">> *x2 = +INFINITY;</span><br>
<span style="color: red;">> *y2 = +INFINITY;</span><br>
<span style="color: red;">> }</span><br>
<span style="color: red;">> </span><br>
<span style="color: red;">> return CAIRO_STATUS_SUCCESS;</span><br>
<span style="color: red;">> }</span><br>
<span style="color: red;">> </span><br>
<span style="color: red;">> BTW, cairo already assumes that INFINITY is not necessarily defined:</span><br>
<span style="color: red;">> </span><br>
<span style="color: red;">> #if !defined(INFINITY)</span><br>
<span style="color: red;">> #define INFINITY HUGE_VAL</span><br>
<span style="color: red;">> #endif</span><br>
<span style="color: red;">> </span><br>
<span style="color: red;">> (thus among the C implementations with no float infinity, it would</span><br>
<span style="color: red;">> behave better when INFINITY is not defined than when it is defined).</span><br>
<span style="color: red;">> Said otherwise, a change of the standard would be a benefit for</span><br>
<span style="color: red;">> software like cairo.</span><br>
<span style="color: red;">> </span><br>
<span style="color: red;">> -- </span><br>
<span style="color: red;">> Vincent Lefèvre <<a href="javascript:top.opencompose('vincent@vinc17.net','','','')">vincent@vinc17.net</a>> - Web: <<a target="_blank" href="parse.php?redirect=https%3A%2F%2Fwww.vinc17.net%2F"><span style="color: red;">https://www.vinc17.net/</span></a>></span><br>
<span style="color: red;">> 100% accessible validated (X)HTML - Blog: <<a target="_blank" href="parse.php?redirect=https%3A%2F%2Fwww.vinc17.net%2Fblog%2F"><span style="color: red;">https://www.vinc17.net/blog/</span></a>></span><br>
<span style="color: red;">> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)</span><br>
<span style="color: red;">> _______________________________________________</span><br>
<span style="color: red;">> Cfp-interest mailing list</span><br>
<span style="color: red;">> <a href="javascript:top.opencompose('Cfp-interest@oakapple.net','','','')">Cfp-interest@oakapple.net</a></span><br>
<span style="color: red;">> <a target="_blank" href="parse.php?redirect=http%3A%2F%2Fmailman.oakapple.net%2Fmailman%2Flistinfo%2Fcfp-interest"><span style="color: red;">http://mailman.oakapple.net/mailman/listinfo/cfp-interest</span></a></span><br>
<br>
<br>
_______________________________________________<br>
Cfp-interest mailing list<br>
<a href="javascript:top.opencompose('Cfp-interest@oakapple.net','','','')">Cfp-interest@oakapple.net</a><br>
<a target="_blank" href="parse.php?redirect=http%3A%2F%2Fmailman.oakapple.net%2Fmailman%2Flistinfo%2Fcfp-interest"><span style="color: red;">http://mailman.oakapple.net/mailman/listinfo/cfp-interest</span></a><br>
<br>
</blockquote><BR></HTML>