Sometimes when I look at codebases I experience frustration at what I perceive as a lack of generalisation.
An example of this is sympy, I think it's called. It looked to me like it contained no mapping between operators and their inverses, for writing solvers more efficiently.
I've bumped into an interesting situation playing with this code. I'm not sure how to identify that a part of an expression can be a component of a linear combination. I'm considering modeling linear combinations as sums of scalar coefficients.
I'm guessing that this isn't actually complicated, and I just need to consider a lot of things that feel inhibited or missing for me.
1. When considering a linear combination, we ask what is it combining. For the uniform distribution sum, we want sums of either scalars or uniform distributions, nothing else. So some way to parameterise that for other parts.
2. When flattening expression trees, one often walks them recursively. I've drafted a construct I called "interpretation" that holds some idea around applying a mixin to an object that is already constructed. Basically it just supports "new" and "isinstance" to give some way to work with objects using intuition while prototyping.
So question #2 is how to write code that reinterprets an expression tree as a flat linear combination, by recursively interpreting its parts that way ... basically the interpretation needs to be parameterised on what the linear combination is of, as described in #1. Whew, I think ...
There's always something you haven't thought of. If you "fully" align your borg with humanity, they spawn a nanite species on the dark side of the moon.