[RFC]: add `blas/base/zswap`

[performant23]

Description

This RFC proposes adding the package @stdlib/blas/base/zswap for interchanging two complex double-precision floating-point vectors.

void c_zswap( const int N, void *X, const int strideX, void *Y, const int strideY )

Related Issues

Related issues: #2039

Questions

No.

Other

No.

Checklist

• I have read and understood the Code of Conduct.
• Searched for existing issues and pull requests.
• The issue name begins with RFC:.

[performant23]

Hi, just had a quick question: For double-precision floating point vectors, in my implementation I represented them as treating complex numbers as pairs of double values (using 2 double variables to store imaginary and real parts of complex number during a swap) but I also found out that there is a double_Complex data type which is a built-in C99 complex data type. If we use that, we'd just need one variable to store the complex number during the swap and the compiler will handle real and imaginary parts (with the restraint that it would work with compilers supporting C99 and above).

So, how should we be representing double-precision complex numbers?

cc @kgryte

[kgryte]

Treat as pairs of real-valued double-precision floating-point numbers. No reason in this case to include an additional header file.

On a more general note, we don't directly use the built-in C99 complex dtypes in stdlib, but use our own C complex dtypes.

[performant23]

Got it, thanks @kgryte! Also, are there any workarounds/guide for memory management using doubles. For example in benchmark/c, using something like:

double x[ len*2 ];
double y[ len*2 ];

resulted in stack overflow on testing:

c::zswap:len=100000
make[1]: *** [Makefile:116: run] Error -1073741571

since we're using len to determine size of x and y and that can go until 10^6 (also double here is consuming twice as more memory compared to float).

A solution I thought can work is allocation using heaps instead of stacks i.e.

double *x = (double *) malloc(len*2 * sizeof(double));
double *y = (double *) malloc(len*2 * sizeof(double));
.
.
.
free(x);
free(y);

[kgryte]

@performant23 See #369 for a quick workaround. Yes, in the longer term, we need to refactor memory allocation of arrays. In the short term, try adjusting ulimit.

[kgryte]

If that doesn't work, feel free to do manual memory allocation and freeing.

[performant23]

Got it! Will do!