-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How should the {si} package work? / Roadmap ideas #5
Comments
Hi @Robinlovelace -- I think you forgot to add an example of how this function works currently. |
True that, updated, thanks for the heads-up @Nowosad and looking forward to doing some geocomputing with you soon! |
Create si_predict/si_calculate for #5
si_model()
/si_predict()
/si_train()
work?
Will try and add some proper thoughts when I'm back at work next week (or more likely the week after) but immediate thoughts on functionality that would be useful would be as well as various options to calibrate cost or distance / origin / destination parameters with observed data and Poisson / nb regression, functionality to input ones own parameter guesses (I.e. 1 for origin, - 1.5 for dis) would be really useful for rough and ready flow estimating. |
One thing that might be useful to consider if incorporating constrained models estimated via GLMs is the use of sparse matrices to accommodate design matrices dominated by binary indicator variables. Unnecessary if instead using the multiplicative form, but could be nice to have both. Another consideration is metrics for evaluating predictions, such as comparing matrices, out-of-sample methods, SSI, etc. |
Hi Taylor, thanks for the input. As per #14 and #15 I think the greatest 'added value' part of this approach could be the geographic pre-processing and flexibility for people to use whatever modelling frameworks they want as inputs into the Agree re metrics for evaluating predictions, plan to discuss this with @lenkahas on Friday, although still need to get the foundations right e.g. #16 is the priority ATM. |
That makes sense @Robinlovelace , very cool. In that case, you can leave the bespoke data structures up to the individual packages doing the calibration. Apologies for the ambiguity, the design matrix here is the columns of input data used for the regression. In the case of the singly constrained model, a Poisson linear regression with fixed effects for the set of locations will generate the same coefficient estimates and predicted values as directly using nonlinear optimization (based on a multinomial distribution) for the multiplicative form from Wilson. The fixed effects from the Poisson linear regression is typically included into the design matrix using a binary indicator/dummy variable for each location, which causes the design matrix to become very sparse for even a moderate number of locations. Not an issue if you are using a different calibration technique, and as you mentioned here, it is more of a downstream issue with the function being supplied by the user. Would be interested to hear yours and @lenkahas thoughts on metrics once you've had a chance to discuss! |
I'm looking for feedback from anyone with experience of SIMs in terms of:
si_predict()
. Aim to add these packages to Suggests and put examples implementing them into articles/vignettes.si_to_od()
creating an 'analysis ready' (and modelling ready) data frame with all the variables from origins and destinations you could need.si_model_exponential_decay()
andsi_model_power()
for quickly getting people started and not having to define their own functionsCurrently (2022-04-22) the function used to predict interaction is called
si_predict()
and works like this:https://github.com/Robinlovelace/si/blob/d9ae80e683b316d619f3a8843f2a7d138c7d3b1f/README.qmd#L40-L53
That is likely to change to a tidy-eval framework in #10.
Previous questions (now mostly answered) related to this:
si_predict()
, perhaps with another function e.g. calledsi_train()
to train models (constrained/unconstrained)?fun
argument be anod
object (I'm currently thinking not as that arg is already insi_model()
, heads up @Nowosad)?si_gravity()
work? I'm thinking as simple as possible would be good, enabling commands such assi_predict(od, fun = si_gravity(m = origins_population, n = destinations_population, distance = distance_euclidean))
would be goodvar_p
)?constraint_p
The text was updated successfully, but these errors were encountered: