Complex bakeoff - example 1

[Harry H. Cheng]

> > 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. 

Under the complex programming paradigm with a *single* complex infinity,
infinity * 1.0I == infinity * (0+1.0I) == infinity.
value/infinity == ComplexZero is always true.
Therefore, the argument for imaginary type using this particular
example is no longer valid if complex number
is handled under a Riemann-sphere model.

> 
>  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.

The above two arguments depend on how you view the issue.
A language with three additional data types of imaginary type
is conceptually less cleaner. In addition, it contradicts the
model used in FORTRAN. 
Three additional type systems will significantly
degrade the performance of implementation. 

> 
>  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?

The complexity is great for an interpretive implementation with
a single pass. It more than doubles the existing support for complex.

The bottom line is that the undue complexity
does not solve any problem.


Harry Cheng
UC Davis