std.complex

[Stewart Gordon]

On 02/01/2014 19:32, Joseph Rushton Wakeling wrote:
> On Thursday, 2 January 2014 at 18:12:56 UTC, Stewart Gordon wrote:
>> Then why not just disable division if it's a non-float type, rather
>> than preventing the whole complex template from being used with that
>> type? This is like cutting off somebody's arm because they have a sore
>> thumb.
>
> Because that also seems to me to be an unpleasant option. A complex
> number implementation that fails to support ordinary arithmetic
> operations in all circumstances is pretty non-intuitive and will
> probably lead to unpleasant bugs in users' code.

The compiler rejecting the code is the most pleasant bug that's possible 
IMO.

>> Moreover, we have no way in the general case of determining whether T
>> is an integral type, a library float-esque type, or (for example) a
>> Galois field type.  So disabling it _just in case_ division doesn't
>> work is crazy.  There must be better ways to do it.
>
> I don't follow your point here. We can constrain T however we see fit.
> The point isn't to have some perfect representation of every
> mathematical possibility, it's to have useful code that serves a good
> range of use-cases while being robust and easy to maintain.

Not being overly restrictive in what types you will allow it to be used 
with is an important part of serving a good range of use cases.

<snip>
>> What do you mean by "in the context of", exactly?  Restricting it to
>> some float-esque type that is in Phobos would still be overly
>> restrictive.
>
> No, I mean that until you have at least one actual float-esque type to
> test with, it is probably unwise to relax the template constraints that
> currently mandate built-in FP types.

I'm sure we have a small handful already.  We just need to find them. 
For instance, given the time I could probably dig up my rational number 
implementation and update it to current D.

>> It would, but removing the restriction would simplify the
>> implementation of Hypercomplex(T) by enabling it to be a wrapper for
>> Complex!(Complex!T).
>
> And complicate the implementation of Complex itself, for the sake of a
> likely very marginal special interest that could be supported quite well
> by an independent type.

How would it complicate the implementation?  Removing the undocumented 
rule whereby Complex!(Complex!T) folds to Complex!T would be a slight 
simplification.

Maybe the right course of action is to have a parameter to the template 
that suppresses the type restriction and the folding rule, so that 
people who want to use it on a type that might not work properly can do 
so.  This would be a relatively small change.

Stewart.