FS Gateware: Colby Peck - Gateware Week 9: Pipeline Refactor Candidate 1

I finished up the first big step of the pipeline refactor this week! The new single header testing project is now solely responsible for generating, testing, and updating Gateware’s single header. All dependencies and calls to the single header or its compiler were removed from the unit test and dummy main projects, and the pipeline is in a fully functional format on the pipeline refactor branch. If it somehow turns out that further progress on the pipeline refactor can’t be made, we have a state we can revert to and merge into master that still improves the current pipeline (a quick-save, if you will).

This is what the current stage of the pipeline refactor looks like on gitlab. I know, I know, the linux debug test is failing. There's a timing issue with a multithreading test. Lari's working on it on his own branch, so it's been deemed 'not my problem' for now.

This setup would require Gateware developers to manually update the single header using the single header test project, which is a big downside. Further along in the refactor, the handling of the single header will hopefully be fully automated, but that’s not something that can be implemented until Lari and I figure out what solution we want to use for automatically pushing to a repo.

While we’re figuring out what’s next in regards to the pipeline refactor (and while I’ve been waiting for the pipelines to run), I’ve been working on refactoring and expanding the unit tests for GVector. I started with a refactor pass that changed all of the existing unit tests to use a lambda and the vector comparison macro I wrote. That made the tests both more unified and more easily extensible. Then, I started expanding the coverage of the unit tests, one by one. The Magnitude and Normalize tests got a bit of special treatment; I guess I was just extra 'in the zone' when I got to them. I haven't finished expanding all of the tests yet, but I'm getting there.

Alright, now I'm going to talk in-depth about some linear algebra for a second here. If you're not interested in that, then this is your final chance to escape.

...Still here? Cool.

So! If we define a 'homogenous' vector as a vector where all components either have equal magnitude (positive or negative) or are 0, then there are 64 possible homogenous 4-component vectors that can be composed with a given magnitude. We can leverage this fact to make a batch of 64 vectors that will test positive values, negative values, and 0s in all possible locations and combinations.

This is a screenshot of the one-component and two-component homogenous vectors being tested in the magnitude test. The three-component and four-component homogenous vectors are also generated and tested. When you're composing a homogenous vector and intend for it to have a given magnitude, each component must equal (intended magnitude / (sqrt(number of non-zero components))).

I then used this batch of 64 vectors to make some test functions for the Magnitude and Normal tests, then called those functions using some for loops to test a lot of different vectors.