lambe
commented
7 years ago After some thought, point (1) above is probably moot if issue #246 is resolved. The user then just creates the matrix using default types and converts the whole matrix to the right type when necessary, e.g., calling a solver with specific type requirements.
Two things would go a long way to improving the user experience for assembling sparse matrices.
1) Check if the index and value arrays can be cast into the correct data types and do so if possible.
For example, if an index array is of type int32, but the matrix index type is int64, a type error is raised in the current code. However, casting into a compatible type is straightforward and can be done without the user's knowledge. In this particular case, we could even cast input arrays of type int64 to type int32 provided the matrix dimension is smaller than 2^31. (But we can save that for later.)
We could do the same for the value array. It's just a question of deciding which casting operations should be allowed and which should throw an error.
2) Allow the value argument to be a scalar instead of a list or numpy array.
This is mostly syntactic sugar, but it means the user doesn't need to create extra lists or arrays for a few cases.