In the short term just submit SVN patches. I'll look them over and check them in if they look good. After I get sick of doing that much work, I'll set you up with proper credentials to check in changes yourself
...
If you're feeling adventurous here's some meatier problems. They involve a lot of math and reading, but it sounds like you don't mind giving it a go:
...
I'm working on fluid physics right now. I wouldn't mind some help, but there's a lot of weird ideas and vocab you need to get familiar with for any of it to make sense. Here's some papers/links:
Basically I'm working on an incompressible "inviscid" "discrete vortex element"/"panel method" fluid sim. Only I'm mostly interested in fluid/boundary interactions, so I'm strongly considering ignoring vortices entirely and only using a "potential flow". Which represents a weird sort of fluid that has properties of both inviscid and really really viscous fluids at the same time. But it's pretty fast to calculate.
...
For rigid body physics, right now, in Annulus, there's some code to do moving polygon vs moving polygon collision detection, and it's only partially finished. In order to handle rotations and translations, I've been decomposing the polygons in to vertices and edges, and using numerical root finding techniques to find roots. I think there's some edge cases (quite literally
) I haven't solved yet. It's not conceptually
too difficult, though you need a certain foundation in numerical root finding and a basic understanding of equations of motion. And there's a lot of code to handle (it's very verbose for some reason. Something I was going to refactor at some point. )
...
Also in Annulus the straight skeleton code I mentioned earlier is technically correct for all the toy problems I've thrown at it (and that involved
way more work than I'd care to admit), but I've noticed that for larger polygons it can get confused and break for numerical reasons. Even writing the unit tests for more complex cases would be helpful, as it takes a lot of work to transcribe the vertices for the polygons and find a straight skeleton solver somewhere online to give the "correct" answer. Fixing the code up would be fantastic
...
There's a
lot of linear algebra code in Azimuth.DenseLinearAlgebra. Right now it's all direct methods (QR decompositions, Cholesky decompositions, etc.). But some iterative methods would be useful, too. Especially because I've noticed that decomposing even medium sized matrices (with about ~40 ros/cols) starts to introduce some numerical error. Being able to "polish" answers with an iteration or two of some iterative solver would be really nice. I don't know a whole lot about iterative solvers, though. But it shouldn't be too hard. If that sounds interesting you could work on that. I can probably dig up some references to get you started.
...
This very week I've been working on optimizing the x86 assembly that the very low level linear algebra code is getting compiled to by the C# JITter. However I'd like to be able to use AVX/SSE as well. But there's no way in C# to indicate that those instructions should be used by the JITter. So I need someone to explore various ways to force their use. One possibility is
slimgen. Another possibility is having a C++/CLI version of the DenseVector code, but that adds a whole lot of complexity to the build process (since now it needs a C++ compiler, and separate DLLs for x86 and x64 builds). And I'd like to the program to autodetect which instruction set is supported and automatically load the appropriate version, which means someone needs to much around with the internals of the JITter. And I'd still like to test all the different versions against the unit tests, so there's that.
...
Those are all really meaty and hard to just jump in and start working on, but they're also IMO the most interesting problems. Feel free to poke around the code base in the mean time and get a feel for things at least.