-
Notifications
You must be signed in to change notification settings - Fork 42
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
[Feature Request] Time/State-Dependent Baulking #234
Comments
Hi, I love this idea. In fact, the baulking function could just take in the simulation object itself, and then have access to any property of the system it needs, including the time? e.g.
What do you think? |
Thank you for considering my ideas! 😊 I can see how passing the simulation to Here is my thinking for the function signature I suggested. Using the I suppose another option would be something like
Further discussion on this is welcome! I am still unfamiliar with most of the mechanisms in Ciw, so I may be missing something. |
Implemented here: 9d00262 |
I noticed that
arrival_node.ArrivalNode.decide_baulk
is responsible for making a decision about whether to baulk an instance ofIndividual
.Here is the implementation:
Baulking is conventionally thought of as customers deciding not to join the queue if it is too long, which is may be why it was implemented this way. I first learn from the docs that the baulking function just takes the length of the queue and returns a probability of baulking.
Here is the example from the documentation:
That function actually uses
n
. We could of course make baulking functions that just ignoren
. Here is a frivolous example that we would not be interested in practice. In this case there is a probability of 1 that the individual will baulk if theint
of the unix time is prime, otherwise there is a 0.5 probability of baulking.But what is of practical interest to me is baulking that depends on time, or the individual's properties, or other properties of
next_node
, or even some entirely non-local properties. And I don't want to patch this unless I have to.How feasible is replacing
next_node.baulking_functions[self.next_class](next_node.number_of_individuals)
with
next_node.baulking_functions[self.next_class](next_node, next_individual)
?Having
next_node
available is a handy default behaviour and otherwise anything about time or state can be accessed vianext_individual.simulation
. It would allow for a form of "generalized baulking" where the reason for not joining the queue could be for reasons other than the length of the waitlist.The text was updated successfully, but these errors were encountered: