I think these are good directions. I also think they should be driven by strong examples (the PyDy example in your repo is good, I see the paper has some others), because that will affect the API.
For vectorized evaluation, array data can be stored in different ways, and this affects the interface and compilation. The length/stride information can either be: 1. not stored with the array (bare C arrays) - the length then either needs to be known at compile time or passed as a parameter to the function. 2. stored in a structure with the data, like numpy arrays. If the compiled code is called from Python, it is very likely using a numpy array for storage. It would then be useful for the compiled code to operate on numpy arrays directly ( See an example here, where it can sum over a 1-d numpy array: https://github.com/markdewing/sympy/blob/llvmlite/sympy/printing/llvmjitcode.py ) In principle the autowrap features should provide equivalent functionality as using an LLVM JIT - the API should be made similar - I haven't gotten around to this yet. (I've been focused on compiling callback routines - which requires precisely specifying the input argument types and their order - I'm not sure if autowrap can do this or not) As for the items in your list - item 1 is currently implemented (though it may not be able to convert every Sympy element - Piecewise is missing). Item 2 should be handled by PR 10683, which was just merged. Item 3 - this would be subject to issues with arrays I mentioned earlier, but would be useful. I have some code for array evaluation, but in the context of callback routines to various integrators (Cuba, Cubature) - I can put up that code if you want. For item 4, do you have an example for how the Cartesian product would be used? Item 6 seems very specialized, but if there are problems where the bottleneck is evaluating functions on large arrays, it could be worthwhile. Mark On Thursday, April 21, 2016 at 12:22:13 PM UTC-5, yueming liu wrote: > > I looked at the PRs yesterday, there are some overlap in the basic > functions. However, I have a longer road map about the JIT compilation. Let > me briefly list out it, so you all may think about if it is worthy or > suitable to put it in SymPy. > For the JIT compilation, it should provide the class or function > interfaces that wrap the details of llvmlite, the following functions are > included: > > 1. Compile a single SymPy expression, a number is returned as the result > > 2. Compile a list of SymPy expresions, an array is returned as the result > (batch compile) > > 3. Compile a single SymPy expression, a array is returned when an array is > passed into the compiled function (vectorization) > - This is very useful since the over head of the function call can be > reduced when you want to do many times evaluation against the compiled > expressison > > Advanced features: > 4. The extension from 3, provide Cartisian product of parameters like the > Cartisian product in SQL > expr = x*y > f = jit_compile([x,y], expr) > f([2,3], [4,5,6]) # return [2*4, 2*5, 2*6, 3*4, 3*5, 3*6] > > 5. The extension from 4, vector symbol can be used instead of symbol of > double number > - This can be used in design algorithms which involve in a double loop > between two list of vectors > > Even longer road map: > 6. The compiled IR can be send to a remote server and the evaluation can > be performed on the server. > > All the above has been implemented in my another project SymJava in the > experimental branch dist-snc. Actually, SymJava is motivated by SymPy, so I > believe is easy to implement the proposed features in SymPy. > > -Yueming Liu > > On Wednesday, April 20, 2016 at 1:43:11 PM UTC-7, Jason Moore wrote: >> >> This sounds great. Note that we have recently merged some code that uses >> llvm to automatically JIT sympy expressions. Check out the master branch >> and search for the relevant pull requests. Maybe there is some overlap with >> your project. >> >> >> Jason >> moorepants.info >> +01 530-601-9791 >> >> On Wed, Apr 20, 2016 at 11:29 AM, yueming liu <nkliuy...@gmail.com> >> wrote: >> >>> I am not sure if it is too late to contribute to SymPy and the paper. >>> I've been developing a private project called sympy-llvm which uses >>> just-in-time (JIT) compilation technique to compile SymPy expressions to >>> native machine code in order to speedup the numerical evaluation of the >>> expressions for numerical computation purpose. This is similar to the >>> existing functions in SymPy like subs/evalf, lambdify, ufuncify and Theano >>> (see http://docs.sympy.org/latest/modules/numeric-computation.html). >>> The advantage of sympy-llvm is that it is faster than all the existing >>> methods in the sense of compilation time and numerical evaluation time. >>> Another advantage is that no FORTRAN or C/C++ source code generation >>> involved. Runnable machine code is generated in memory using LLVM >>> (Attached figures show some comparison benchmarks. SMC_py stands for >>> sympy-llvm implementation). Example applications are implemented such as >>> the numerical computation for modals in PyDy. I'd like to make sympy-llvm >>> public and integrate into SymPy as an optional component for numerical >>> computation if possible. >>> >>> As you all may know that the projects like Google TensorFlow and Theano >>> are both using symbolic-numerical way to provide human friendly language >>> interface and fast numerical computation. The CASs projects developed a >>> couple of decades ago like Maple, Maxima, Mathematica, Reduce etc ( >>> https://en.wikipedia.org/wiki/List_of_computer_algebra_systems) none of >>> them have 'in-memory' JIT complication functions to bridge the gap between >>> symbolic and numeric computations. I believe sympy-llvm as a component of >>> SymPy will be a great enhancement of SymPy in numerical computation field. >>> >>> -Yueming Liu >>> >>> >>> On Tuesday, April 19, 2016 at 3:53:13 PM UTC-7, Ondřej Čertík wrote: >>>> >>>> Hi, >>>> >>>> I would like to invite anybody to contribute to our paper about SymPy >>>> and become an author. We use the authorship criteria that are written >>>> in our README: >>>> >>>> >>>> https://github.com/sympy/sympy-paper/blob/2a93d84a6f3447f8e15e24f02cedb6c27c299abd/README.md#authorship-criteria >>>> >>>> >>>> In other words, to satisfy 1), you must contribute to sympy in some >>>> way (e.g. some good patch that is more than, say, fixing a typo in >>>> documentation), to satisfy 2), get involved with the development of >>>> the sympy-paper repository: https://github.com/sympy/sympy-paper, >>>> submit a patch there, write a section, or just review PRs. Finally, >>>> you must also be willing to satisfy 3) and 4). Hopefully this should >>>> be pretty clear, but if you have any questions about authorship, >>>> please let me or Aaron know. >>>> >>>> Once this paper is accepted, we will probably put it into the SymPy's >>>> README for people to cite, so I encourage everyone to get involved. >>>> >>>> Ondrej >>>> >>> -- >>> 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+un...@googlegroups.com. >>> To post to this group, send email to sy...@googlegroups.com. >>> Visit this group at https://groups.google.com/group/sympy. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/sympy/af0be361-2f60-4c4e-878c-6a264289ba50%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/sympy/af0be361-2f60-4c4e-878c-6a264289ba50%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- 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 https://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/c59b3b38-2679-47e4-bd9a-8d8db2e61c86%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
