I like the timeline. I think that it indirectly measures maturity.
On Tue, Feb 12, 2013 at 11:39 AM, Aaron Meurer <[email protected]> wrote: > > Experience was that direct questions tend to have low information > content (everyone says the same thing). Indirect questions will be ignored > by the lazy but engage the engaged. You often want to test for curiosity > and passion more than actual experience in the domain. > > I like this idea. We already ask what environment students use. > > But I think the main focus of the application is to see if students > are able understand their own project. We should ask questions that > attempt to make this clear. > > My main question when I created this session idea was whether or not > we should abandon, or at least refactor, the timeline portion of the > application. On the one hand, it forces the student to think about > exactly what they are going to do. On the other hand, it is never > accurate (students always overestimate what they can complete in a > given amount of time), and yet students still try to stress over > making it accurate. What are your thoughts on this? > > > We should match mathematically strong students with strong programmer > mentors and strong programmer students with strong mathematical mentors. We > often do the opposite due to shared interests but this might result in > ideal contributions > > I'm not sure about this. It sounds like a good idea, at least to > match a strong programmer with a weak one, because we want to watch > out for amateur mistakes, and give suggestions for things that the > student probably would never think of (e.g., a more elegant object > oriented or Pythonic approach to solving some problem). But on the > other hand, I really think it's important to match students doing > mathematically difficult (or even just theoretically difficult) > projects with someone who knows as much about the theory as possible, > because they are going to run into issues with the theory at some > point, and it's nice when the mentor can give them help there. > > I remember there was a nice example of this with Ondrej and Sean. They > can correct me on the details, but there was some issue with incorrect > results. It was either an issue of a typo in a book or a typo in the > code (I don't remember), but Ondrej helped him figure it out. The > point it, you really had to know the physics to understand the problem > and figure out how to fix it. > > On Tue, Feb 12, 2013 at 12:23 PM, Matthew Rocklin <[email protected]> > wrote: > > I'm happy to serve as secondary mentor on any of {assumptions, matrices, > > stats, rewrite-rules}. I don't think I'm sufficiently on top of things > to > > be an effective mentor this year. Let me know if you'd like me on the > list. > > Sure, add yourself. Backup mentors are helpful, especially for > difficult projects. And of course, we will appreciate any help you > can give reviewing applications. > > Aaron Meurer > > > > > > > On Tue, Feb 12, 2013 at 11:21 AM, Matthew Rocklin <[email protected]> > > wrote: > >> > >> 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. > > > > > > -- > 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.
