Using FRP to model road network with jams
Asked Answered
L

1

6

I am currently trying to understand arrows and FRP, and I came upon a question, which I cannot seem to map to FRP, namely how to model a road network.

I thought I could model a road network as Arrows, where each Arrow represents a road segment. It accepts streams of cars at locations and times and produces the same type, albeit with different locations and times.

So far so good. But this model does not take into account, that segments may get jammed. While each segment could well respond to heavy traffic and delay cars more and more, the more congested it gets, there would be no backwater effect, i.e. the jam would not propagate backwards to other road segments.

I suspect I am applying too much OO thinking here, instead of focusing on what needs to be computed, but I cannot get it right in my head.

  • How can I model a road network with Arrows such that backwater effects are taken into account?
Lawgiver answered 21/5, 2015 at 6:27 Comment(5)
what exactly is the backwater effect - is this just traffic jam that will propagate backwards through your roads? - as a side note: while interesting this question will most likely be to broad for this kind of FAQ site - have anything to show yet and a concrete problem (for example: how did you model your roads - in code ;) )Dag
Yes, the backwater effect is as you describe. No, I don't have any code to show, because I believe I must solve this conceptual problem first.Lawgiver
How much discrete systems modeling have you done? Have you used software like Arena before (it's the one I was exposed to at uni, but there are certainly others)? In order to encode something like this into arrows or FRP, you're going to need to spend a lot of time thinking about the model you want to use and experimenting with how to get it modeled in one of these paradigms. You could also consider something like Pipes, as it has bidirectional communication for each channel.Janae
perhaps "backpressure" is a better term.Fetterlock
Why wouldn't it propagate backwards? It seems that you only need the simulation function to know whether the subsequent segment is full, and if so, then not let any cars exit a segment. Perhaps you should really show some code so that we can see your mental model and how it would prohibit propagation.Corydon
X
2

The problem is that in arrows and in FRP the flow of information is in general unidirectional. Think of a FRP arrow like a piece of digital circuit. The output of a circuit element doesn't depend on what's connected to it - it just "offers" the output to whoever is interested. This is also described visually in Primitive signal functions in the Yampa overview:

Yampa - signal functions

Your situation is different. The state of a segment of a road depends on both the next and previous segments - cars are comming from the previous one, but if cars can't leave to the next one, they have to stay. It's just like a pipe with running water. If you close the pipe at its end, water stops, and the information about that propagates backwards through the pipe at the speed of sound in water.

So each road segment will need to have 2 inputs: One saying let's say how many cars can the following segment accept, and how many cars are coming from the previous segment (which should always be less or equal to the number of cars the segment can accept at the moment). This means that the FRP signal flow will be actually circular. For this you'll need loops, shown in the last image in the above diagram, which are captured by ArrowLoop type-class. Most likely you'll have a custom binding function for road segments that'll be internally creating the required loops. Note that there must be a time delay in a loop, to prevent it from diverging, which makes sense as it takes some time for cars to go from one segment to another.

(I'll perhaps expand the answer with an example, if I'll have more time.)

Xuthus answered 22/5, 2015 at 8:41 Comment(1)
Petr, you seem to completely understand my problem. I had similar thoughts: A segment needs two inputs! What I am asking myself is the following: who says that the computation needs to return cars? The computation does not necessarily have to follow the flow of cars, but could compute "something" from the upstream and downstream sides of a segment. But I am unable to finish this train of thoughts.Lawgiver

© 2022 - 2024 — McMap. All rights reserved.