> Am 16.02.2016 um 23:21 schrieb Andreas Kloeckner <[email protected]>: > > Gregor Thalhammer <[email protected]> writes: >> Great, I will try to look into this. At first glance it seems the >> infrastructure for providing a flag is not yet there. Such workarounds >> are device dependent. I am thinking about adding device specific build >> options, similar to _PLAT_BUILD_OPTIONS in pyopencl/__init__.py, which >> defines an macro (e.g. PYOPENCL_COMPLEX_NOSTRUCT) to switch >> definitions in pyopencl-complex.h based on this flag. > > That sounds reasonable. Who or what would activate that flag? (I'm > asking because I'd strongly recommend against some sort of 'magic' or > look-up table to activate it.)
Agree, any magic action is a nightmare to maintain and test. In my case I would just activate the workaround explicitly, assigning to pyopencl._DEVICE_BUILD_OPTIONS after importing. Additionally an environment setting could be used. > >> A drawback of optionally reverting to the old vector-based complex >> types is that the nice .real and .imag attribute access cannot be used >> anymore, instead one has to revert to the .x and .y attributes, or >> introduce macros for attribute access. > > Functions (not macros) for the attribute access already exist: > > cdouble_real(...), cdouble_imag(...) > > Are you ok just using those? These typed functions are ok for using in custom kernels, but in pyopencl-complex.h itself they are not used for attribute access, so the same macro expression can be used to define the complex math functions for both cfloat and cdouble. Thats the reason why I only see the options of reverting to use a.x, a.y or introduce macros (e.g. RE(a), IM(a)) for use in pyopencl-complex.h Gregor _______________________________________________ PyOpenCL mailing list [email protected] https://lists.tiker.net/listinfo/pyopencl
