Is it possible to support complex dtypes on Windows?

[eriknw]

Is there any workaround we could do to make this work? Can we write any custom C code to serve as a bridge between Python and C GraphBLAS?

If anybody needs complex dtypes on Windows or has any information for how we might get it to work, please reply here!

[DrTimothyAldenDavis]

SuiteSparse:GraphBLAS should work with complex data types on Windows. Is this the python-to-C connection that doesn't work?

[eriknw]

Correct, we currently strip out all complex stuff for Windows. I wish we could get this working, since complex works with SuiteSparse:GraphBLAS on all OSes.

I don't think we need anything from you; we'll need to figure it out, or live with this shortcoming. Similarly, I wonder whether wrapping SuiteSparse:GraphBLAS with Cython would work with complex dtypes...

[DrTimothyAldenDavis]

It might be possible to change how I handle my 2 complex types. I could use my own struct, as in

typedef struct { double real ; double imag ; } GxB_FC64_t ;

I already do many of the complex operators myself (see for example https://github.com/DrTimothyAldenDavis/GraphBLAS/blob/0b79097dfba798c158af244eb7323a55adf9cf30/Source/GB_math.h#L25 and following).

[DrTimothyAldenDavis]

For example, I do my own complex division because the compiler-provided versions are mixed in quality. I want to match how MATLAB does it, and they are more careful about Inf and NaN behavior. So I use this:

https://github.com/DrTimothyAldenDavis/GraphBLAS/blob/0b79097dfba798c158af244eb7323a55adf9cf30/Source/GB_math.h#L336

and revised in my master branch as:

https://github.com/DrTimothyAldenDavis/GraphBLAS/blob/031fd110ba9e8c431ee5bb31f5609fc1aee00efa/Source/GB_math.h#L497

If I had an #ifdef'd option to use my own complex type definition, then the GxB_CMPLX(r,i) macro would be

#define GxB_CMPLX(r,i) (GxB_FC64_t) { .real=(r) ; .imag=(i) ; }

because this works:

#include <stdio.h>
#include <stddef.h>
typedef struct { double real ; double imag ; } mycomplex ;
int main (void)
{
    double pi = 3.14 ;
    double one = 1.0 ;
    mycomplex t = (mycomplex) { .real=pi, .imag=one } ;
    printf ("(%g,%g)\n", t.real, t.imag) ;
    #undef creal
    #define creal(x) ((x).real)
    #undef cimag
    #define cimag(x) ((x).imag)
    printf ("(%g,%g)\n", creal (t), cimag (t)) ;
}

If this was an #ifdef'd option, then GxB_FC32_t and GxB_FC64_t would both be typedef'd structs. Can you pass in scalars and arrays of that type?

[DrTimothyAldenDavis]

Downside to this: I would need to write my own complex trig and hyperbolic functions: cacos, cacosf, casin, casinf, catan, catanf, ..., cacosh, ... cpow, cexp, clog, and so many more. That would be very hard to do. I would need to find a set of definitions of these functions that I could use and incorporate into GraphBLAS.

[DrTimothyAldenDavis]

What if instead you pretend on your side that GxB_FC64_t has this typedef:

typedef struct { double real ; double imag ; } GxB_FC64_t ;

and then whereever you need to pass in a C scalar of that type, pass in that struct. Or a C array of that type -- just pass in a pointer to an array of those types.

[eriknw]

What if instead you pretend on your side that GxB_FC64_t has this typedef:

typedef struct { double real ; double imag ; } GxB_FC64_t ;

and then whereever you need to pass in a C scalar of that type, pass in that struct. Or a C array of that type -- just pass in a pointer to an array of those types.

Yeah, we should be able to do that for Windows easily enough. If we tried this, do you think it should work with the latest SuiteSparse:GraphBLAS, or would you need to do something?

[DrTimothyAldenDavis]

I would need to make a 3-line change to GraphBLAS.h.in, and the change would have no effect on anything inside SS:GrB, nor any effect on any other users of GraphBLAS. Here's what I would do:

The 3 lines would be:

#ifndef GXB_COMPLEX_DEFN
#define GXB_COMPLEX_DEFN

... here I place lines 137 to 203 of GraphBLAS.h
but I would remove the definition of GB_restrict (already done in the master branch).

#endif

Then in your C wrapper, you do this:

#define GXB_COMPLEX_DEFN
typedef struct { double real ; double imag ; } GxB_FC64_t ;
typedef struct { float real ; float imag ; } GxB_FC32_t ;
#define GxB_CMPLX(r,i) (GxB_FC64_t) { .real=(r) ; .imag=(i) ; }
#define GxB_CMPLXF(r,i) (GxB_FC32_t) { .real=(r) ; .imag=(i) ; }
#include "GraphBLAS.h"

Then your notion of the two complex types would differ from mine, but they would be compatible at the bit level. Your C wrapper would think they are structs of 2 floats or 2 doubles. All of the GraphBLAS prototypes that you see on your side would use that definition. All of they prototypes GraphBLAS would see internally would be the built-in complex type in Windows, since you would still compile SS:GrB the same, without this preface of #define GXB_COMPLEX_DEFN.

This would be a minor change to GraphBLAS so I could do it as a v7.5.0 version, released any time you like. I'd bump the minor version from v7.4.x to v7.5.0 because it's a new user-visible feature. It would have no effect at all on any other GraphBLAS users, except to add the #define preprocessing token GXB_COMPLEX_DEFN.

Would that work on your side?

[alugowski]

In case this is helpful: here is how pybind11 does individual complex values: https://github.com/pybind/pybind11/blob/master/include/pybind11/complex.h
And their nparray code: https://github.com/pybind/pybind11/blob/master/include/pybind11/numpy.h
I don't see anything windows specific, nor anything weird about complex values.

I can confirm that pybind11 works for me with complex numpy arrays being read and written by a C++ extension, including on Windows.

[alugowski]

Oh, I think I see what's causing the problem. The MSVC command that compiles the Python extensions does not specify a C standard. The MSVC default is something ancient, which does not have complex value support.

I'll submit a PR shortly that will include a /std:c11 switch. Last few days I've gotten cibuildwheel working so that maybe we can get Python GraphBLAS working normally on all platforms. I've added that switch to my changes.

Tim, GraphBLAS/CMakeLists.txt does set the C standard, but in a confusing way. The line that does so is this one:

set_property ( TARGET graphblas PROPERTY C_STANDARD 11 )

(line 293). The confusing bits:

• there is also C_STANDARD_REQUIRED 11 which is not a correct use, since that is an ON/OFF value, not a number. It just says that the value of C_STANDARD is required, and should be set to "ON" not "11". See https://cmake.org/cmake/help/latest/prop_tgt/C_STANDARD_REQUIRED.html.
• The big compiler-specific set of IFs list C-standard switches such as -std=c11, which is redundant given the C_STANDARD property is set. Of course, all except MSVC :)

Also FYI, the preferred way to check for Clang is:

if (CMAKE_CXX_COMPILER_ID MATCHES "Clang")

Notice the MATCHES, not STREQUAL. That way you handle both regular Clang and AppleClang, the default (and often only) compiler on macOS.

[alugowski]

The cibuildwheel PR with /std:c11 is ready: #66

I'll let someone familiar with the complex value issue see if that fixes it or not.

[DrTimothyAldenDavis]

Thanks for the comments. I'll work on fixing those issues in the GraphBLAS/CMakeLists.txt file. It was the first cmake I wrote and you can see it's a bit crufty in a few places -- in particular, the large if-else block for handing different compilers. Some of that can be cleaned up.