Remove complex and imaginary types?

[Don Clugston]

Pablo Ripolles wrote:
> Walter Bright Wrote:
> 
>> The issue comes up now and then about why have complex and imaginary 
>> types, rather than using structs? All but one of the advantages of 
>> having them be core types can be addressed with advancing compiler 
>> technology. Getting rid of them will release 6 keywords, and make the 
>> core language simpler. Given the increasing complexity of D, this will help.
>>
>> The remaining advantage is that of imaginary literals, i.e. the i postfix:
>>
>> 	3 + 5i
>>
>> Assuming we solve the literal problem, existing code would only need to add:
>>
>> 	import std.complex;
>>
>> to acquire complex and imaginary types.
> 
> Hello all,
> 
> although perhaps a bit late the following are my points of view.
> 
> * Presumably D has a very interesting future in numerics.  As you clearly state in the Foreword of the recently published 'Learn to Tango with D', there is a gaping hole.  An moreover the need for performance and flexibility.  Definitely, D is a much better way to tackle the increasing complexity of the next coming numerical projects.
> 
> * There is no numerics in D without scientists and engineers programming it in D.  In this numerical programming field, as in many other aspects of life, there is the classic approach and the more vanguardist one.  In the classic and conservative branch people use the good old Fortran, perhaps recycled into Fortran95: "runs fast, it's easy to learn and we know it well".  In the more vanguardist and progressive branch people use the hardcore C++: "here is where the real power is", perhaps a mixture of Python and Fortran.  Probably formal education tends to be much less interdisciplinary than many of us wish it would be... The people from engineering dedicated to numerics know their fluid dynamics quite well, but in general the C++ not that well.  The people from informatics dedicated to numerics know their C++ quite well, but in general the fluid dynamics not that well.  All this is quite reasonable... both worlds are overly complex! fluid dynamics is the task, the programm
ing language is the tool, whose complexity can we reduce? probably both...  Among other things this invites us to design a better programming language.  Fortran people that are doing mix programming such as Python-Fortran will migrate to D, however the rest of the Fortran programmers might have prejudices...  simplistic judgements are not uncommon: "How come D is supposed to be the promised land without the complex intrinsic (core) type?", "That's a step backwards!", "What about standardization? " these have been classic arguments from Fortran programmers against C++ in numerics.  The same goes for the intrinsic (core) array syntax introduced in Fortran90.  So in this context, although standardization might be a weak argument it has been used strongly.
> 
> * As Don said, game programmers might wonder why complex deserve to be in the core language and not quaternions.  I agree, however that reasoning is due to the biased criterion of a game programmer.  I would dare to say that the reasons why complex numbers are studied in any basic course of mathematics (along with integers and real numbers) and not the quaternions are the same as why they might be a better candidate to be in the core language.

Yes, my comment wasn't really fair. Complex numbers are fundamental to 
mathematics in a way that quaternions are not.

But, imagine if quaternions were included, and treated in the same way as 
cdouble/idouble.
We'd need quaternions, imaginary, complex, real, root_i, i*root_i, 
(root_i+imaginary),  (root_i+i*root_i), (imaginary+i*root_i), 
(root_i+imaginary+i*root_i).
(real +root_i+imaginary),  (real +root_i+i*root_i), (real + imaginary+i*root_i).

That's 12 types * { float, double, real} = 36 types!
It's just not a viable approach.

> * Again as Don said, the set of imaginary numbers has no practical use in mathematics.  As Bill mentioned there is no set of the imaginary numbers defined in mathematics.  Why should it be in a programming language? This would definitely strike a numerical analyst very weird!  I think that if the type of complex numbers is in the core language it should respect the mathematical foundations, so why do we need the set of imaginary numbers? that definitely needs a redesign!

Imaginary numbers were included in D because they are in C99. Why are they in C99?
It's because of a really obscure situation.
(a.re + a.im * 1i)*(0.0 + b.im * 1i)
is not the same as (a.re + a.im * 1i)*(b.im * 1i)

if a.im or a.re is infinity. In the version where b.re is 0.0, a NaN is created, 
instead of the correct answer of 0.
Ultimately this happens because 0.0 can mean either exactly 0, or 'too small to 
represent' (an underflow).

As far as I can tell, D can avoid the need for a pure imaginary type, because *D 
guarantees constant folding, whereas C does not*. If constant folding is 
guaranteed, then with any compile-time complex constant, you know if it is a 
zero, or just an underflow. The problematic multiply-by-approximately zero can 
be eliminated -- it is known that it is a multiply-by-exactly zero. So we don't 
need the C99 hack of creating an entirely different type.

> * Complex numbers are very useful in numerics.  They may be used in many situations as if they were reals.  They may reduce differential operations to algebraic ones: solving a linear set of differential equations in the real field reduces to solving a linear set of algebraic equations in the complex field.  This is just to mention a few...  I am not claiming this is an argument for complex numbers to be in the core language as long as performance holds the same.
> 
> Well, i think that is about all i wanted to say...
> 
> Cheers!