inducer / compyte Goto Github PK

surban/Theano@0e870a1

This was causing problem on Windows I think.

Is this library deprecated in favor of libgpuarray?

First version, copy Theano reshape

2e version optimize it by not always coping when not contiguous when the strides/shapes allow it.

To don't use this field by mistake in old code that don't support strides.

We need PyCUDA/PyOpenCL to try to use the .bytes fields when we ask him to do so.

Move all dependency to Theano fil scalar/basic.py and copy this file here.

Mark clearly that this file is under BSD 3 clauses

There is 42 of them:
char1, uchar1, char2, uchar2, char3, uchar3,
char4, uchar4, short1, ushort1, short2, ushort2,
short3, ushort3, short4, ushort4, int1, uint1, int2,
uint2, int3, uint3, int4, uint4, long1, ulong1,
long2, ulong2, long3, ulong3, long4, ulong4,
longlong1, ulonglong1, longlong2, ulonglong2,
float1, float2, float3, float4, double1, double2

There is 2 way to implement them: add basic typenum as for other basic dtype or use a system like numpy composite dtype. I'm not sure what is best.

In the commit 2293b43 a test for numpy.lib.stride_tricks.as_strided() was added in array.py checking that it preserves a structured dtype. It works for the rather simple type there, but stops working for types with padding set through offsets parameter:

import numpy
from numpy.lib.stride_tricks import as_strided

dtype = numpy.dtype({
    'names':['i1','nested','i2'],
    'formats':['<u4',[('v', '<u8')],'<u4'],
    'offsets':[0,8,16], 'itemsize':24})

arr = numpy.zeros((128,), dtype)

print(dtype)
print(new_arr.dtype)

Output:

{'names':['i1','nested','i2'], 'formats':['<u4',[('v', '<u8')],'<u4'], 'offsets':[0,8,16], 'itemsize':24}
[('i1', '<u4'), ('f1', 'V4'), ('nested', [('v', '<u8')]), ('i2', '<u4'), ('f4', 'V4')]

Apparently, as_strided() adds some dummy fields in this case and removes offsets. The alternative version of as_strided() in array.py does preserve them, but since the numpy one passes the test, it does not get invoked.

Is it the planned behavior?

We could use PyOpenCL w

http://documen.tician.de/pyopencl/array.html#complex-numbers

In addition, I've added a rudimentary facility for translating Fortran
kernels to OpenCL, see here:

https://github.com/inducer/pyopencl/tree/master/contrib/fortran-to-opencl

As pointed out by @seberg in #36 (comment).

Copy/adapt the theano code for dimshuffles.

This include:

• restructure the code to localize to 1 file the dependency on python.
• make the c function names follow the convention
• check and tests all functions and put it in comments that it handle correctly
  • flags({c,f}_contiguous, owndata, align, writable, updateifcopy)
  • offset
  • descr(dype, elemsize)
  • compound dtype

If we add 3 tensor and 2 of them are c contiguous but not the last, it seam wasteful to compute the index 2 times for each c contiguous array.

This is needed for OpenCL (since the current code does something really hacky).

Also might help support multiple CUDA contexts.

I'm not sure how much difference it makes in practice, but the char type in C/C++ isn't guaranteed to be signed or unsigned.

By default, x86/M1 seem to treat char as signed, but ppc64le treats it as unsigned. This can also be modified by compiler options (e.g., https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/C-Dialect-Options.html#index-funsigned-char).

OpenCL seems to define it as signed: https://registry.khronos.org/OpenCL/specs/3.0-unified/html/OpenCL_C.html#built-in-scalar-data-types

I'm getting a deprecation warning from this line with numpy-1.20 saying that np.bool is just an alias for the builtin bool type. Is changing this likely to break or cause some awful performance regression on older numpy versions?