Wishlist for Ciw 3.0

The possibility of a 3.0 release opens up some possibilities, allowing some big changes that are not back-compatible, and some smaller internal changes. Below is a list of possible features or changes that might appear. Please use the comments below to discuss.

1. Remove ability to read in from yaml (reasoning: pyYaml does this for us and better)
2. Remove ability to write results to file (reasoning: pandas does this for us and better. Ciw records are already lists of NamedTuples with are easily compatible with pandas)
3. Baulking and rejection losses should recorded as DataRecords (exactly the same as how reneging and interrupted services are, for consistency)
4. Classes should simply be indices (no need for the string "Class 1", just index by the number 1)?
5. Add option for 'class_names' and 'node_names' in the Network object, so that the data records show these. This might make Ciw records more readable.
6. Ensure consistent using of current_time / next_event_time internally (I think current_time is better)
7. Rethink exact arithmetic (Decimal(3.2) + 4.1 = Decimal(7.3), so maybe no need for the increment_time thing
8. (If possible) simplify import_params.py (especially in terms of routing functions)
9. Replace ciw.dists.NoArrivals() with None (this is how reneging and dynamic classes handle no distributions)
10. Make it easier to choose Individual attributes to include in the DataRecords, e.g Q = ciw.Simulation(N, attributes_to_record=['successful_service', 'age']) (see https://github.com/CiwPython/Ciw/issues/205#issuecomment-1175267882 for how this is currently handled)

[geraintpalmer]

@drvinceknight that would be fantastic thank you

[lec00q]

May I add a couple of ideas?

1. Allow state-dependent reneging distributions
2. Allow general distributions for baulking
3. Allow to set “batching” at any node, that is, a mechanism to wait for a certain number of customers before being accepted/released, and accept/release all of them at the same time
4. A “wait-to-be-pushed” mechanism, that is, a customer stays in service indefinitely until the queue is filled and one more customer wants to join the queue, therefore it “pushes” all others in the queue and also the one who was in service is released
5. Parallel computations (which however is always tricky)

Hope it helps