Skip to content
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

TypeError when using infinite servers in conjunction with schedules #83

Open
alcarney opened this issue Sep 25, 2016 · 5 comments
Open
Labels

Comments

@alcarney
Copy link
Contributor

If I use the following parameter dictionary:

params = {'Arrival_distributions': {'Class 0': [['Exponential', 3.0]]},
          'Service_distributions': {'Class 0': [['Exponential', 5.0]]},
          'Transition_matrices': {'Class 0': [[0.0]]},
          'Number_of_servers': ['Inf']
}

Ciw works quite happily, however if I use this dictionary:

params = {'Arrival_distributions': {'Class 0': [['Exponential', 3.0]]},
          'Service_distributions': {'Class 0': [['Exponential', 5.0]]},
          'Transition_matrices': {'Class 0': [[0.0]]},
          'schedule': [[5, 'Inf'], [10, 0]],
          'Number_of_servers': ['schedule']
}

then I get the following stack trace:

Traceback (most recent call last):
  File "crossroads-traffic-lights-sim.py", line 38, in <module>
    Q = ciw.Simulation(N)
  File "/home/alex/Blender/Ciw/env2/lib/python2.7/site-packages/ciw/simulation.py", line 48, in __init__
    for i in range(network.number_of_nodes)]
  File "/home/alex/Blender/Ciw/env2/lib/python2.7/site-packages/ciw/node.py", line 36, in __init__
    self.node_capacity = node.queueing_capacity + self.c
TypeError: unsupported operand type(s) for +: 'float' and 'str'

I see the error using both Python 2 and Python 3

@geraintpalmer
Copy link
Member

Yes, server schedules and infinite servers are incompatible at the moment sorry!
At the moment can't think of a way around this. But will add a note to the documentation to clarify. Apologies for this. Keeping this issue open.

@drvinceknight
Copy link
Contributor

Perhaps remove the bug label and add a wontfix label?

@geraintpalmer
Copy link
Member

Perhaps remove the bug label and add a wontfix label?

It's wontfix at the moment. But here may be a way of refactoring everything in the future and making this work. This is far from a priority though.

@drvinceknight
Copy link
Contributor

Yup, but I'd suggest going with a wontfix label for now so that this doesn't look like a long standing bug. (If something is an actual bug it implies that it's broken and needs to be fixed.)

@geraintpalmer
Copy link
Member

👍

@geraintpalmer geraintpalmer added wontfix and removed bug labels Apr 2, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants