I’ve always been enchanted by the shapes and figures found in nature. Noticing the intricate patterns present in trees, leaves, animal coats, and our own fingertips led me to want to investigate these patterns from a mathematical and computing perspective.
An early and still useful entry point to mathematical modeling is Alan Turing’s 1952 paper The Chemical Basis of Morphogenesis, where he introduced a set of equations to model changes over space and time that allow us to describe, discover, and replicate patterns found in natural systems.
These are known as reaction-diffusion systems and they can be used to model and study the behavior of many different phenomena, such as the variation of concentration of one or more chemical substances.
And because I believe that the difference between words and code is like the difference between telling and doing, let’s implement these models and create some patterns with the power of computability!
Reducing the system to one substance
When ink is poured into water, the ink moves from higher concentrations to lower. This process is called diffusion. It is normally thought of as a smooth and stable process, and can be mathematically modeled with the following equation:
Understanding the formula by implementing it
What we are trying to do is to define a concentration value for each point in space, which will change over time:
C(x, t)
Let’s imagine time is discrete: t in [0 1 2 3 4 5 6 7 …]
For each moment t and for each point in space x, we are defining C, the concentration of ink. We define C according to a constant that represents the rate of diffusion D and a value obtained from how the concentration in x changed according to its neighborhood in the previous step N(x, t-1); for example, by taking the difference of the value of x and the average of its neighborhood at t-1.
So our discrete interpretation of the formula would look something like this:
C(x, t) = D * N(x, t-1)
Three.js + WebGL implementation
To create a visualization of this system, it is important to note that the previous state will be needed to compute the actual values. In other words, we will be using the output of the previous step as the input of the current one. These are known as feedback systems and can be thought of as a sequence of frames:
Each white square will show the color values at each position of the screen, and the black arrows are the algorithm for updating those colors at each frame.
In a diffusion process specifically, each pixel will be mapped to a color value representing the concentration, or saturation, of that color.
I used WebGL to implement the diffusion algorithm and Three.js to render each frame. I used the ping pong rendering technique, which allows us to use the output of each rendering pass as input for the next one.
Here’s how I defined the general structure of the Three.js script:
Setting up the scenes:
var camera,renderer,scene;
function setupMainScene(){
...
}
var bufferScene ,ping ,pong, renderTargetParams;
function setupBufferScene(){
...
//initialize textures ping and pong
}
Initializing the scenes:
var bufferUniforms, bufferMaterial, plane, bufferObject;
function initBufferScene(){
bufferUniforms = {
...
};
bufferMaterial = new THREE.ShaderMaterial({
//uniforms, and shaders involved
});
plane = new THREE.PlaneBufferGeometry( 2, 2 );
bufferObject = new THREE.Mesh( plane, bufferMaterial );
bufferScene.add(bufferObject);
}
var finalMaterial,quad;
function initMainScene(){
finalMaterial = new THREE.MeshBasicMaterial({map: ping});
[*]
quad = new THREE.Mesh( plane, finalMaterial );
scene.add(quad);
}
Rendering the scene:
function render(){
requestAnimationFrame( render );
//Ping to buffer scene
renderer.setRenderTarget(ping);
renderer.render(bufferScene, camera);
renderer.setRenderTarget(null);
renderer.clear();
//Swap ping and pong
let temp = pong;
pong = ping;
ping = temp;
//Update uniforms
...
//Draw to screen
renderer.render( scene, camera );
}
Understanding how ping pong buffers work
- STEP 0: Set up two scenes, the main scene and the buffer. Initialize two textures, ping and pong, one for each respective scene.
- STEP 1: Set texture ping to be rendered in the buffer scene.
- STEP 2-3-4: Swap textures.
- STEP 5: Update scene materials.
To experiment with the diffusion algorithm and visualizations, you can check out my code here and try the demo here.
Going deep into reaction-diffusion systems
We already have a sense of what diffusion is, via the example of one substance (such as ink) spreading through water. Now let’s suppose that the system has more than one substance.
Picture spatially how the substances move around. Each of them will be diffusing at a different rate, going from areas of high concentrations to lower ones at a certain speed.
There would also be areas where both substances are present, and we have to account for how they interact or react to each other.
Going back to Turing’s article: he described a system with two substances, and he introduced the name morphogen for a substance in such a system.
In the reaction, morphogens work in opposition to each other, in what’s known as a growth-decay or activator-inhibitor relationship.
If the reaction rate of the decay is faster than the growth rate, you would expect the system to behave smoothly and stably as in diffusion. This is where Turing introduced an amazing idea: “diffusion-driven instability.” In this case, the diffusion rates of different substances carry an asymmetry throughout the solution, so that under certain conditions these instabilities cause the formation of patterned concentrations.
Reaction-diffusion pattern in shells
Reaction-diffusion pattern in a fish
Reaction-diffusion pattern in a fish
To learn more, I suggest reading about pattern formation in animal skin.
Three.js + WebGL implementation
To visualize reaction-diffusion systems, we can use the same ping pong technique described above, with the difference that at each frame there can be several iterations of the algorithm (arrows going down).
Using the Gray-Scott model
The Gray-Scott model is a simulation of a reaction-diffusion system of two virtual chemicals in a two-dimensional grid. This tutorial by Karl Sims explains how the algorithm works. He describes the simulation in terms of the following equations:
To keep this consistent with our diffusion system interpretation, let’s again imagine that time is discrete [0 1 2 3 4 5 6 7 …].
Essentially, for each cell(x,y) in your grid you have A concentration of one chemical and B concentration of the other. And at each time step, both values will be updated according to:
- the previous concentration values;
- how each diffuses; and
- how the two react.
The reaction depends on two constant values: the feed and kill rate. Only certain combinations of these values will evolve into a pattern. This is a great resource to explore those values.
In the link above, you will see the following grid where the horizontal axis represents the kill values, and the vertical the feed values. By clicking over {kill, feed} cell, you can see how the system will evolve.
Only the green-ish area represents the combinations of rates that lead to pattern formations, which are the ones we want to explore in our simulation.
You can also experiment with different values using Pearson’s classification.
Following my interest in natural patterns led me to implement an environment where math and art converge, each enriching the other and inspiring me to explore new creative practices where they intersect. It was such a rewarding experience, as I have always been fascinated by both disciplines but never had the chance to merged them into one — until now!
Try it yourself!
You can try the demo here!
Gray-Scott model:
The code is available here. For rendering just patterns, the interpolation value should be 0. Note that for visualizing the Gray-Scott model, I changed from MeshBasicMaterial to ShaderMaterial since I added an extra color shader.
Mapped on 3D surfaces:
I added a vertex shader for meshing to geometry. Check out the experimental code here.
Gray-Scott model mixed with video capture:
Analog Pedagogy: Teaching Programming in a Juvenile Detention Center
by Pedro Baumann
In 2016, I started Vía Código, a non-profit in Lima, Peru, that teaches incarcerated teenagers to code. As you might imagine, an environment like this poses significant obstacles to education. One challenge is that our students have experienced a lot of trauma, which incarceration exacerbates. They’re not allowed to bring printed material, notebooks, or writing implements into their barracks, so their learning experience is limited to the classroom. Furthermore, they don’t have access to the internet, which presents particular challenges when learning to code!
We knew from the start that we had to develop a curriculum that took these factors into account and was rigorous enough to help students become proficient developers. It had to be engaging and useful from the beginning. Thus, we created a set of core principles that guide our pedagogy, which we’ve continued to refine over time.
First Principle: You are capable of crafting your own future
Remember how amazing you felt the first time you wrote a small piece of software? Most of our students have been told by their families, teachers, and other authorities that they are dumb or violent, that they don’t have many options, or that the world is not built for them, so they shouldn’t even try to be a part of it.
Suddenly, when they program, they feel powerful. They can talk to the machine and it understands. Leveraging this transformative effect helps them develop their confidence and self esteem, and it also helps us build trust in our relationships. Why would we give them such power if we were only trying to use them?
Second Principle: The computer is stupid
In the first iteration of the program, we encountered a lot of frustration. Viacoders were used to seeing themselves as bad students and thinking they weren’t intelligent enough to learn.
We decided to develop a computer science module as the introduction to the program. Inspired by Harvard's CS50, we created three sessions: how binary works, hardware basics (in a CPU optimization exercise, one of them came up with the meltdown bug!), and intro to networking.
Starting with these fundamentals changed everything. Now, instead of thinking they weren’t intelligent enough to “talk computer language”, students realized that maybe the computer wasn’t intelligent enough to understand them and that they had to simplify their instructions.
Third Principle: Combine human development with the technical content
Because learning is so tied to personal growth, we integrate the technical and personal development aspects of the program as much as possible. We always have at least one staff member in the classroom whose job is to help students deal with frustration, mediate conflict, and work through problem-solving strategies.
Within this massively toxic environment, we take every opportunity to introduce other perspectives. In the unit on semantic HTML, for example, students built a blog about famous women programmers, the role of women in trap music, and about Laboratoria (a Peruvian NGO that teaches web development to vulnerable women). This also helped them develop their critical thinking skills.
Fourth Principle: Understand the value of your knowledge
After three years, most employees of the detention center still think we’re teaching Microsoft Office. Being incarcerated in an environment where no one else understands what programming is about is alienating. To combat this alienation, we’ve developed different strategies that bring some real life, outside recognition to their accomplishments.
We started inviting guest speakers on Saturdays to give the Viacoders special workshops on topics like CSS animation, game development with Construct2, UX research, branding, etc. A respected Peruvian dev school, Area51, agreed to assess the students and issue official diplomas. All but one student passed the tests!
We invited the students at Laboratoria to do pair programming inside the detention center, which turned out to be by far our best idea! The Viacoders were excited because they had researched Laboratoria, and the Laboratorians admired the Viacoders for being able to program without using the internet. We also organized demo days where government officials and hiring managers from software companies came to meet the students and see their portfolios.
Finally, we started a pen pal program where each student was assigned a mentor to correspond with. For some students, it was hard to write to a stranger; for others, it was unbelievable that someone from another country would care enough about them to write them a letter, so they thought them fake at first. But some of them kept in touch way beyond the course!
Our biggest finding is that programming is a great tool not just to increase economic opportunity and get better jobs, but to develop cognitive skills and leadership capacity. Working on this project has been an incredible experience for everyone on the Vía Código team. More importantly, it’s changed many of our students’ lives. If you want to learn more about us, please feel free to contact me!
What Happened to Women in Computing?
by Carolina Luz Hadad
Sometimes people ask why Chicas en Tecnología, our NGO, tries to “force” teenage girls to choose a profession that they "don't like.” The reality is that an individual’s path toward a vocation is encouraged (or discouraged) by a variety of complex social and cultural factors. My co-founders and I are writing a book about how these forces -- via parenting, education, peer group pressures, and workplace dynamics -- prevent women and other marginalized groups from entering, staying in, and advancing in tech. In this piece, I want to explore a lesser known fact: women were the majority in the early days of computing, yet we make up less than 20% of programmers today.
Women have played key roles in the advancement of computing from the beginning. Ada Lovelace, writing in the 19th century, is widely recognized as the first programmer. The early ENIAC programmers, and the Argentine Clementina programmers, were all women. Katherine Johnson and Mary Jackson at NASA helped send humans to space for the first time. For decades, the number of women entering technical careers grew much faster than the number of men, but this percentage first stagnated and then crashed precipitously in the 1980s.
In Argentina we see the same trend, even more pronounced. Women were 75% of computer science students in the ‘70s and the proportion steadily decreased to 11% today. How did this change so much?
In the ‘60s and ‘70s, programming was advertised as a profession “suitable for ladies''. The book ABC de la Chica de Hoy, published in 1973 in Spain and very popular in Latin America, listed programming as a good career option for women and noted: “Nowadays women can have any career, if they can adapt to it. The question ‘why bother, if I’m getting married soon?’ shouldn’t influence your thinking because what if your husband had an accident and became unable to work? Who would feed the children in that case?” Similarly, in an interview with Dr. Grace Hopper in the April 1967 issue of Cosmopolitan magazine, she compares programming to “planning a dinner”.
Yet when computers entered the personal consumer market and became everyday tools for work and play, they were marketed to… drum roll… boys! In the TV commercial for the IBM 510, launched in 1977, ten men explained how computers helped them grow their business and work efficiently. Meanwhile, the one woman emphasized how difficult her decisions were and how much the computer helped her think. You see similar contrasts in ads for home computers, like the Commodore 64, and when it was advertised as a game object, it was always boys (and not girls) depicted playing with it.
As the industry grew, programmers became more in demand and better paid. Companies needed to hire people, fast. But how to define what skills to look for in applicants, if the area was totally new? An investigation by the Washington Post discovered that, in an effort to demystify that process and improve hiring, the software company System Development Corp. (SDC) hired two psychologists to create a profile of the best programmers. They interviewed 1,400 engineers — 1,200 of them men — and developed a personality profile to predict who would be the most successful programmers. Since almost all of the interviewees had been men, the biased evaluation concluded that men were the ideal candidates for engineering jobs.
Furthermore, the test concluded that extroverts and empathetic people were less valuable candidates. SDC was highly influential in the industry at that time and many companies copied their developer profile for their job searches. Over the years, this contributed to a vicious cycle: the hiring process favored men, cementing their dominance in the industry and fueling popular perception of engineering as a domain for socially awkward men.
This stereotype was taken up in mass media as well. In the 1980s, TV series and films that portrayed women in different professions -- rock stars, FBI agents, doctors, and more -- began to become popular. But nearly every time a computer was seen on the screen, it was operated by a "nerd": always a man, almost always white, shy, weird, intelligent but not very socially skilled. The nerd is often characterized as having a good heart or good intentions, which justify his misogyny. In many of these stories, nerds use their computer knowledge to solve their problems and win over a girl.
A prime example of this is the 1985 film “Weird Science,” where two high school nerds use their computer to create a stunning woman who teaches them how to talk to girls. Young boys who grew up watching this representation of women as objects and computers as tools to acquire them didn’t question it when their professors taught them image processing using a cover of a Playboy magazine.
The argument that women don’t become programmers because it doesn’t interest them has no historical support. Women have always been computing pioneers. But over the years, women were pushed out of the profession for social, political, and economic reasons. Those who stayed faced the challenges of discrimination, disrespect, disparities in pay and seniority, and often hostile work environments. Understanding the history of how and when women were excluded from the field can help us figure out how to reverse this trend and build a more inclusive tech industry -- not just for women, but for everyone.
