std.complex

[Joseph Rushton Wakeling]

On 02/01/14 23:26, Lars T. Kyllingstad wrote:
> 2. Special-case Complex for imaginary numbers. The pros are that it solves the
> problems Imaginary was intended to solve, and we don't need a new type. The cons
> are that the Complex implementation becomes more complex (haha) and less
> performant, and that we actually change the semantics of IEEE floating-point
> "zero" somewhat.

Well, what I was mulling over was a Complex type that consists of two FP values 
(re and im) and two bools (let's call them hasRe, hasIm).

The point of this is that if you assign to Complex from a regular real-valued 
number, then the value of re gets set, im gets set to zero, hasRe to true, and 
hasIm to false.  So, you have a flag inside that says, "Hey, only worry about 
your real part."

Then you could define an imaginary() helper function that creates a Complex 
number with re = 0.0, im set to whatever it needs to be, hasRe to false, and 
hasIm to true.  So again, you can benefit from a Complex that _knows_ it's 
purely imaginary.

Moreover, it should be possible to preserve that kind of knowledge under certain 
operations.  e.g. if you multiply two Complex numbers which both have hasRe == 
false, you can _know_ that you're going to wind up with a number where hasRe == 
true and hasIm == false.

OTOH when you perform certain other operations, you might end up with a zero re 
or im, but also with hasRe or hasIm to true, which basically reflects your 
_certainty_ that the real or imaginary part is zero.

It might be interesting to try out, and it seems nicer to me than if ()'s based 
on whether re == 0 or im == 0, but on the other hand it enlarges the size of a 
Complex type and will result in a performance hit, and will break compatibility 
with C/C++ Complex types.

> They all suck. I don't know what is the lesser of three evils here, but I too am
> starting to lean towards 1.  I'm probably going to continue playing devil's
> advocate, though. ;)

Please do.  It's fun, and it also helps to improve things. :-)

>>    * You can do calculations involving purely real-valued numbers and complex
>>      numbers and not run into the same issues, because purely real values are
>>      supported. So you should be able to do the same with purely imaginary
>>      numbers.
>
> That argument is fallacious. Imaginary numbers are quite different from real
> numbers.

Can you expand on that?

> I think it's great that you're doing this. :)

Thank you! :-)