Complex bakeoff - example 1

[Frank Farance]

> Date: Fri, 6 Oct 1995 16:42:24 -0500
> To: frankafarance.com (Frank Farance), numeric-interestavalidgh.com,
>         sc22wg14adkuug.dk
> From: knaakacray.com (David Knaak)
> Subject: (SC22WG14.1750) Complex bakeoff - example 1

David-

 I think we are in agreement on most points, the most
 important one is: infinities (and other exceptional values
 and attributes) are used as placeholders.  Depending upon
 the paradigm, the placeholders may fit the application
 exactly, loosely, or not at all.  Several have pointed out
 that the Cartesian paradigm is most useful.

> I am not in favor of the inclusion of an imaginary type because:
> 1) there really isn't a problem that needs to be solved by it,
> 2) it doesn't solve the problem any way,
> 3) the complexity added by it to the language is too great.

 Our opinions differ with respect to the conclusions.  With
 respect to #1, I think you've identified the problem that is
 solved:  infinity * 1.0I != infinity * (0+1.0I), thus the
 need for an imaginary type.  Without an imaginary type,
 value/infinity == 0 would hold for reals, but not for pure
 imaginaries.  Thus, two different styles of coding would
 need to be developed.  The first style would apply to reals
 -- it would be characterized as conceptually cleaner and
 more efficient.  The second style could apply to reals and
 pure imaginaries, but would be *required* for use with pure
 imaginaries -- it would be chaaracterized as having more
 embedded exception handling and performing poorer.  The
 program design would adapt to one of the following:

         (1) Use fast code for reals, use slow code for pure
         imaginaries.  Advantage: This is the fastest you can
         make the code while still using complex types.
         Disadvantage:  Requiring two different styles is
         highly error prone, expecially in well-tuned numeric
         code.

         (2) Use slow code for both.  Advantage: Fewer
         programming mistakes due to different styles.
         Disadvantage: Additional programming mistakes due to
         loss of conceptual clarity; performance is reduced.

         (3) Use fast code for reals, don't use complex types
         -- use reals (with fast code) for pure imaginary
         values.  Advantage:  This is the fastest you can
         make the code.  Disadvanatage:  Programming mistakes
         because the real and imaginary components of complex
         values are handled separately (loss of ``complex''
         paradigm) rather than handling them within their
         ``nature'' (i.e., within their conceptual paradigm).

 In summary, all of these are error-prone solutions that the
 compiler *could* get right.

 With respect to conclusion #2, I think it does solve the
 problem to the extent that: (1) allows for conceptually
 cleaner code, (2) allows for performance improvements.  In
 other words, that's all the problem is.

 With respect to conclusion #3, you claim that the complexity
 is too great.  The code generation can't be much of a
 problem since it would be generating one quarter to one half
 the code it would have generated for the complex type.  The
 type system and promotion rules shouldn't be much of a
 problem since they are very similar to the existing support
 for complex.  So what is too great?

-FF
--------------------------------------------------------------------
Frank Farance, Farance Inc.   E-mail: frankafarance.com
Telephone: +1 212 486 4700    FAX: +1 212 759 1605
ISO JTC1/SC22/WG14 & ANSI X3J11 (C Programming Language) Project Editor