I think that we should highlight the "important projects" in the ideas page. I also think that we should supply more concrete goals, perhaps in the form of a list of issues. If I get time I'll try to think of a few for new assumptions. In short I think that we need to manage these projects more explicitly.
If we give a more structured list of goals then the applications will have less information (they'll just copy-paste what we write) and we'll need some other mechanism to judge students. On Tue, Feb 12, 2013 at 11:16 AM, Aaron Meurer <[email protected]> wrote: > On Mon, Feb 11, 2013 at 11:19 PM, Ondřej Čertík <[email protected]> > wrote: > > On Mon, Feb 11, 2013 at 8:40 PM, Aaron Meurer <[email protected]> > 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): > > - 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 [email protected]. > > To post to this group, send email to [email protected]. > > 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 [email protected]. > To post to this group, send email to [email protected]. > 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/sympy?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
