Randomness in Codea?

Questions
1

Hi there,

I’m busy programming a pathfinding algorithm, and currently testing with multiple instances trying to find a path, not permitting them to pass through each other.

Something that occurred while testing, was that sometimes, under the exact same conditions, different paths were calculated. I would for example start the program, see the instances follow a path, hit restart, and then different paths were chosen.

I didn’t use any kind of random numbers in my code (except for coloring), so how isn’t this the same every time I execute the program? Did anybody else ever encountered this sort of behavior in Codea?

2

@Prynok If you mean math.randomseed, no I’m not.

Also, I removed the use of the random function in the coloring, and even then it occurred. That makes sense, since it’s got nothing to do with the path calculation.

3

@Kjell to make those random colors, are you using the random seed?

4

An example: I start with this situation, and end up with either this or this. In the mean time, nothing in the code has changed.

5

@Kjell. this is a kind of an old game. I only seek to show the application of math.randomseed ()

   function Enemy:draw()
    math.randomseed(self.radio)
    -- CIRCLES fill
    fill(math.random(255),   --R
         math.random(255),   --G
         math.random(255),   --B
         math.random(255))   --A
   end

example: in a sequence of balls you can put a random color for each ball, and the math.randomseed() can send the overall radius of the balls.

there are many ways to use math.randomseed()

6

Without seeing the code it’s hard to say anything reasonable.

7

Here you go: K.txt

The pathfinding part can be found in the ‘Object_move’ tab.

8

@Kjell I’ve had a look at your code and run it a few times. If you slow it down (intriguingly, by increasing the speed!) then you can see that the divergence happens when the two blocks meet. Then one has to move aside and let the other one through. The two different outcomes are from the two different possibilities there.

I’ve only had a brief look at your code, so this is somewhat speculative, but I think that what is happening is that the tweens which govern the behaviour of the pieces are not consistently established. Codea has to do some work before it sets up one of the tweens, I think, and that can take slightly different amounts of time each run. I’m not too sure about how the tweens code works, but I guess that it gets checked once every draw cycle. This can also vary between runs. So there are a few things that can vary between runs and which mean that a different tween “fires” when the two blocks meet.

So my guess is that your method is highly sensitive to initial conditions because the decision on which object to move aside depends on which one notices the blockage first, and they both check almost, but not quite, simultaneously.

9

@Andrew_Stacey Thanks for your time looking into the code! As you said, it probably must be the tweens. Although I still think it’s behavior one wouldn’t expect in this situation, since the initial conditions are always the same with different outcomes. Maybe the time calculation in Codea isn’t that precise.

But it isn’t going to be a big problem, since it only occurs when there is one small passage. I’m planning on using this in wide open spaces. It still needs some polishing though, because in some situations they still pass through each other.

Anyway, thanks for your help. Any tips on motion planning are always welcome!