I saw your edits to the template, and I mostly like them. One thing
that strikes me as maybe a bit much is the part that says "In your
opinion what are the two most undervalued packages in Python?" (and
also the question before it). I know that I would not have been able
to answer this question when I first applied to GSoC, because my only
Python experience was solving my own problems using the language and
the standard library. Maybe we could change it to something more
Python language related, like "what are your favorite features of
Python that are lacking in most other common programming languages?"
or "what, in your opinion, is the most advanced Python language
feature or standard library functionality that you have used?"
Furthermore, the focus for almost all the projects will not be on
using third party packages, but rather features of the Python
language, standard library, and SymPy.
Also, I wouldn't worry too much on trying to figure out how well the
students know Python in the application. That will come out clear
enough in the patch requirement.
But all in all, I think this is a great idea. This should make reading
the applications fun, and reduce the amount of boilerplate that the
reviewers just skim over anyway.
Aaron Meurer
On Tue, Feb 12, 2013 at 12:44 PM, Matthew Rocklin <mrock...@gmail.com> wrote:
> I like the timeline. I think that it indirectly measures maturity.
>
>
> On Tue, Feb 12, 2013 at 11:39 AM, Aaron Meurer <asmeu...@gmail.com> 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 <mrock...@gmail.com>
>> 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 <mrock...@gmail.com>
>> > 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 <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):
>> >>>
>> >>> - 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.
>> >>>
>> >>>
>> >>
>> >
>> > --
>> > 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.
>>
>>
>
> --
> 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.
