> 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.
