Thanks for the feedback Alex, > Not a problem. Just write a dedicated method for Complex and a generic > method in ComplexFunctions. This small level of code duplication is > acceptable where the efficiency of the method is greatly improved by > rewriting it, as has been done for the scalar functions.
For proj(), I had to take it out of ComplexFunctions for now to pass the coverage checks, but I have left the original code for proj() in the Complex class. > Why should I have to return a ComplexDouble? Since the ComplexConstructor > is typed it makes more sense to have the methods that use it to also be > typed. These methods should perform an operation that generates a real and > imaginary part. This is passed to the provided constructor. It should be up > to the provider of the constructor (i.e. the caller) to decide what to do > with the result. By typing to ComplexDouble you are removing that > flexibility. > However there is no requirement to specify what R is, allowing it to be > Void. This also decouples the interface from Complex and ComplexDouble. > Note that this may make ComplexDouble obsolete which would simplify the > current changes. > I've not applied this change to your entire current diff so there may be > some issues, for example with the scalar functions. I am interested to see > if this would work. So, I have made all interfaces typed and updated the method signatures accordingly. Please let me know if there are any problems with these changes. As for updating the test suite, I am currently working on that right now and will let you know as soon as I am done. Thanks, Sumanth
