Hey everyone! Weeks 7 and 8 are done, and the biggest news first: I passed the midterm evaluationš. Half of GSoC is behind me now.
These two weeks were less about writing new classes and more about going back and making the ones I already had a lot stricter. Here is what happened.
PR #1920: The RatioEstimatorBuilder
This PR adds the builder for the NRE family, so NRE_A, NRE_B, NRE_C and BNRE all get the same typed interface that NPE and NLE already had.
The builder itself was honestly the easy part. By now the pattern is well established, so it was mostly mirroring what already worked, with linear, mlp and resnet as the classifier options. The interesting part was what my mentor Jan Teusen suggested we bundle into the same PR.
Some improvements to the base class
PR #1920 was the first PR that proved the shared base class serves a third family. My Mentor, Jan pointed out that this was exactly the right moment to fix the validation gaps in that base, because then the NRE builder and the vector field builder that was coming next would inherit the fixes for free, instead of me retrofitting four builders later.
So we folded a hardening bundle into the same PR:
Invalid Literal values now raise at construction. This was the real gap. If you typed a wrong field name, Python already raised a TypeError for you. But if you typed a wrong value on a correctly named field, like z_score_input="idependent", nothing happened until you called .train() and it blew up much later. Now it fails immediately.
Model-incompatible kwargs now raise too. Passing num_blocks to a linear classifier used to be silently dropped, and the same argument on mlp crashed late. Both are caught at construction now by inspecting the target build function's signature.
frozen=True on the config dataclasses. Configs are now immutable. If you want a different setting, you make a new object instead of mutating the old one. This sounds like a small thing but it removes a whole class of "I changed the config after passing it to the trainer, why did nothing happen" confusion.
A custom __repr__. Printing a config now shows only the fields that matter for the chosen model, instead of a wall of thirty Nones.
Uniform public API exposure. The mixed density builder was not exported at the same level as the others, so I fixed that too.
The z-score rename
The other thing that landed in this PR was a rename I had been putting off. The builders used z_score_x and z_score_y, inherited from the low level build_* functions. The problem is that those names are ambiguous once you have more than one family. For NPE, z_score_x actually standardizes theta, not x, because NPE models theta given x. So the name says one thing and does another depending on which trainer you are in.
We renamed them to z_score_input and z_score_condition. input is whatever the model is modelling and condition is whatever it is conditioning on, and the trainer decides which is which. The downstream build_* functions keep their old names, and the builder translates at the boundary.
The reason we did it now and not later is simple: the builder API has never shipped in a release yet, so this rename is free. After a release it becomes a breaking change. It was in three builders at that point and PR #1921 was about to add a fourth.
A shift in how we work
The other outcome of the midterm sync was a change in workflow for the second half of the project. Instead of Jan handing me a design and me implementing it, I now write a short design proposal first, as a markdown file in our GSoC repo, and Jan reviews it before I write any code.
The first one of these is for the vector field estimators, which is the next family. I will be honest, writing a design document before touching the editor feels slower at first. But the point is that a design mistake caught in a markdown file costs an hour, and the same mistake caught in review costs a week of rework. We also decided to start the documentation earlier than originally planned, instead of leaving it all to the very end.
An honest note about week 8
Week 8 was a slow week for me. I had other commitments and reduced my workload, so PR #1920 did not move much and the vector field design proposal did not get written. I flagged it in the sync rather than quietly falling behind, and Jan was completely fine about it. Back to normal pace from now.
What's Next?
PR #1920 needs the hardening review addressed and then it can merge. After that I write the vector field design proposal, get it reviewed, and only then start on VectorFieldEstimatorBuilder for FMPE and NPSE.
Thanks for reading, and see you in the next update!
Top comments (0)