Implement loading and dumping of complex64 and complex128 dtypes

[axelhzf]

Implements support for loading and dumping complex64 (c8) and complex128 (c16)

• complex64 (c8) uses Float32Array.
• complex128 (c16) uses Float64Array.

Complex numbers are represented as interleaved real and imaginary parts: [real0, imag0, real1, imag1, ...].

Since complex types cannot be inferred from plain number arrays, I added a dtype option to the dump method

[j6k4m8]

This is great! I have to small questions for you —

• What are your thoughts on interleaved vs nested arrays, i.e., a 1D array of [float, float], [float, float]?
• It looks like the 100x100x100 is all in the u8 range, and is rather large — considering that tests are passing with it here, would you be amenable to taking it out of this PR to keep the repo size down?

[j6k4m8]

PS — thank you @axelhzf SO MUCH for this contribution, I'm grateful for your help and I'm glad we can expand support for this library!!!

[axelhzf]

What are your thoughts on interleaved vs nested arrays, i.e., a 1D array of [float, float], [float, float]?

Using an interleaved representation has the benefit that it is allocated as a contiguous memory block. It also integrates better with typed arrays.

Having a nested array representation adds an extra level of indirection for every access, and the allocation is non-contiguous.

It looks like the 100x100x100 is all in the u8 range, and is rather large — considering that tests are passing with it here, would you be amenable to taking it out of this PR to keep the repo size down?

Removed

[j6k4m8]

Using an interleaved representation has the benefit that it is allocated as a contiguous memory block. It also integrates better with typed arrays.

great points, agreed! thank you :)

[j6k4m8]

Now in ≥ v1.1.0 on npm :)

[axelhzf]

Awesome, thank you @j6k4m8 !