3 ms·

I've never seen TOML, but I really like it. In my pretty simple pipeline, I've just been using a JSON-like structure that I can easily import into Python: st

I've never seen TOML, but I really like it. In my pretty simple pipeline, I've just been using a JSON-like structure that I can easily import into Python: strategies = [ { 'name': 'column1', 'kind': 'categorical', 'strategy': 'ohe' }, { 'name': 'column2', 'kind': 'continuous', 'strategy': 'center' } ... ] It has worked very well thus far. I received a request from a stakeholder a few weeks back about building a new model using a slightly different target. I told him it'd take a couple of days at least (it was a very similar target), but I had it completed (at least from a re-engineering perspective) in about 5 minutes. I simply changed the target variable config and removed any leaky features after changing the target. I'm convinced that this approach, coupled with configurations for tree-based models like minimum samples per leaf and max depth, is the most efficient way of building predictive models. Those configurations specific to tree-based model software help to skirt things like the rule of five, etc., IMO.

w4nderlust 8y ago
That experience you talked about, being able to really quickly come up with solutions starting from an already established and working configuration, was one of the main motivating factors behind the making of Ludwig too! Basically I had a model, and they asked me first to add an input feature, then to add another one, then to add an output feature. Every time I did it with generality in mind so that the following time they would ask me it would require less time to do it. In the end the final solution is that it just costed me to add a for in a YAML file. :)
thanatropism 8y ago
That's basically my approach. TOML is chosen for readability and easy maintenance, as well for the ability to cut and paste some chunks of python defining constants etc. directly which makes the first steps much less bureaucratic. I'm looking into more general parsing that would allow me to define semi-verbose little languages. In my heart Stata is still the gold standard for rapid fire usability, even at the cost of idiosyncrasy; I'd like to further make the engineering of, say, REST APIs more and more code/language independent and more logically specified, since a lot of the new "data science" crowd coming from stats and applied maths can't code their way out of a Tequila Sunrise.

w4nderlust 8y ago

That experience you talked about, being able to really quickly come up with solutions starting from an already established and working configuration, was one of the main motivating factors behind the making of Ludwig too! Basically I had a model, and they asked me first to add an input feature, then to add another one, then to add an output feature. Every time I did it with generality in mind so that the following time they would ask me it would require less time to do it. In the end the final solution is that it just costed me to add a for in a YAML file. :)

thanatropism 8y ago

That's basically my approach. TOML is chosen for readability and easy maintenance, as well for the ability to cut and paste some chunks of python defining constants etc. directly which makes the first steps much less bureaucratic. I'm looking into more general parsing that would allow me to define semi-verbose little languages. In my heart Stata is still the gold standard for rapid fire usability, even at the cost of idiosyncrasy; I'd like to further make the engineering of, say, REST APIs more and more code/language independent and more logically specified, since a lot of the new "data science" crowd coming from stats and applied maths can't code their way out of a Tequila Sunrise.