Repository navigation
wishlist #69
Description
- cast numpy scalars to af scalars, so that things like
np.sin(scalar)+af_array=np_arraydon't happen. It's confusing and people are bound to usemath.orcmath.functions. Pyopencl does the casting silently. funny:af_array+np.sin(scalar)=af_array - change array layout to row-major as in numpy and C/C++ so that arrays copied from the host and arrays created on the device match (or is there a reason for column-major arrays?))
- make the api a little more like numpy (I know, afnumpy is there) e.g. implement more array methods (
.abs(),.min(),.max(),.sum(),.imag,.real,.conj(),.transpose()and so on) and rename the array attributes (.elements()to.size,.dims()to.shape,af.moddims()to.reshape()...)
Activity
pavanky commentedon Mar 24, 2016
@ZacDiggum
np.sin(scalar) + af_arrayis perhaps calling the__add__onnp.ndarraybut not onaf.Array. I will see if I can figure this out.af.Arrayin your code that does the renaming.@FilipeMaia any thoughts ?
FilipeMaia commentedon Mar 24, 2016
np.sin(scalar) + af_arraydefinitely calls__add__on numpy. Probably then numpy tries to convert the second argument to a numpy array by calling__array__on it. The exact same issue exists in afnumpy. I don't know of a way around this while still ensuring thatnp.array(af_array)works.FilipeMaia commentedon Mar 24, 2016
BTW about (1) the issue only happens with
numpy.functions, not the ones inmath.orcmath.which return normal python scalars.pavanky commentedon Mar 24, 2016
@FilipeMaia Any idea why numpy's
__add__takes precedence over arrayfires__radd__?FilipeMaia commentedon Mar 24, 2016
@pavanky Why would your class have precedence over numpy's one? The numpy argument is first so its
__add__is always the first to be called. Only in case that it fails is__radd__called on the other argument.pavanky commentedon Mar 24, 2016
@FilipeMaia yeah I just found that out myself. May be a simple solution would be to have the user set a flag which chooses between
__array__or not ?FilipeMaia commentedon Mar 24, 2016
@pavanky That could be an option. Another possibility might be to raise a warning if
__array__is being called by someone other thannumpy.array, although this might require some ugly stack introspection.pavanky commentedon Mar 24, 2016
@FilipeMaia This will still not solve the problem. I am guessing
np.ndarray.__add__calls__array__which would result in no warning at all.FilipeMaia commentedon Mar 24, 2016
You mean
__add__callsnumpy.array. Yes you're probably right, so we would need to be clever about it...pavanky commentedon Mar 24, 2016
@FilipeMaia I am leaning towards not supporting
__array__by default and only enabling it when a user manually asks for it. We could have a methodto_ndarraywhich users can call conversion to numpy.FilipeMaia commentedon Mar 24, 2016
Sure, that's cleaner and also a reasonable solution.
FilipeMaia commentedon Mar 24, 2016
@pavanky I found a better solution! Setting the
__array_priority__attribute inArray. I tested this on afnumpy and it seems to work.Check http://stackoverflow.com/questions/35866738/avoid-numpy-distributing-an-operation-for-overloaded-operator
pavanky commentedon Mar 24, 2016
@FilipeMaia can you send in a patch ? You understand the situation better than I do here.
FilipeMaia commentedon Mar 24, 2016
@pavanky #71 should solve the first issue.
pavanky commentedon Mar 24, 2016
@ZacDiggum since (1) is now fixed and (2) has a different issue associated with it, can you close the issue and open a new one for adding new methods (or atleast rename this issue to reflect the unresolved ones).