Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!husc6!seismo!rochester!kodak!grodberg
From: grodberg@kodak.UUCP
Newsgroups: comp.lang.c
Subject: Re: C and Floating Point
Message-ID: <788@kodak.UUCP>
Date: Tue, 7-Apr-87 15:51:59 EST
Article-I.D.: kodak.788
Posted: Tue Apr  7 15:51:59 1987
Date-Received: Fri, 10-Apr-87 03:08:36 EST
References: <15958@sun.uucp> <5716@brl-smoke.ARPA> <14680@cca.CCA.COM> <790@xanth.UUCP>
Reply-To: grodberg@kodak.UUCP (Jeremy Grodberg)
Followup-To: comp.lang.c
Organization: Eastman Kodak Co, Rochester, NY
Lines: 54
Keywords: C Fortran Floating Point Parenthases
Summary: Then what ARE parenthases for?

In article <790@xanth.UUCP> kent@xanth.UUCP (Kent Paul Dolan) writes:
>In FORTRAN, since that seems to be the counterexample language used in these
>discussions, if I write an expression, and parenthesize it, I have only one
>possible evaluation order to debug; that is the one I have written.  If I
>write the equivalent expression in C, I have to consider (if I'm working in
>a _really_ critical application, model and validate), _every_possible_ order
>of evaluation.  Guess which takes longer.  ;-)....
>
>   Within reason, the speed of compiled code is a _very_minor_ cost factor 
>in the code's life cycle cost, compared to the people costs of creating the 
>code....   It is not a _minor_
>matter when a piece of code doesn't execute the way it reads, and it is not
>a _minor_ matter when someting like the proposed unary plus override on
>parenthesis evaluation order is added to a language.  It is a utility
>destroying set of blunders by the language designers.


   I must very forcefully agree with Mr Dolan.  I have written a lot of code
which necessarily works at the limit of numerical representation on the
machine I am working on.  I must be able to specify the order of evaluation
of expressions so that intermediate values do not overflow, underflow or
otherwise bomb.  On many compilers, this is what parenthases mean.  I don't
know of any compilers which now support the unary +, and it will be very
long before writing code that compiles on an ANSI standard compiler is
considered writing portable code.  To me this means that I will have to add 
plusses to a lot of my expressions when shifting to an ANSI compiler.

    I also don't believe that people put parenthases in their code with the
understanding that it won't have any effect on the order of evaluation.  
One of the reasons I put parenthases in my #defines is so that I can be sure
that that will be evaluated before anything around it. 

    In other words:
    1) Current compilers don't support unary +, so adding it will break most
       (all?) current compilers.
    2) *People* expect parenthases to be honored, and will be confused when
       bugs occur because they are not.
    3) Existing code does not depend on the compiler figuring out that the
       way the expression is parenthasized is not the right way to calculate
       the expression in order to achieve the correct value.  
    4) The time saved in evaluation is not worth all these hassles.

     To satisfy the time critical applications, I would recommend either
a compile time command line option such as -Oe (optimize expressions) or
a reserved word #define, such as #define OPT_EXPR (which could also be
specified on the compiler line).  The latter would provide for code
transportability between standard and non-standard compilers, as well as a way
to compile old code on new compilers.

-- 
          Jeremy Grodberg

Usenet: ...rochester!kodak!grodberg
Arpa: 	grodberg@kodak or kodak!grodberg@rochester