On Tue, Feb 12, 2013 at 12:16 PM, Aaron Meurer <asmeu...@gmail.com> wrote: > On Mon, Feb 11, 2013 at 11:19 PM, Ondřej Čertík <ondrej.cer...@gmail.com> > wrote: >> On Mon, Feb 11, 2013 at 8:40 PM, Aaron Meurer <asmeu...@gmail.com> wrote: >>> It also means that the dates I gave are wrong. The application >>> deadline is actually March 29 and the application period begins March >>> 18. That gives us more time than I had originally thought, though we >>> should still get going on this now, especially with the ideas page, >>> because now that the program has been officially announced, students >>> are going to start coming to SymPy and looking at it. >> >> Yep. What ideas/projects do you think are high priority (or important) in >> sympy? >> Or do you prefer to simply list all good ideas and simply let students >> choose? >> I have a few ideas for projects, that I will propose in more detail/guidance, >> and then we can have just random good ideas where the students can get >> inspired. >> >> Ondrej > > As always, I encourage students to apply for those projects that are > most interesting to them. If it's on the ideas page, then it means > that we want it implemented (modulo some cleaning up of the ideas page > as I mentioned earlier), so it's not like we won't accept them because > they are proposing to do something we don't want. If they want to > suggest an idea that's not on the ideas page, that's fine, and it > should be clear after discussing it with us whether we would accept > the idea or not. > > With that being said, I consider these to be the highest priority > projects (in order, most important first):
I forgot one. This is maybe not enough to be a GSoC project in itself, though enough could probably be added to it to make it one. We need to automate our release process (see http://code.google.com/p/sympy/issues/detail?id=3445, and my rant on the mailing list linked to there). I would put this at the top of my list, above the assumptions. Right now, we are releasing at an abysmal rate (less than once a year), when we have enough changes coming in to be releasing once a month. I myself have already committed to not do another release until this is fixed, so unless someone else steps up, this literally means that we won't release again until this issue is solved. Any thoughts on something that could be added to this to make it a full GSoC project? Aaron Meurer > > - Completely move to the new assumptions system. This means we have a > good API for the new system, the old system is completely gone (and > the core is cleared of assumptions), the new assumptions have all the > power of the old ones (and ideally much more), and are well > documented, all the logical implication stuff is done correctly so > that they are fast, etc. This is unfortunately a hard project because > it requires a bit of knowledge of SymPy already. It also requires a > good knowledge of Python, including some of the more advanced language > features like context managers, and possibly metaclasses. > > - Additions to the polys, especially involving algebraic > numbers/functions. I put this next because unlike the other items in > my list, this one requires a very high level of mathematics (probably > some graduate work in algebra), and therefore it will be a rare find > if a student comes forward who can do it. Our ability to do things > like implement the algebraic part of the Risch algorithm or improve > our simplification of algebraic expressions (basically, anything with > roots in it) depends on this. > > - Refactor the polys for speed. In particular, we need to move to a > sparse representation, as the current dense representation is too slow > for polynomials of more than just a few variables. This project may > actually be a prerequisite for the previous one: if things are too > slow to do anything useful, it won't matter what algorithms we have > implemented. We won't even be able to effectively test them, much > less use them. > > - Fast linear algebra. The idea here is to refactor the matrices to be > more like the polys, i.e., in a layered structure. At the bottom > there should be the ground types, which would be the same as the polys > ground types. This would let us have matrices over fast gmpy > rationals, or even matrices over rational functions, which > automatically reduce themselves to zero. This would also leave room > for abstraction against different internal representations, like > sparse or dense. > > These are, in my opinion, the most important things to be done for the > core of SymPy. Others may disagree. But note that these ideas are > mainly targeted to maximize the speed/capabilities of all of SymPy. > If you are interested in the most important things for some particular > submodule, we could probably determine that as well. I don't know > about all the submodules. I could tell you pretty accurately what the > most important things to be done in the integration module are, for > example, but I have no > >> >> -- >> 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. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> -- 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. For more options, visit https://groups.google.com/groups/opt_out.
