std.complex

[Joseph Rushton Wakeling]

On 03/01/14 14:32, Stewart Gordon wrote:
> I wasn't asking for it to go beyond the existing complex implementation or any
> other.  I was proposing that the arbitrary restriction be removed so that the
> implementation we already have would work on them.

Yes, but it isn't an arbitrary restriction.  Template constraints are 
fundamentally a promise to users about what can be expected to work.  Integral 
types, or library types, won't work without significant modifications to the 
internals of the code.  It would be a false promise to relax those constraints.

> FPTemporary is a template.  At the moment it's defined only for the built-in
> floating point types.  So what we really need is to define FPTemporary for other
> types.  For int and smaller integral types, we can define it as real just as we
> do for float/double/real.  Whether it's adequate for long would be
> platform-dependent.  For other types, I suppose we can reference a property of
> the type, or just use the type itself if such a property isn't present.
>
> One possible idea (untested):
> -----
> template FPTemporary(F)
>          if (is(typeof(-F.init + F.init * F.init - F.init))) {
>      static if (isFloatingPoint!F || isIntegral!F) {
>          alias real FPTemporary;
>      } else static if (is(F.FPTemporary)) {
>          alias F.FPTemporary FPTemporary;
>      } else {
>          alias F FPTemporary;
>      }
> }
> -----

Yes, it ought to be possible to redefine FPTemporary (or define an alternative) 
to determine proper internal temporaries for any "float-esque" case.  I was 
toying with something along the lines of,

     template FPTemporary(F)
         if (isNumeric!F || isFloatLike!F)
     {
         alias typeof(real.init * F.init) FPTemporary;
     }

... where isFloatLike would test for appropriate floating-point-like properties 
of F -- although this is probably far too simplistic.  E.g. how do you handle 
the case of a float-like library type implemented as a class, not a struct?

In any case, absent an appropriate test-case in Phobos, it would be premature to 
generalize the constraints for Complex or the design of FPTemporary.

> Oh yes, and it would be crazy to try and make it work for unsigned integer
> types.  But even if we were to resolve the issues with FPTemporary and that, it
> would still fall under my earlier suggestion of making it so that if people want
> to use Complex on an unsupported type then they can explicitly suppress the type
> restriction, but should understand that it might not work properly.

People who want to use Complex on an unsupported type can quite readily 
copy-paste the code and remove the constraints, if that's what they want to do. 
  I think that's better than giving them an option which is essentially an 
invitation to shoot themselves in the foot, and which has very little chance of 
actually working.

It doesn't matter if you document it as "This might not work", by providing the 
option you are still essentially saying, "This is an OK way to use the type."

I think that's essentially an encouragement of bad code and a violation of the 
design principle that the easy thing to do should be the right thing to do.

> Really, I was just thinking that somebody who wants a quick-and-dirty
> hypercomplex number implementation for some app might try to do it that way.

I understand that, but quick-and-dirty solutions are often bad ones, and in this 
case, it just wouldn't work given the internals of Complex.

If you would like to revise std.complex to support this approach, I'm sure your 
pull request will be considered carefully, but personally I don't see it as an 
effective way to pursue hypercomplex number support when there are other options 
on the table.