Hi, I'm not exactly sure if the polys architecture can be copied "exactly". There would surely be some differences in the implementation of the matrix module and the polys module. And I think we cannot foresee some differences until we start implementing this part.
I don't think we should implement Level 0 in C. We can get speed with identifying bottlenecks with speed and improving those. And here lies the problem. I am now somewhat skeptical about the whole issue, because I am having doubts if we are exactly sure where these bottlenecks are. Maybe a detailed profiling will help us identify those. Sincerely, -Saurabh On May 14, 6:44 pm, Tom Bachmann <e_mc...@web.de> wrote: > Hi, > > you will by now have noticed that this is a rather hotly debated topic. > A few pragmatic remarks: > > - the polys module, as it stands, works very well, and is used all > throughout sympy (implicitly or explicitly) > - by itself, this is no reason to copy its design > - it is essentially impossible to prove or refute the claim that using a > C-style architecture yields superior performance [*] > > The following is my personal view on the matter. I do not have much > justification for it beyond what I am saying directly here. In > particular I am not saying this is the way things should be done. > > - writing "C-style" python yields the performance of python and the > readability of C > - hence don't do it > - python code can be expected to perform well, as long as the frequency > of function calls stays low > - hence if you find your code slowed down by excessively performing > low-level operations on your objects, implement said low-level > operation in C > > I am not entirely sure how practical the last suggestion is (in > particular regarding our "pure python" mentality). > > I see python as great way to write high-level algorithms. If it is not > perfect for implementing e.g. low-level polynomial arithmetic then so be > it; write your highlevel algorithms to work with a well-specified > polynomial arithmetic interface, and implement that in C (or cython). > > Best, > Tom > > [*] The only way to refute the claim is to re-implement polys in a more > object-oriented style, which is most likely not going to happen (it is a > huge amount of work). > > On 14.05.2013 14:23, Saurabh Jha wrote: > > > > > > > > > Hi, > > > I recently had a discussion with Ronan on irc on the polys module and > > he made the point that using functions instead of classes do not lead > > to increase in speed as pointed out in [1]. > > > He made the following points-- > > the benchmarks are flawed because > > 1) they are too short (good benchmarks last for seconds, not > > milliseconds) > > 2) they use his design, so cannot be used as a justification of his > > design > > > I feel that the current polys module is not very substantially > > different from the one proposed in [1]. I would you request you all to > > give your views on this issues, on the adequacy of the polys > > architecture, partly because of it's importance in sympy and partly > > because my proposal is based on the architecture of the current polys > > module[2]. > > > I myself like the polys architecture. > > > [1]http://mattpap.github.io/masters-thesis/html/index.html > > [2]http://www.google-melange.com/gsoc/proposal/review/google/gsoc2013/ > > saurabh_jha/11001 > > > -Saurabh -- 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?hl=en-US. For more options, visit https://groups.google.com/groups/opt_out.
