> On 7 Nov 2019, at 17:31, Eric Barnhill <ericbarnh...@gmail.com> wrote:
> 
> On Thu, Nov 7, 2019 at 3:59 AM Alex Herbert <alex.d.herb...@gmail.com>
> wrote:
> 
>> 
>> There is a matrix for real/imaginary/complex all-vs-all additive and
>> multiplicative operators in the standard (tables in G.5.1 and G.5.2).
>> The question is do we want to support the entire matrix:
>> 
>> Covered:
>> 
>> Complex.multiplyReal(double x) as  Complex.multiply(double x)
>> Complex.divideReal(double x)   as  Complex.divide(double x)
>> Complex.addReal(double x)      as  Complex.add(double x)
>> Complex.subtractReal(double x) as  Complex.subtract(double x)
>> 
>> Not covered:
>> 
>> Complex.multiplyImaginary(double x)
>> Complex.divideImaginary(double x)
>> Complex.addImaginary(double x)
>> Complex.subtractImaginary(double x)
>> Complex.subtractFromReal(double x)
>> Complex.subtractFromImaginary(double x)
>> 
>> 
>> I am going through Complex now to fix code coverage and make it in line
>> with the C.99 standard. I will push all the config changes with the
>> update to Complex. Should be done be end of today.
> 
> 
> 
> Well that's interesting, I did not see that the standard specified
> all-vs-all methods in all those cases. There isn't a performance gain for
> multiplying by an imaginary double like there is for a real double, as one
> has to deal with imaginary*imaginary, so one might as well just pass a
> Complex rather than an imaginary double. Consequently I would imagine
> implementations of that corner of the standard's matrix are pretty rare.
> But I see no reason not to have it for completeness and continuing the goal
> I set, of being the only non-C library that I've ever seen that fulfills
> the whole standard.
> 
> +1

My changes to the tests for Complex have taken longer than I expected. I will 
continue tomorrow and will push something by the end of tomorrow.

One thing I noted is that although there is coverage of edge cases there is not 
a lot of coverage of the methods using ‘ordinary’ data. Some of the coverage 
comes from methods being used in other methods and not tested directly. I’ll 
fix up the code coverage and then will make an attempt to generate some results 
of complex operations using the GNU C compiler that can be incorporated into 
tests of the individual methods. This will be along the lines of:

void assertOperation(Complex z, UnaryOperator<Complex> op, Complex expected) {
   // Check: expected == op.apply(z)
}

for all the operations on complex data.

I also note that the C.99 standard uses the following definitions of some 
functions using others:

casin(z) = -i casinh(iz)
catan(z) = -i catanh(iz)
ccos(z) = ccosh(iz)
csin(z) = -i csinh(iz)
ctan(z) = -i ctanh(iz)


The code currently was not doing this. It implemented the functions on the left 
directly. This means that all the edge cases in the function on the right (as 
these are tested in the CStandardTest) were missed from the function on the 
left. So for now I have implemented the equalities as defined above and 
commented out the original code.

Multiplication by I and -I is a straightforward real <=> imaginary swap with an 
appropriate sign update. So using the equalities is simple and more 
maintainable as some methods duplicate a lot of the same computation.

Alex






Reply via email to