Preventing endless loops in Yampa/Animas with SF's depending on each other

Question

I'm trying to understand how this functional reactive programming works, and I have run into a problem. I am trying to create a boid simulation, but I'm starting out slowly, and I have for now defined a boid as a function taking a starting position and creating a signal function from a position to a position, where the input is the point it is moving towards and the output is the current position:

type Position2 = Vector2 Float

boid :: Position2 -> SF Position2 Position2
boid s = loop (arr (uncurry seek) >>> integral >>> arr (^+^ s) >>> arr dup)

the seek function takes two inputs (because of the loop). The current position and the target position. Then it just creates a vector pointing from the current position towards the target position with a magnitude of 50 i.e. the velocity. Then the velocity is integrated and the starting position is added. In the end the signal is split into two, so one can become the output and the other can loop back into the seek function.

Now i can define boids like this:

aBoid = constant (vector2 500 500) >>> (boid (vector2 600 60))
bBoid = aBoid >>> (boid (vector2 3 4))

Here aBoid seeks towards the point (500, 500) and bBoid seeks towards aBoid.

My problem is, when i want the two boids to seek toward each other. When i do this:

aBoid = bBoid >>> (boid (vector2 600 60))
bBoid = aBoid >>> (boid (vector2 3 4))

The program just prints: ProgramName: <<loop>> which I assume means that it goes into an endless loop.

I have also tried to use the par function like this:

sim :: SF a [Position2]
sim = loop (arr snd >>> par route [boid (vector2 10 10), boid (vector2 100 100)] >>> arr dup)

here the route function just maps the output of each boid to the input of another one (like zip, but with an offset of 1)

This also gives the <<loop>> message.

I would think that having objects depend on the state of each other should be a pretty common problem when dealing with reactive systems, so I hope there is some elegant solution.

I should add that I find this FRP thing very hard and often confusing, so I'm not really sure if i even make sense at all ;)

Kink

Answer 1

So with a little help from ehird i came up with something that works.

The code is as follows(here using 3 boids instead of 2):

sim :: SF a [Position2]
sim = loopPre [zeroVector, zeroVector, zeroVector] (
    arr snd >>>
    par route [boid (vector2 10 10), boid (vector2 100 400), boid (vector2 500 500)] >>>
    arr dup)

Here the route function works the same as the one i described in the question.

By using loopPre instead of loop i can give each boid a starting position, which solves the problem. I think the reason ehird's solution did not work, was that some plumbing is required when running several signal functions in parallel, which the par function takes care of.

An answer from someone who is 100% sure whats going on would be appreciated :)

Edit

This implementation of sim is a little prettier:

sim :: Int -> SF a [Position2]
sim num = loopPre (take num (repeat zeroVector)) (
    arr snd >>>
    par route (randomBoids num) >>>
    arr dup)

Where randomBoids num generates num random boids.

Kink

BTW, take n . repeat ≡ replicate n :) – Borstal

Answer 2

I'm not really familiar with Yampa/Animas, but it seems like the problem is essentially that you have a recursion with no base case; you've described the evolution of the system, but not how it starts out.

How about:

aBoid = bBoid >>> boid (vector2 600 60) >>> iPre (vector2 0 0)
bBoid = aBoid >>> boid (vector2 3 4)

so that aBoid starts out at (0,0), and then the feedback loop begins the next instant? This is assuming my understanding of iPre is correct...

(The pipeline may be easier to understand if you imagine it with (.), the flipped version of (>>>).)

Borstal

I agree that i looks like something that should work, unfortunately it does not. However your answer made me look at the function loopPre which i now use with the par approach and this works. From looking at the implementation of loopPre i get the idea that the problem is that iPre should be on the input side and not the output side, but i havent tested that. – Kink

Ah; does it work if you put the iPre before the bBoid or just after it (before the boid)? That way it will set the initial value for bBoid instead, I think. Glad to know you got it working; hopefully I can edit my answer into something that works :) – Borstal

I can't really get it to work. However i do suspect that it might be because working with signal functions in parallel requires more than just defining the signal functions in terms of each other. It seems you actually need some plumbing for splitting a signal up, feeding it into each signal function and then collecting the output again as a single signal in a meaningful way. Therefore i have come to the conclusion that using a function like par or pSwitch is the correct solution. If you were to use iPre, which i indirectly do through loopPre, it seems it should be on the input side. – Kink

Fair enough. It seems like this could be solved with observable sharing, to rewrite the recursive definitions with such a construct. You should post and accept your solution to help others in the future :) – Borstal