Argument names

[smmaurer]

I'm taking a poll! Let me know if you have opinions about the following.

I want to add some new prediction functionality to the template model classes, and tweak a few argument names to make them clearer.

Currently, UrbanSim supports sending predicted values to a different column name than estimation values came from. I'm adding support to send them to a different table as well. This will make it easier to fit a model from empirical data (CL, CHTS, etc) while specifying from the outset that prediction will take place in a separate table of synthetic data. (Right-hand-side column names will probably need to be the same in the two tables.)

For parameters related to model fitting (in a simple case like binary logit or OLS), this gives us:

• tables
• model_expression
• filters? (replacing fit_filters)

And for prediction:

• out_tables
• out_column (replacing out_fname)
• out_transform (replacing ytransform)
• out_filters? (replacing predict_filters)

I'm uncertain whether to rename fit_filters and predict_filters, which are already clear and descriptive names. My only complaint about them is that "fit" and "predict" can be misinterpreted as verbs, but they're meant as adjectives. Calling them filters and out_filters would be more consistent with the other parameter names, though.

Any thoughts about the names or the proposed functionality?

@janowicz @waddell @mxndrwgrdnr

[mxndrwgrdnr]

What about fitted_filters and predicted_filters to make the names more adjective-like? The only other thing to consider here is that for MNL-based models, there are both alts_fit_filters and choosers_fit_filters. Not sure if that changes how you're thinking about naming conventions, but I wanted to point that out.

[smmaurer]

The "settings objects" proposed in issue #54 will provide a nice solution for the problem of coming up with clear parameter names.