On Wednesday, 1 January 2014 at 19:55:58 UTC, Joseph Rushton
Wakeling wrote:
On Wednesday, 1 January 2014 at 12:29:35 UTC, Stewart Gordon
wrote:
[...] why do you need an appropriate application in order not
to have this arbitrary restriction? Or have I missed
something?
There are binary operations on complex numbers where the only
sensible outcome seems to be non-integral real and imaginary
parts. Addition, subtraction and multiplication are OK with
integral types, but division really seems unpleasant to
implement absent floating point, exponentiation even more so.
I imagine there are ways to resolve this, but it certainly
simplifies implementation to assume floating-point, and absent
a compelling application there is not much reason to avoid that
simplification.
I agree completely. This is the main reason why I chose to
explicitly disallow integral types when I wrote std.complex.
It isn't just integer types. Somebody might want to use
complex with a library (fixed-point, arbitrary precision,
decimal, etc.) numeric type.
Fractal generators, for example, are likely to use this a lot.
I agree that such any numeric type that effectively models a
real number should be supported. In principle it ought to be
sufficient to check that the required "floating-point-ish"
operations (including sin and cos) are supported, plus maybe
some tweaks to how internal temporary values are handled.
Agreed. Any "floating point-like" library type which is to be
supported by std.complex must either have cos(), sin(), hypot(),
etc. as member functions (since std.complex cannot import non-std
modules), or the type needs to be supported by std.math as well.
If so, std.math is the place to start, not std.complex.
