BODY { font-family:Arial, Helvetica, sans-serif;font-size:12px; }Re:
"What I meant to ask was if any implementations have infinity in
double but not float, or in long double but not double.
"IBM's CELL had a PPE processor and 8 SPE processors.
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.
Here's what
https://web.archive.org/web/20150830002041/http://www.realworldtech.com/cell/
[1] says: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. The PPE processor was fully PowerPC
compatible with IEEE compliant floating-point.
- Ian
On Mon 21/10/11 1:36 PM , Jim Thomas jaswthomas at sbcglobal.net sent:
> On Oct 11, 2021, at 7:01 AM, Vincent Lefevre wrote:
>
> On 2021-10-10 17:06:54 -0700, Jim Thomas wrote:
>> It is allowed for a wider standard floating type to have infinity
>> (or NaN) but not a narrower type. C doesn’t have infinity and
NaN
>> macros for that. Is this an issue for some implementation?
>
> Programs that use INFINITY with double would be incorrect with
such
> hypothetical implementations.
Right. What I meant to ask was if any implementations have infinity
in double but not float, or in long double but not double..
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.
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.
- Jim Thomas
> For instance, cairo does that in src/cairo-default-context.c:
>
> static cairo_status_t
> _cairo_default_context_clip_extents (void *abstract_cr,
> double *x1, double *y1, double
*x2, double *y2)
> {
> cairo_default_context_t *cr = abstract_cr;
>
> if (! _cairo_gstate_clip_extents (cr->gstate, x1, y1, x2, y2))
{
> *x1 = -INFINITY;
> *y1 = -INFINITY;
> *x2 = +INFINITY;
> *y2 = +INFINITY;
> }
>
> return CAIRO_STATUS_SUCCESS;
> }
>
> BTW, cairo already assumes that INFINITY is not necessarily
defined:
>
> #if !defined(INFINITY)
> #define INFINITY HUGE_VAL
> #endif
>
> (thus among the C implementations with no float infinity, it would
> behave better when INFINITY is not defined than when it is
defined).
> Said otherwise, a change of the standard would be a benefit for
> software like cairo.
>
> --
> Vincent Lefèvre - Web:
> 100% accessible validated (X)HTML - Blog:
> Work: CR INRIA - computer arithmetic / AriC project (LIP,
ENS-Lyon)
> _______________________________________________
> Cfp-interest mailing list
> Cfp-interest at oakapple.net [4]
> http://mailman.oakapple.net/mailman/listinfo/cfp-interest
_______________________________________________
Cfp-interest mailing list
Cfp-interest at oakapple.net [5]
http://mailman.oakapple.net/mailman/listinfo/cfp-interest
Links:
------
[1] http://www.realworldtech.com/cell/
[2]
http://webmail.primus.ca/javascript:top.opencompose(\'vincent at vinc17.net\',\'\',\'\',\'\')
[3]
http://webmail.primus.ca/javascript:top.opencompose(\'vincent at vinc17.net\',\'\',\'\',\'\')
[4]
http://webmail.primus.ca/javascript:top.opencompose(\'Cfp-interest at oakapple.net\',\'\',\'\',\'\')
[5]
http://webmail.primus.ca/javascript:top.opencompose(\'Cfp-interest at oakapple.net\',\'\',\'\',\'\')
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20211011/4934e1b5/attachment.htm>