Code center > Darwinbots3
Helping
Numsgil:
--- Quote from: rwill128 on April 17, 2013, 10:26:40 AM ---Haha, I've been in the planes of the Liberal Arts majors for the last few years, grinding rhetoric and critical theory.
Working on getting my stats up in calculus this whole week, but even the trash mobs sometimes force a tactical retreat.
EDIT: Looks like I was just jumping in too deep. The dense linear algebra code is making a lot of sense. Should be able to make some actual contributions within a week or two. Thanks for your patience and willingness to shove all this information my way.
--- End quote ---
It's pretty daunting math. What you see is several years of work learning the underlying math and writing code to do that math well.
If that math ends up winning, I do have other tasks you can work on. But they might be less fun :) (for some definition of fun)
rwill128:
Well, you're welcome to hit me with these other tasks.
The main thing slowing down my progress is that I can only work effectively learning one thing at once, and there's simply a lot more than one thing for me to learn -- C#, .NET libraries, math, your coding practices (which seem like good examples to follow), and the overall organization of your modules for Azimuth (and for the larger project that is DB3).
I've recently gotten a better mental map of which modules feature the lowest-level code and how they interact, so now I'm just learning how the basic Vector classes, etc. behave and what features they have before I get into the denser stuff.
The thing is, I start looking at the math, which usually makes sense, until I hit a concept I don't remember clearly, which means I get on Wikipedia or various other sites and read up on it. Then I go back to the code briefly and run into a line of C# code that I'm not familiar with. Next thing I know I've been on msdn.microsoft.com reading about the SerializableAttribute class for 45 minutes.
---
With all this math to learn, I'm starting to think the most effective way to review it is to practice coding implementations of it in my own basic programs.
But I'd like to also keep in mind how Azimuth handles these problems because it does it in such a clean, flexible fashion, processor-efficient fashion. As far as I can tell from my amateur perspective, physics engine libraries and object-oriented programming principles were made for each other, so it's nice to see a structured combination of the two.
---
Anyway, I'll keep on chipping away at the big pieces, but if there's some practical way of helping that I can take part in, I'll do that, even if it's not as fun.
Numsgil:
Implementing them is a good way to learn it, yeah. Also, you can set breakpoints in some of the functions and run the unit tests, and step through the code to figure out what it's doing. I've always found the debugger to be the best tool for understanding unfamiliar codebases. The code is built very much bottom up, which makes trying to understand it from a top down perspective, which is usually how people like to understand things, difficult. Doesn't help that it's not even really done.
Have you seen this picture? It's woefully out of date, but but that's roughly how I imagined things fitting together when I first started coding things.
...
Anyway, day-to-day right now I'm working on Azimuth.DenseLinearAlgebra.DenseVector. C# and I have been battling over making the code both readable and as fast as possible. I've been losing that battle, but I'm bringing out the big guns: a C preprocessor. Gonna throw some macros at the problem. Take that C#! I'm working on modifying an existing open source preprocessor so it'll work for the task, and I've basically got it working.
Right now I have to run the preprocessor as a pre-build step. It generates a C# code file, and I'll use that to build the project with. However, it's not immediately obvious which code is the real code and which is autogenerated, other than a comment at the top. Visual Studio has a way to help with this, though, which is to use the concept of "code behind" getting generated by a custom tool. It's not sexy coding work, but I need someone to code up a DLL that will allow Visual Studio to treat the preprocessor as a Custom Tool. See Custom Tools Explained. It comes with source, so it should be pretty easy to modify it.
The task is to build the DLL and have it query the input file's first line for the tool to run, and then run that tool. eg: the first line might be //..\..\3rdParty\mcpp\bin\release\mcpp.exe The custom tool takes that, appends the current file's path and a reasonable output file (maybe currentFile.Generated.cs), and then runs that final command. Also, you need to build scripts to register and unregister this custom tool with Visual Studio, which involves registry keys and fun things like that.
I'd normally start working on it sometime on the weekend or early next week, but if you want to tackle it for me it would save me some time and be immediately useful.
Botsareus:
--- Quote ---SerializableAttribute class
--- End quote ---
I remember that one. :)
rwill128:
Heck yeah! Something immediately useful that I can do. And I can accomplish it in the short term, which makes it easier to get motivated.
I'll read the Custom Tools tutorial and get cracking.
And yeah, I've seen the ModuleDiagram. It was helpful for some basic insight, which is good.
The main thing I need to work out (and perhaps diagram for myself, just to keep it straight) is how Azimuth works within itself, in addition to how it's going to connect to the larger project. That idea of using the tests and the debugger to watch the code work is perfect, though. I will be doing that later this weekend.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version