eck@cs.vu.nl (Hans van Eck) (11/09/90)
Is it allowed to evaluate constant floating point expressions with greater range and precision than that of the execution environment in contexts where a constant is not required? There are unexpected implications of both allowing and disallowing such folding, but I cannot find a statement in the standard that unambiguously says what a translator may or may not do. -- Hans van Eck, Dept. of Mathematics and Computer Science, Vrije Universiteit, De Boelelaan 1081, 1081 HV Amsterdam, The Netherlands Voice: +31 20 5485302 Email: eck@cs.vu.nl
henry@zoo.toronto.edu (Henry Spencer) (11/14/90)
In article <8191@star.cs.vu.nl> eck@cs.vu.nl (Hans van Eck) writes: >Is it allowed to evaluate constant floating point expressions with greater >range and precision than that of the execution environment in contexts >where a constant is not required? > >There are unexpected implications of both allowing and disallowing such >folding, but I cannot find a statement in the standard that unambiguously >says what a translator may or may not do. I believe the relevant statement is the "as if" rule discussed in 2.1.2.3: the compiler can do anything it pleases, provided the observable results are the same. Observable results include overflow exceptions and the values of data items written out to files. Evaluating constant floating-point expressions at compile time using different floating-point hardware strikes me as a minefield of difficulties. -- "I don't *want* to be normal!" | Henry Spencer at U of Toronto Zoology "Not to worry." | henry@zoo.toronto.edu utzoo!henry
eck@cs.vu.nl (Hans van Eck) (11/14/90)
henry@zoo.toronto.edu (Henry Spencer) writes: >In article <8191@star.cs.vu.nl> eck@cs.vu.nl (Hans van Eck) writes: >>Is it allowed to evaluate constant floating point expressions with greater >>range and precision than that of the execution environment in contexts >>where a constant is not required? >I believe the relevant statement is the "as if" rule discussed in 2.1.2.3: >the compiler can do anything it pleases, provided the observable results >are the same. Observable results include overflow exceptions and the values >of data items written out to files. Evaluating constant floating-point >expressions at compile time using different floating-point hardware strikes >me as a minefield of difficulties. The problem is that the standard (in 3.4) explicitely allows greater range and precision for floating point expressions when a constant is required, which seems to take higher precedence than the "as if" rule. What I do not know is whether this rule may also be applied when a constant is not required. Perhaps a simple example is in place: { static double d = 0.3F; double e = 0.3F; In this example, d may may be initialised with a precision higher than that of a float. Does that also hold for e? Thanks in advance. -- Hans van Eck, Dept. of Mathematics and Computer Science, Vrije Universiteit, De Boelelaan 1081, 1081 HV Amsterdam, The Netherlands Voice: +31 20 5485302 Email: eck@cs.vu.nl
lewine@cheshirecat.rtp.dg.com (Donald Lewine) (11/14/90)
In article <1990Nov13.174025.1520@zoo.toronto.edu>, henry@zoo.toronto.edu (Henry Spencer) writes: |> In article <8191@star.cs.vu.nl> eck@cs.vu.nl (Hans van Eck) writes: |> >Is it allowed to evaluate constant floating point expressions with greater |> >range and precision than that of the execution environment in contexts |> >where a constant is not required? |> > |> >There are unexpected implications of both allowing and disallowing such |> >folding, but I cannot find a statement in the standard that unambiguously |> >says what a translator may or may not do. |> |> I believe the relevant statement is the "as if" rule discussed in 2.1.2.3: |> the compiler can do anything it pleases, provided the observable results |> are the same. Observable results include overflow exceptions and the values |> of data items written out to files. Evaluating constant floating-point |> expressions at compile time using different floating-point hardware strikes |> me as a minefield of difficulties. See section 3.1.3 of the rationale: "In folding and converting constants, an implementation must use at least as much precision as is provided by the target environment. However, it is not required to used exactly the precision as the target, since this would require a cross compiler to simulate target arithmetic at translation time." In other words, the "as if" rule does not require getting a bit-for-bit identical result. The "minefield of difficulties" can be safely crossed. -------------------------------------------------------------------- Donald A. Lewine (508) 870-9008 Voice Data General Corporation (508) 366-0750 FAX 4400 Computer Drive. MS D112A Westboro, MA 01580 U.S.A. uucp: uunet!dg!lewine Internet: lewine@cheshirecat.webo.dg.com
henry@zoo.toronto.edu (Henry Spencer) (11/15/90)
In article <8237@star.cs.vu.nl> eck@cs.vu.nl (Hans van Eck) writes: >The problem is that the standard (in 3.4) explicitely allows greater range >and precision for floating point expressions when a constant is required... I don't think 3.4 says quite that; indeed, it explicitly states that the rules for constant expression evaluation are the same as for non-constant expressions. The clause you're referring to says that precision and range *may not be less* than that available at run time. I would interpret that as a clarification and a warning to implementors, not as a change of the rules. -- "I don't *want* to be normal!" | Henry Spencer at U of Toronto Zoology "Not to worry." | henry@zoo.toronto.edu utzoo!henry
jfc@athena.mit.edu (John F Carr) (11/15/90)
In article <1990Nov13.174025.1520@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes: >Observable results include overflow exceptions and the values >of data items written out to files. Overflows of types other than unsigned integers are undefined, so a conforming compiler could rearrange float expressions that would overflow in the target machine's floating point format. The standard allows calculations to be in greater precision than the types involved. In practice, this means if the compiler simplifies floating point expressions involving constants, it must use the target float format, or a format with more bits than the target (both range and precision must be at least as great as the target). -- John Carr (jfc@athena.mit.edu)
bhoughto@cmdnfs.intel.com (Blair P. Houghton) (11/15/90)
In article <1990Nov14.192231.29728@athena.mit.edu> jfc@athena.mit.edu (John F Carr) writes: >In article <1990Nov13.174025.1520@zoo.toronto.edu> > henry@zoo.toronto.edu (Henry Spencer) writes: >>Observable results include overflow exceptions and the values >>of data items written out to files. > >Overflows of types other than unsigned integers are undefined, so a Almost threw me there. The standard defines unsigned integers as being unable to overflow; the excess bits are simply lost and the effect is that of 'result mod 2^n, n = number of bits in an unsigned integer' (cf. ANSI X3.159-1989, sec. 3.1.2.5., p. 24, ll. 5-9). It doesn't _explicitly_ state that overflow for other types is undefined. That comes from the explicit undefinedness of the effect of any exception during expression evaluation (ibid., sec. 3.3, p. 39, ll. 15-7). --Blair "Just wanted to clear that up."