arrayfire / arrayfire-haskell

Haskell bindings to ArrayFire

Home Page:http://hackage.haskell.org/package/arrayfire

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Smart constructors are transposed

gilgamec opened this issue · comments

This was mentioned in #22, but I'll make an Issue for it here. The data provided to the smart constructors matrix, cube, and tensor is validated (in terms of row and column sizes) in row-major order, but the constructors all flatten the input lists and use mkArray, which enters the data in the column-major order. This leads to, first, properly arranged rows and columns being invalid:

λ> A.matrix (3,2) [[1,2,3],[4,5,6]]
*** Exception: AFException {afExceptionType = SizeError, afExceptionCode = 203, afExceptionMsg = "Invalid elements provided. Expected 6 elements received 4"}

and, second, if the input lists are transposed so they validate OK, the data in the Array doesn't even follow the rows and columns provided:

λ> A.matrix (3,2) [[1,2],[3,4],[5,6]]
ArrayFire Array
[3 2 1 1]
    1.0000     4.0000 
    2.0000     5.0000 
    3.0000     6.0000 

@gilgamec what do you suggest then ? Would it be more convenient for the end user if we force her user to specify everything in column-major order ?

I think it might be good to support both, tbh. Row / Column-oriented interfaces for all of the smart constructors, that is.

#37

@gilgamec this should provide a fix so that matrix can be used correctly.

example shown below:

> A.matrix (3,2) [[1,2,3],[4,5,6]]
ArrayFire Array                                                                                                                                                                                                                               
[3 2 1 1]                                                                                                                                                                                                                                     
    1.0000     4.0000                                                                                                                                                                                                                         
    2.0000     5.0000                                                                                                                                                                                                                         
    3.0000     6.0000                                                                                                                                                                                                                         

@gilgamec this should be fixed, please re-open if you think otherwise.

we're converging upon Array perfection.