Fixing the imaginary/complex mess
Georg Wrede
georg.wrede at iki.fi
Thu Apr 30 22:16:31 PDT 2009
Don wrote:
> Georg Wrede wrote:
>> Don wrote:
>>> D currently allows some conversions between complex/imaginary types
>>> and real types, which are highly dubious.
>>>
>>> Given creal z, ireal y, these casts are legal:
>>> real x = cast(real)z;
>>> x = cast(real)y; // always sets x==0, regardless of the value of y.
>>> But I believe that should not be legal.
>>>
>>> For the first case, it should be written as: real x = z.re;
>>> (which is shorter and clearer), and the second case is probably a
>>> bug, and should be x = y.im; (unless the intention really was to set
>>> x=0!).
>>>
>>> By the same logic, we could have sqrt(-1)==0, since the real part is 0.
>>>
>>> The most important effect of disallowing these casts would be to fix
>>> a host of bugs and wierd behaviour. All the A op= B operations
>>> involve a cast to A. If those nonsensical casts become illegal, the
>>> nonsensical op= operations become illegal automatically.
>>>
>>> Eg, ireal y;
>>> y *= y; // mathematically nonsense, y*y is real, so can't be stored
>>> in a pure imaginary type!
>>>
>>> There are a few segfault/ICE bugs (eg 718, 2839) which involve
>>> int/=complex, an operation which never makes any sense anyway.
>>>
>>> I think we're just making problems for ourselves by allowing these
>>> useless operations. I think they should be killed.
>>> Does anyone object? (If not, I'll create a patch to do it; it's not
>>> very difficult).
>>
>> It might be a good idea to write in the docs why these operations are
>> missing. Even better would of course be if the user got a message
>> stating that this operation isn't implemented because it doesn't make
>> mathematical sense.
>
> I'll make sure the error messages are sensible.
>
>> If the latter isn't done, then many people will just think there's
>> something wrong with the compiler/language. Bad press we don't need.
>
> I don't think anyone expects to be able to divide an integer by an
> imaginary, and then assign it to an integer. I was astonished that the
> compiler accepted it.
Just goes to show you the average math knowledge. I never would have
thought of omitting it either. :-)
More information about the Digitalmars-d
mailing list