I'm working on adding support ofr codegeneration with Matrix objects. Currently an `indexed` type is supported that results in low-level contiguous arrays. These are always converted into loops though (and I don't really understand what they're for). In contrast, the intent here is to provide support for generating matrices that are comprised of sympy expressions (as seen frequently in `mechanics`). For example, the following should *work* after this update:
>>> mat = Matrix([sin(a), cos(b), tan(c)]) >>> func = autowrap(mat) >>> func(1, 2, 3) array([ 0.84147098, -0.41614684, -0.14254654]) I have some stuff working already, but have some question before I progress further. *1. Sympy Matrices are always 2 dimensional, should this be true of the generated code as well?* In numpy, the default is the minimum number of dimensions required. For example, `array([1, 2, 3])` has only one dimension. In contrast, with sympy `Matrix([1, 2, 3])` has 2 dimensions always (no way around). For expressions that are inherently column/row vectors should a single dimension array be created? *- Pros:* Less nested data, many scipy routines require single dimension arrays only (odeint) *- Cons:* Multiplication and indexing will be different. For this reason I'm kind of against switching, but I could be swayed. For example: >>> np_a = array([1, 2, 3]) >>> sym_a = Matrix([1, 2, 3]) >>> np_a.dot(np_a.T) # Perform Multiplication as done in numpy 14 >>> sym_a * sym_a.T # Perform Multiplication as done in sympy Matrix([ [1, 2, 3], [2, 4, 6], [3, 6, 9]]) >>> np_a_res = np_a.reshape((3,1)) # Reshape the array to be 2 dimensional >>> np_a_res.dot(np_a_res.T) # Multiply the 2 dimensional numpy arrays. This results in the same as sympy array([ [1, 2, 3], [2, 4, 6], [3, 6, 9]]) >>> np_a[1, 0] IndexError Traceback (most recent call last) <ipython-input-265-9a4f4bee3353> in <module>() ----> 1 np_a[1,0] IndexError: too many indices >>> np_a_res[1,0] # Indexing works the same in 2d as it would in sympy normally 2 *2. Should the default be numpy arrays?* I think yes. They are pretty much used everywhere in scientific python, and should be supported. numpy.matrix is on its way out, and should not be used in my opinion. Cython offers some support for generality, so that anything that offers the buffer protocol can be used. f2py may do the same, but I have little experience with it. Currently autowrap supports lists as well. I think this is silly, and results in some inefficiencies. As they're transformed into numpy.array internally in the call, the user must have numpy installed, and should be able to do this themselves. *3. For inputting matrices to functions, `MatrixSymbol`, or `DeferredVector`?* Sometimes you may have a lot of input variables, have those variables expressed as a vector of *known* length. Sympy offers two options for this: `MatrixSymbol` and `DeferredVector`. They both seem to offer the same intention, although `MatrixSymbol` seems to be used *way* more/have more functionality. Currently I'm only supporting `MatrixSymbol`. The idea is that this should be possible: >>> x = MatrixSymbol('x', 3, 1) #Acts as a vector >>> expr = x[1,1] + sin(x[2,1]) + cos(x[3,1]) >>> func = autowrap(expr) >>> inp = np.array([1, 2, 3]) >>> func(inp) 0.9193049302252362 Note that this is the inverse of the issue described in #1. This time it's the function input that will have dimesion mismatch between what is being input (a single dimension numpy vector, compared to a 2 dimension sympy MatrixSymbol/Matrix. Again, the numpy array can be reshaped either externally or internally with the magic of cython (this won't result in a copy operation either, just a new memoryview). Still, I'd like an opinion on this. *4. What is an Indexed type for?* Currently I'm ignoring these, and allowing them to stay as they are while writing functionality around them for Matrix types. Still, the code supporting them is messy (maybe it has to be?) and I can't refactor it into something cleaner until I understand what they do. I've read the docs on this functionality and see that you can make a Matrix Mutliplication function. Great. But I plan on supporting that later on as well with MatrixExpr types and calls to blas routines. There has to be a purpose for these, I just don't understand it yet. *5. Would a ctypes CodeWrapper be wanted?* (Not relevant immediately, but I'm curious) Currently only Cython and f2py are supported for wrapper objects. these make very robust solutions, but neither is in the standard library. `ctypes` is a standard library module that provides some functionality of wrappers around shared libraries (.so or .dll). Not nearly as robust, and no built in type conversion. Pros: everyone has it, Cons: it's not as good. I think I'll add this in later. If you have thoughts on any of these, please let me know! I want to make this useful for everyone, not just myself :) -- You received this message because you are subscribed to the Google Groups "sympy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/b362375c-2caa-41ee-a176-841d14147f12%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.