# Flocking as in NatureOfCode

**URL:** <https://discourse.processing.org/t/flocking-as-in-natureofcode/28912>\
**Category:** Coding Questions\
**Created:** [March 27, 2021, 7:45pm UTC](https://discourse.processing.org/t/flocking-as-in-natureofcode/28912 "2021-03-27T19:45:17Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![manno](https://avatars.discourse-cdn.com/v4/letter/m/a6a055/32.png) [@manno](https://discourse.processing.org/u/manno)\
**Post date:** [March 27, 2021, 7:45pm UTC](https://discourse.processing.org/t/flocking-as-in-natureofcode/28912/1 "2021-03-27T19:45:17Z")

</div>

Question on flocking. In many examples (and also on [The Nature of Code](https://natureofcode.com/book/chapter-6-autonomous-agents/)) there’s something like:

```auto
 if (count > 0) {
      sum.div(count);
      sum.normalize();
      sum.mult(maxspeed);
      PVector steer = PVector.sub(sum,velocity);
      steer.limit(maxforce);
      return steer;
    }

```

In the ‘align’ as well as ‘separate’ code examples. Now the question: Why divide the vector by a scalar before normalizing it? Dividing only changes magnitude, and normalizing only changes the magnitude _and_ always has the same outcome (magnitude wise) regardless of any previous magnitude. So, why the division before the normalization? What am I missing here?

Kind regards,  
Manno

---

<div class="post-metadata">

**Author:** ![jb4x](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.processing.org/jb4x/32/789_2.png) [@jb4x](https://discourse.processing.org/u/jb4x)\
**Post date:** [March 27, 2021, 7:57pm UTC](https://discourse.processing.org/t/flocking-as-in-natureofcode/28912/2 "2021-03-27T19:57:15Z")

</div>

Hi manno,

Haven’t looked in detail but you are right, you could get rid of `sum.div(count)` and the result would be the same.

Maybe the initial idea was to take an average value and then it changed to be the maxspeed all the time 🤔

But as is, you can for sure get rid of the division line and it wouldn’t change anything.

---

<div class="post-metadata">

**Author:** ![micuat](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.processing.org/micuat/32/19407_2.png) [@micuat](https://discourse.processing.org/u/micuat)\
**Post date:** [March 27, 2021, 8:06pm UTC](https://discourse.processing.org/t/flocking-as-in-natureofcode/28912/3 "2021-03-27T20:06:23Z")

</div>

I guess it’s just a mistake; I mean perhaps a residue from something else. It may be helpful to make a pull request or send feedback to Dan. He sometimes makes these mistakes, and we all love him

> <https://twitter.com/shiffman/status/1150389671173775360>

Out of curiosity I changed the value to see what can potentially go wrong with this line. With this large value, sometimes boids are stuck depending on their position.

> <https://gist.github.com/micuat/66a965d4edc694adfd35a80d10e4f998#file-noc_6_9-pde-L150>

---

<div class="post-metadata">

**Author:** ![manno](https://avatars.discourse-cdn.com/v4/letter/m/a6a055/32.png) [@manno](https://discourse.processing.org/u/manno)\
**Post date:** [March 27, 2021, 8:22pm UTC](https://discourse.processing.org/t/flocking-as-in-natureofcode/28912/4 "2021-03-27T20:22:01Z")

</div>

Thanks @jb4x and @micuat .  
tbh, I had not even thought about the repo and communicating through that. Might do that, thanks

Very large numbers as the denominator are pretty rare I suppose. Having that size of ‘neighbourhood’ would not benefit the frame rate at least 🙂 .

Kind regards,  
Manno

---

<div class="post-metadata">

**Author:** ![paulgoux](https://avatars.discourse-cdn.com/v4/letter/p/b9bd4f/32.png) [@paulgoux](https://discourse.processing.org/u/paulgoux)\
**Post date:** [March 27, 2021, 10:25pm UTC](https://discourse.processing.org/t/flocking-as-in-natureofcode/28912/5 "2021-03-27T22:25:19Z")

</div>

From my understanding the flocking algorithm checks and takes the average velocity of a boid and the boids in its vicinity, hence the div(count) count being the neighbour of boids withina certain radius.

---

<div class="post-metadata">

**Author:** ![manno](https://avatars.discourse-cdn.com/v4/letter/m/a6a055/32.png) [@manno](https://discourse.processing.org/u/manno)\
**Post date:** [March 27, 2021, 11:37pm UTC](https://discourse.processing.org/t/flocking-as-in-natureofcode/28912/6 "2021-03-27T23:37:40Z")

</div>

Partially true @paulgoux. Flocking deals with getting an average velocity (to align your own to), an average position (to move towards to for cohesion) and an average ‘evasion vector’ (to separate).  
However, in calculating all this, after summing vectors, division is useless if you are going to normalize the vector immediately after. It is setting the length to some calculated value (division) after which you set it to be of length one (normalize), and nothing happens in between.

Vector math wise, you only need to divide by the ‘neighbour count’ for the cohesion. There you need an average position which you want to steer towards using seek. With alignment and separation the total vector is set to a certain magnitude (independent of the amount of neighbours that contributed to the total) to limit its ‘force’.