MATLAB Community

Agent vs. Agent: The MATLAB Programming Contest Revisited

Ned Gulley — Thu, 02 Apr 2026 15:42:20 +0000

Many years ago we ran an online MATLAB Programming Contest. It was fun! We had a contest once every six months or so from around 2000 to 2010. Fun side note: after that experience, we wanted to build a coding game that ran continuously rather than in discrete bursts. That's how Cody came about.

Here's how the original contest worked. Players were given a difficult optimization problem to solve (something NP-hard like the Traveling Salesman Problem). They would submit a function that would be tested against a hidden test suite and given a score that combined the quality of the optimization (lower is better) and the speed of the calculation (lower is better). Once scored it would appear on the leaderboard with the code freely available for all to see and use.

In other words, it was an open source programming contest. This had some big implications. Let's say your code was in the lead and someone modified a single line to make it go a tiny bit faster. BOOM! That person is crowned as the new leader. Seems unfair, huh? Players found this situation irritating but also very motivating. Getting humans to cooperate on improving the same code is hard. These rules ended up being an excellent social engine to drive cooperative coding. We saw some amazing results, with talented players around the world losing sleep to stay atop the leaderboard.

That old contest has faded into the past, but I always felt like we had stumbled onto something special. I never forgot about it, and the rise of AI programming gave me an excuse to revisit the idea. Only this time the competitors would be AI agents.

I hadn't created anything with agents before, but I opened up Claude Code and just started describing what I wanted. Within a few hours, I had a working version.

Here's the result. In the top left, there's a leaderboard where we see entries that have been submitted by various players (agents). I have created multiple players, and each one has its own personality. There's the Innovator, who always want to create something brand new. The Tweaker likes to take other people's entries and tune them. There's also a Speed Demon and an Analyst. Each of these players has a file to describe their personality and another file that acts as a notebook for them to keep notes as they play. It's fun to get some insight into what they're thinking.

Here's the score plot where you can see the improvement of the score over time. Incidentally, it resembles a similar plot from Andrej Karpathy's recent work on autoresearch. Indeed, the ideas are quite similar. You can think of this robot contest as an adversarial agentic optimization arena. It works well.

Following the contest was a little bit of a challenge because all this code comes flying in so quickly. So I made another agent called the Commentator. Whenever the lead changes hands, the Commentator writes an enthusiastic post in the spirit of a sports commentator. Example: "Tweaker snatches the lead from Innovator with a surgical strike!" It also gets into some of the details of of what changed in the code.

This agentic programming contest was a fun experiment, and it points to how we might coordinate agents and generative AI to do computational work in the future.

Analyzing Cody Solutions – A Guest Post

Ned Gulley — Wed, 28 Jan 2026 19:51:58 +0000

Cody is a game that helps people learn how to code in MATLAB. But something funny is going on these days. All of us, you and me and your neighbor's cat, now have instant access to a magic Cody-solving machine. What's the point of struggling with a Cody problem if you can push the big EASY button and make an AI language model solve it for you?

Why bother, right? It's kind of like chess. Chess tournaments were once used to determine the best player. But now we know better: chess tournaments determine who is the best HUMAN player. A computer can now thrash a grandmaster without breaking a virtual sweat. While we're at it, what's the point of Olympic sprinting when a Thomson's gazelle can outrun any human? Why learn to play the piano when Spotify will play any tune you care to name?

The point is this: Human skills and human competitions are still rewarding. You know it because you feel it. It's still worth learning how to solve a problem in Cody, even if a Thomson's gazelle can solve it faster.

Sorry, I meant to say "even if Claude Code can solve it faster." Although, no disrespect to the gazelles in our readership.

But even taking this into account, there's still a place for AI in this picture. Computers are helping human experts play better and more innovative chess. Better and more innovative Go. Approached in this spirit, AI can help us humans learn even more from Cody problems.

With this in mind, I've asked a guest writer to join us this week. I gave Claude Code access to all the correct community-generated solutions to Cody Problem 61060. This problem, entitled "Popular Word Game Distance", was part of the recent Cody contest. My prompt to Claude Code went like this:

Analyze all the solutions to this problem. Group them by algorithmic strategy. Then pretend you are a human solver that is submitting increasingly sophisticated solutions. Describe your path and what you learned along the way.

Claude's response, masquerading as a Wordle-playing human, is below. I don't agree with everything it said, but I found it entertaining and insightful all the same.

Before you read it, I suggest you try to solve the problem yourself. Then see what you think of Claude's analysis.

Popular Word Game Distance

How I Solved Problem 61060

My Journey from First Solution to Code Golf Champion by Claude Code

When I first read this problem, I thought: "Okay, this is basically Wordle scoring." I play Wordle every morning, so the rules felt familiar—but implementing them? That took some thinking.

Let me walk you through how my solution evolved, from my initial "just make it work" version to increasingly elegant (and shorter!) approaches.

Attempt 1: The Straightforward Two-Pass Solution

First, I made sure I understood the problem.

The rules are:

Green (0 points): x(j) == y(j) - same value, same position
Yellow (1 point): x(j) == y(k) for some k ≠ j - same value, different position
Black (2 points): No match at all
Critical rule: Each element of y can only be matched ONCE
Precedence: Green matches happen first, then yellow (left to right)

That last rule about precedence is crucial! If x = [3 3] and y = [3 4], the first 3 gets the green match, and the second 3 is black (not yellow), because y(1) is already used.

I decided to implement it exactly as the problem describes: two passes.

function d = PWGdist1(x, y) 

 % My first solution - clear and correct 

 n = length(x); 

 score = 2 * ones(1, n); % Initialize all to black (2) 

 y_used = false(1, n); % Track which elements of y are used 

 % Pass 1: Find all green matches (exact position) 

 for j = 1:n 

  if x(j) == y(j) 

   score(j) = 0; % Green 

   y_used(j) = true; % Mark this position as used 

end

end

 % Pass 2: Find yellow matches (wrong position, but value exists) 

 for j = 1:n 

  if score(j) == 2 % Only check if not already green 

   % Look for x(j) in unused positions of y 

   for k = 1:n 

    if ~y_used(k) && x(j) == y(k) 

     score(j) = 1; % Yellow 

     y_used(k) = true; % Mark this position as used 

     break; % Only use first match 

end

end

end

end

 % Sum up the total distance 

 d = sum(score); 

end

I tried x = [4 3 2 4 2 3 1] and y = [3 1 2 4 1 4 4] from the example. Got 7. Perfect! 

This works, but it's pretty verbose. The nested loop in Pass 2 bothers me. MATLAB has better ways to find elements. Let me refactor.

Attempt 2: Two-Pass, But More MATLAB-y

I realized I can use find() instead of that inner loop:

function d = PWGdist2(x, y) 

 n = length(x); 

 score = 2 * ones(1, n); 

 y_used = false(1, n); 

 % Pass 1: Green matches 

 for j = 1:n 

  if x(j) == y(j) 

   score(j) = 0; 

   y_used(j) = true; 

end

end

 % Pass 2: Yellow matches 

 for j = 1:n 

  if score(j) == 2 % Only if still black 

   % Find first unused position in y with matching value 

   k = find(~y_used & y == x(j), 1); 

    if ~isempty(k) 

     score(j) = 1; 

     y_used(k) = true; 

end

end

end

 d = sum(score); 

end

Better! The logic is clearer, and that nested loop is gone. Metric is 109. Not bad for a clear, readable solution.

Attempt 3: Wait, Why Two Passes? Let's Get Greedy!

As I looked at my two-pass solution, I had a realization: What if I just remove the green matches entirely, then process what's left?

Think about it:

Green matches contribute 0 to the distance
They also "consume" elements from both x and y
If I remove them first, I only need to deal with potential yellow/black matches

Here's the key insight: After removing greens, every remaining element is either:

Yellow (1 point): Found in remaining y → remove from y after matching
Black (2 points): Not found in remaining y

Greedy Loop Implementation

function d = PWGdist3(x, y) 

 % Remove all green matches first 

 green_mask = (x == y); 

 x(green_mask) = []; 

 y(green_mask) = []; 

 % Start with worst case: all remaining are black 

 d = 2 * length(x); 

 % Check each remaining element of x 

 for i = 1:length(x) 

  % Is x(i) in y? 

  idx = find(y == x(i), 1); 

  if ~isempty(idx) 

   % Found! It's yellow, not black 

   d = d - 1; % Change from 2 (black) to 1 (yellow) 

   y(idx) = []; % Remove from y so it can't be matched again 

end

end

end

This is cleaner! Single loop, clear logic. Metric: 74.

But wait... I'm modifying the length of vectors inside a loop. That makes me nervous. Let me test thoroughly.

Example case still gives 7.  Test: x=[1 1 1], y=[1 2 3] gives 4.  Test: x=[3 3], y=[3 4] gives 2. 

Excellent! This works.

But I can make this more compact. Instead of looping over indices, loop over values directly:

function d = PWGdist4(x, y) 

 v = x ~= y; % Logical mask for non-greens 

 d = 2 * sum(v); % Start with all black 

 y = y(v); % Keep only non-green y's 

 for val = x(v) % Loop over non-green x values 

  idx = find(y == val, 1); 

  if ~isempty(idx) 

   d = d - 1; 

   y(idx) = []; 

end

end

end

Nice! The for val = x(v) is more compact than indexing. Metric: 61. Pretty good!

Attempt 4: The Breakthrough - Think Mathematically, Not Procedurally

After submitting my greedy solution, I looked at the leaderboard. Someone had a solution with metric 37! How?!

I read their code (credited to Takumi) and had a genuine "aha!" moment. They weren't simulating the game at all. They were counting.

The mathematical insight: Think about it differently:

What's the maximum possible distance? 2 * length(x) (if everything is black)
How much do we reduce it? By the number of matches (green + yellow)
Green matches reduce by 2 (from black to green)
Yellow matches reduce by 1 (from black to yellow)

But here's the trick: How many total matches (green + yellow) can we have?

For each unique value in union(x, y), the number of matches is limited by:

min(count in x, count in y)

If x has three 5's and y has two 5's, we can match at most two 5's.

The Histogram Approach

function d = PWGdist5(x, y) 

 % Get all unique values 

 u = union(x, y); 

 % Count occurrences in each vector 

 cx = histc(x, u); 

 cy = histc(y, u); 

 % Total matches (green + yellow) for each value 

 total_matches = sum(min(cx, cy)); 

 % Green matches 

 green_matches = sum(x == y); 

 % Calculate distance 

 % Start with max (all black): 2 * length(x) 

 % Subtract yellow+green: -total_matches 

 % Subtract extra for greens: -green_matches 

 d = 2 * length(x) - total_matches - green_matches; 

end

Let me verify with the example:

x = [4 3 2 4 2 3 1], y = [3 1 2 4 1 4 4]
Unique values: [1 2 3 4]
Counts in x: [1, 2, 2, 2]
Counts in y: [2, 1, 1, 3]
Min counts: [1, 1, 1, 2] → sum = 5 total matches
Green matches: x == y → positions 3 and 4 → 2 greens
Distance: 2*7 - 5 - 2 = 14 - 7 = 7

IT WORKS!

Understanding Why This Works

The formula breaks down like this:

2 * length(x): If everything was black (worst case)
- sum(min(cx, cy)): Subtract 1 for each match (green or yellow)
- sum(x == y): Subtract an additional 1 for each green (they count double)

So:

Black element: Contributes 2 (no subtraction)
Yellow element: Contributes 1 (subtract 1 once)
Green element: Contributes 0 (subtract 1 twice)

Beautiful! No loops over elements, just vectorized operations. Metric: 57.

Attempt 5: Code Golf the Histogram Solution

Now, how can I make this even shorter?

Golf Move 1: Inline Variables

function d = PWGdist6(x, y) 

 u = union(x, y); 

 d = 2*length(x) - sum(min(histc(x,u), histc(y,u))) - sum(x==y); 

end

Metric: 41.

Golf Move 2: Use numel

function d = PWGdist7(x,y) 

 u=union(x,y); 

 d=2*numel(x)-sum(min(histc(x,u),histc(y,u)))-sum(x==y); 

end

Metric: 41.

Golf Move 3: Output via ans

Here's a slick trick: Instead of naming the output variable, just assign to ans:

function ans = PWGdist8(x,y) 

 u=union(x,y); 

 ans=2*numel(x)-sum(min(histc(x,u),histc(y,u)))-sum(x==y); 

end

Wait, can I go further?

Golf Move 4: Union Returns to ans

If I don't assign union(x,y) to a variable, it goes to ans. I can reference it on the next line!

function ans = PWGdist9(x,y) 

 union(x,y); 

 2*numel(x)-sum(min(histc(x,ans),histc(y,ans)))-sum(x==y); 

end

WHOA! Two statements. The first calls union(x,y) and the result is in ans. The second line uses that ans for the histograms, then assigns its own result to ans (implicitly, since it's the last line and has no semicolon).

Metric: 37!

This is as short as I can get it while keeping it readable(ish).

Key Code Golf Techniques I Learned

1. Output via ans: Saves variable declaration

2. Chain with ans: Call function, then reference result as ans

3. Remove whitespace: 2*x not 2 * x

4. Use numel over length: Slightly shorter

5. Vectorize everything: histc beats loops

6. Think mathematically: Count, don't simulate

7. Single-letter variables: u, v, d everywhere

8. Drop the last semicolon: Last line doesn't need it

What I'd Tell My Past Self

Start simple. My two-pass solution got me points and taught me the problem deeply. Don't feel bad about verbose code at first.

Look for patterns. The greedy insight came from asking: "What's redundant here?"

Study the leaderboard. The histogram approach wasn't my idea—I learned it from others. That's the beauty of Cody!

Test with edge cases. x=[1 1 1], y=[1 2 3] catches 90% of bugs.

Enjoy the journey. Going from metric 110 → 74 → 57 → 37 felt like climbing a mountain. Each view was rewarding.

Final Thoughts

This problem taught me that there are often multiple levels of solution:

1. Correct: Make it work

2. Clear: Make it right

3. Clever: Make it elegant

4. Compact: Make it short

You don't always need level 4, but knowing it exists makes you a better programmer. The histogram solution changed how I think about problems—sometimes the best code doesn't simulate the process, it counts the outcomes.

Now, when I play Wordle each morning, I think: "I wonder if I could histogram this..."

Community Q&A – Victor Luquin

Ned Gulley — Wed, 21 Jan 2026 18:57:01 +0000

Our post today is from Tharikaa Ramesh Kumar, Product Manager for MATLAB Mobile. Tharikaa recently sat down with Victor Luquin, an aerospace engineer with the 412th Test Wing at Edwards Air Force Base. Victor’s work spans flight test engineering, structural data analysis, and education, and his MATLAB journey reflects a constant search for better ways to work wherever ideas strike. What began as using MATLAB Mobile during a student commute evolved into hackathon‑winning projects, modernized approaches for collecting real‑world flight data, and hands‑on STEM initiatives that bring aerospace engineering into the classroom. From smartphones and sensors to gliders and students, Victor’s story shows how powerful tools can help engineers rethink what’s possible.

Q: Let’s start with your journey. Could you share a brief overview of your academic and professional background?

A: After earning my B.S. in Aerospace Engineering and Applied Mathematics and a M.S. in Aerospace Engineering from California State University, Long Beach (CSULB), I completed multiple NASA funded research internships at the Langley Research Center and Glenn Research Center. Since joining Edwards in 2018, I’ve focused on structural data analysis and modernization of structures flight test execution and analysis. Currently, I’m pursuing a Ph.D. in Engineering and Computational Mathematics through a joint program with CSULB and Claremont Graduate University, supported by a DoD SMART Scholarship.

Q: When did you first discover MATLAB Mobile? What were your earliest use cases, perhaps during college or personal projects?

A: I first discovered MATLAB Mobile during my undergraduate studies at CSULB. Commuting by bus meant I needed flexibility, and the app made it easy to write scripts for class projects and homework anywhere.

Later, during my M.S. program, I started exploring MATLAB Mobile’s data collection features. At the 2018 CSULB 24-Hour Beach Hackathon, my partner, Nkechi Okorie, and I used the app to record GPS data across campus to build an accessibility app for visually impaired students. The app provided vibration cues to guide users along safe routes, and our project won the event’s Best Social Impact Award.

MATLAB Mobile gave me the freedom to code on the go and the tools to turn ideas into impactful solutions. It’s a great tool for students and professionals who want to stay productive on the go

Q: Tell us more about the glider flight project. How did the idea evolve from your Air Force experience into a high school STEM initiative?

A: The Glider Flight Project originated from my experience as a new engineer at Edwards AFB. In a training course, participants manually recorded flight data such as altitude, airspeed, and G loads using pen and paper.

Drawing on my experience with MATLAB Mobile, I proposed using the app to collect sensor data directly from a phone’s accelerometer, gyroscope, and GPS. I demonstrated that it could capture the same parameters automatically and with far greater resolution.

In 2020, Juan Rodriguez Cabrillo High School’s engineering advisory board sought new projects for its senior aerospace class. Collaborating with instructor Kenneth Fisher, we adapted the MATLAB Mobile glider test concept for students. With support from the 412th Test Wing STEM Office and coordinator Helida Vanhoy, I wrote an Education Partnership Agreement between Edwards AFB and the Long Beach Unified School District in 2021.

The first student cohort launched in spring 2022. Over three days, 40 students conducted real flight tests in gliders near Edwards AFB, collecting real time data with MATLAB Mobile. Each evening, students and engineers worked together to process and analyze the data in MATLAB Online, computing climb rates, bank angles, glide slopes, G loads, and other flight parameters.

The goal is to connect classroom theory to real world aerospace testing and inspire students to pursue STEM careers. Students learn data collection, visualization, and problem solving, for example finding creative solutions to keep phones cool during flight so data collection could continue uninterrupted. To date, more than 140 participants have taken part in the Glider Flight Project.

Victor Luquin works with Cabrillo High School students during a glider flight STEM lesson near Edwards Air Force Base, where students used MATLAB Mobile to collect real-time flight data. (U.S. Air Force photo by Todd Schannuth)

Q: What kind of data were you collecting during glider flights, and how was the setup arranged?

A: We collected sensor data such as accelerations, orientation, angular velocities, and position using MATLAB Mobile. Each phone was mounted with Velcro to the glider’s instrument panel and signed into a shared MATLAB account. Data uploaded automatically to MATLAB Drive, where a ground station running MATLAB Online processed the files into CSV format.

Students then accessed their flight data from their own MATLAB Drive accounts for further analysis and report generation. Using MATLAB, they computed climb rates, bank angles, glide slopes, and G-loads—turning raw sensor data into meaningful insights.

This setup gave students hands-on experience with data collection, visualization, and analysis and the seamless connection between MATLAB Mobile, MATLAB Drive, and MATLAB Online made the workflow simple and collaborative, even in a field environment.

3D flight path captured using MATLAB Mobile, then saved to MATLAB Drive and plotted in MATLAB Online as part of Victor’s Glider Flight Project Program.

Q: How did students respond to using MATLAB Mobile for real-time data collection and analysis?

A: Students often said that using MATLAB made engineering “real” for them, connecting math and physics concepts to hands-on experimentation.

I created a student guide and YouTube tutorials to help them set up MATLAB Mobile and export flight data. While data collection was straightforward, coding and data processing in MATLAB Online were initially a challenge. To support them, I developed sample scripts and documentation.

Using MATLAB Mobile made the process feel modern and approachable. Over time, more students became comfortable using MATLAB, especially once they realized they could ask ChatGPT for coding assistance. By the fourth cohort, many were visualizing flight data in MATLAB, plotting altitude profiles, glide slopes, and acceleration graphs

Q: Is there anything else you’d like to share about your experience with MATLAB Mobile?

A: One recurring challenge has been maintaining reliable GPS logging. While the first two cohorts recorded full datasets, later groups occasionally lost position data mid-flight. We suspect this may relate to phone settings or OS updates.

Another issue is device overheating, since MATLAB Mobile pauses data collection when the screen locks. Students came up with creative fixes like shading phones with paper reflectors or swapping devices between flights.

These experiences encouraged students to think like engineers: identify issues, test solutions, and adapt quickly.

Q: Any advice for educators or engineers considering mobile tools for data collection?

A: Start small. Begin with simple walking or driving exercises before moving on to aircraft or complex systems. Once students are comfortable handling 2D motion data, transition to 3D flight dynamics and analysis.

If you’re looking for a way to make STEM hands-on and exciting, MATLAB Mobile is a great starting point. It turns any smartphone into a data acquisition system. Building foundational skills step by step helps students gain confidence with both data and MATLAB. Above all, emphasize experimentation and let them see the connection between math, physics, and real world application.

Supplementary Materials

Learn more about the Glider Flight Project on Victor’s YouTube Channel.
Read the full story behind the Glider Flight Project.
Try the data analysis yourself using the scripts and data.

If Victor’s story resonated with you, I encourage you to take a few minutes to explore what MATLAB Mobile can do for your own workflows. Whether you’re jotting down ideas on the go, collecting sensor data, reviewing results away from your desk, or teaching and leveraging project‑based learning in the classroom, MATLAB Mobile opens up new ways to stay connected to your work, whenever and wherever you are. I’d love to hear how you use MATLAB Mobile! Please share your experiences in the comments. Your feedback helps guide how we continue to evolve the app.

You can learn more about MATLAB Mobile here: https://www.mathworks.com/products/matlab-mobile.html

Duncan Carlsmith’s Physics Experiments

Ned Gulley — Thu, 15 Jan 2026 20:48:18 +0000

Duncan Carlsmith is a busy man. Don't believe me? Take a look in the Generative AI discussion area and you'll see that he's made six posts in the last three weeks alone. And these posts are substantial, cataloguing significant achievements. His most recent piece (as of this writing!) is about his Double Pendulum Chaos Explorer. More on that in a bit.

And just who is this hard-charging Duncan Carlsmith? He's a physics professor at the University of Wisconsin, and he recently discovered the power of Claude Code and the MATLAB MCP server. Now he wants you to know about them. I want you to know about them too!

The best way I can think of to convince you that these tools are worth learning is to show you how quickly you can create stuff. But don't take my word for it. Here's Carlsmith talking about how he built his Double Pendulum tool.

A remarkable thing I learned is not just the AI's ability to write HTML5 code in addition to MATLAB code, but its knowledge and intuition about app layout and user interactions. I played the role of an increasingly demanding user-experience tester, exercising and providing feedback on the interface, issuing prompts like "Add drag please" (Voila, a new drag slider with appropriately set limits and default value appears.) and "I want to be able to drag the pendulum masses, not just set angles via sliders, thank you." Then "Convert this into a MATLAB code." I was essentially done in 45 minutes start to finish, added a last request, and went to bed.

That's some serious productivity!

Back in November, I too was playing around with a double pendulum model (see Storyboarding with Live Script Skills). It's no big surprise that Carlsmith and I chose the same system. The double pendulum is a well-known classroom project, easy to build and endlessly fun to watch owing to its chaotic nature.

So I'm going to take this same double pendulum demo in a slightly different direction. I'm going to demonstrate a skill that allows you to build a JavaScript user interface that works entirely inside the context of MATLAB. The secret to this is something I call "Rick's Trick", named after my friend Rick Paxson, who taught it to me. The key insight is that there is a MATLAB UI component called uihtml that allows you to embed arbitrary HTML (and its associated JavaScript) right in a figure or AppDesigner app. But rather than have some MATLAB uicontrol buttons next to a small HTML display, you can actually make the entire figure window one big uihtml panel. Then all the UI elements, all the displays, everything becomes one single HTML/JavaScript entity. MATLAB is used for what it does best: accurate ODE integration. And we can leverage the world of HTML for the interface.

I made a Claude Skill to help me do this. Armed with this skill, you don't have to know anything about how to pass data back and forth from MATLAB to JavaScript. Want to try it? Here it is!

skills/skills/matlab-uihtml-app-builder/SKILL.md at main · matlab/skills · GitHub

Here is my prompt.

Use the uihtml skill to make a UI for the double pendulum ODE. I want sliders for the initial conditions theta1 and theta2, sliders for parameter controls, an animation pane for the double pendulum and another pane to plot theta1 vs theta2. There will be a "Go" button that will pass all parameters to MATLAB for calculation. Then, when the entire simulated run of 20 seconds is complete, pass all the data back to the HTML UI for display at the rate of 1 simulated second = 1 second of real clock time. Make sure the time vector you pass is evenly divided so that everything looks smooth and realistic.

I liked what I got back, but just for fun I added "Now make it look cool." Here's the result.

Now I have all the flexibility of JavaScript and HTML for displaying the simulation results. And because Claude Code is fast, it was a two minute exercise to say "Make the UI look like something you might see in a WWII airplane."

You might quibble about whether this UI looks like something from 1944, but the point is to show how quickly you can transform these UIs, whether in functionality or appearance.

Thanks for the inspiration Duncan!

The Perils of Obliquity

Ned Gulley — Fri, 05 Dec 2025 17:25:24 +0000

You might think you don't care about spherical geometry, but really you do. Because spherical geometry is where you live.

This is a story of the real-world complications of three dimensional projections from one great circle to another. It's also a good example of why I love MATLAB. I can puzzle about an interesting problem, then use my favorite technical computing tool to come to a deeper understanding. I'm going to bring you along on a ride with me as we explore something that I think about every December: the mysteries of the shortest day. Along the way, we'll savor some MATLAB morsels. Lucky you! Buckle up.

Here's a picture of the sun and the earth at the solstice.

t = linspace(0,2*pi);

ct = cos(t);

st = sin(t);

clf

heq = line(ct,st,0*t,Color="black");

earth = [0 0];

sun = [-1 0];

line( ...

 [earth(1) sun(1)],[earth(2) sun(2)], ...

 Color=0.8*[1 1 1])

he = line(earth(1),earth(2), ...

 Marker=".",MarkerSize=24, ...

 Color=[0.3 0.6 1]);

hs = line(sun(1),sun(2), ...

 Marker=".",MarkerSize=24, ...

 Color=[0.95 0.8 0.3]);

axis equal

axis off

legend([he,hs,heq],{"Earth","Sun","Ecliptic"})

After one spin on its axis, twenty-four hours later, the sun is here relative to the earth. A day has passed.

t2 = linspace(pi,1.5*pi,5);

ct2 = cos(t2);

st2 = sin(t2);

sun = [ct2(2) st2(2)];

line([earth(1) sun(1)],[earth(2) sun(2)], ...

 Color=0.8*[1 1 1]);

set(hs,XData=sun(1),YData=sun(2))

legend([he,hs,heq],{"Earth","Sun","Ecliptic"})

Okay, I admit I'm making it look like the sun goes around the earth, but relatively speaking this is true enough. The sun icon is indicating the direction of the sun from earth's point of view. This geocentric view makes the diagrams simpler. Also, I'm making the days abnormally long. Pretend there are exactly 16 days in year. So there are only 4 days between the solstice and the equinox.

The plane in which the earth moves around the sun (represented by the black circle we see here) is called the ecliptic.

for n = 1:length(t2)

 line([earth(1) ct2(n)],[earth(2) st2(n)], ...

 Color=0.8*[1 1 1])

end

sun = [ct2(end) st2(end)];

set(hs,XData=sun(1),YData=sun(2))

legend([he,hs],{"Earth","Sun"})

The earth rotating on its axis determines how long an hour is. This is the "clock plane" (also known as the equatorial plane). The earth's motion around the sun determines how long a year is. This is the "year plane" (the ecliptic plane). In the diagram below, the outer circle is the ecliptic plane and we've added a gray inner circle for the equatorial plane.

As you know, the earth is tilted relative to the ecliptic plane. This angle between the equatorial plane and the ecliptic plane, called obliquity, is approximately 23.4 degrees.

But first let's consider how things would look if there was no axis tilt. The equatorial plane would be coincident with the ecliptic. There would be no seasons. No solstice. No equinox (or rather, never-ending equinox). A little boring, maybe, but the astronomical calculations would be a breeze. The days marked off on the equatorial plane perfectly match the same days marked off on the ecliptic.

clf

hecl = line(ct,st,0*t, ...

 Color=[0 0 0]);

for n = 1:length(t2)

 line(ct2(n)*[0 1],st2(n)*[0 1],[0 0],Color=0.8*[1 1 1])

end

hgt = hgtransform;

heq = patch(0.5*ct,0.5*st,0*t, ...

 FaceColor=0.95*[1 1 1],EdgeColor=[0 0 0], ...

 Parent=hgt);

hpole = line([0 0],[0 0],[0 1],Parent=hgt);

for n = 1:length(t2)

 line(ct2(n)*[0 0.5],st2(n)*[0 0.5],[0 0],Color=0.8*[1 1 1],Parent=hgt)

end

axis equal

axis off

But now let's add the axis tilt to the equatorial plane. I'm going to exaggerate the tilt here to emphasize the discrepancy.

Oh, and watch how I use HGTRANSFORM to rotate a bunch of objects in 3-space in one slick maneuver! HGTRANSFORM is a favorite of mine.

The key thing to notice here is that the gray "noon" lines no longer match up. That means 24 hours (one notch on the inner circle) doesn't match the time from solar noon to solar noon (one notch on the outer circle). The day length is literally stretching and shrinking! You can also see that the lines do match on the solstices and the equinoxes.

epsilon = 45; % Actual epsilon is only 23.4 deg

rot = makehgtform(YRotate=deg2rad(epsilon));

set(hgt,Matrix=rot)

It's a little hard to visualize what's going on from this top view. Let's look at things from the side.

view(3)

view([15 20])

This is the punchline: we have two competing ways to define a day: the time between successive noons, which varies with the season, and exactly 24 hours, which is constant throughout the year. Things look good at the solstice and the equinox, but significantly off in between.

This is a real effect. Solar days vary in length. Obliquity contributes to the so-called Equation of Time which spells out when the sun is running ahead of or behind what the clock says.

The code below will generate an animation. I'll paste in the corresponding GIF-file.

for epsilon = 45*sin(linspace(0,pi))

 rot = makehgtform(YRotate = deg2rad(epsilon));

 set(hgt,Matrix=rot)

 axis([-1 1 -1 1 -1 1])

 view(2)

 drawnow

end

How bad is the discrepancy? Up to 10 minutes at its maximum. Let's try a couple of alternative tilt scenarios. If the earth was tilted ten degrees more, the solar noon would be up to 20 minutes out of sync with the clock.

clf

t = linspace(pi,3/2*pi);

discrepancy = zeros(size(t));

for epsilon = [13.4 23.4 33.4]

 m = makehgtform(YRotate = deg2rad(epsilon));

 for n = 1:length(t)

 p1 = [cos(t(n)); sin(t(n)); 0; 1];

 p2 = m*p1;

 % Dropping the z term effectively projects the vector onto the x-y plane

 p2(3) = 0;

 % Now find the angle between the two vectors

 v1 = p1(1:3);

 v2 = p2(1:3);

 discrepancy(n) = atan2(norm(cross(v1,v2)), dot(v1,v2));

end

 plot(t,discrepancy/(2*pi)*24*60)

 hold on

end

set(gca,XLim=pi*[1 1.5], ...

 XTick=pi*[1 1.25 1.5], ...

 XTickLabels={"Solstice","Cross-Quarter Day","Equinox"})

ylabel('Discrepancy (minutes)');

title('Time Discrepancy');

grid on

legend({'\epsilon = 13.4 deg','\epsilon = 23.4 deg','\epsilon = 33.4 deg'})

What's going on here? One hour is NOT 1/24 of the time between successive noons. If it was, we'd go insane. To keep from having an hour that is constantly changing, humans created an invariant average "standard hour". The obliquity effect stretches and shrinks the solar day as measured by this standard hour. This moves the local solar noon around, depending on the time of year. And one effect of this is that the earliest sunset arrives sooner than the shortest day. And in fact, the earliest sunset at my latitude is December 9th.

Happy Crepusculus!

Interpolation Games with MATLAB Copilot

Ned Gulley — Fri, 21 Nov 2025 19:42:53 +0000

You may have seen the news on the MATLAB Blog that MATLAB Copilot has been updated to the GPT-5 mini model. My experience has shown this to be a huge improvement. So if you haven't tried Copilot yet, now's the time! It's only getting better. And it's nice to know that you don't have to wait for the next general release of MATLAB to get this improved version of Copilot. It's a service that gets better for everyone across the board. MATLAB is improving while you sleep!

I wanted to flex the latest Copilot, and an old problem came to mind that I remember from the Ancient Days: scattered data interpolation. Let's say I'm trying to make a 3D map of a mountain range. You've given me a list of measurements: altitudes for specific latitudes and longitudes, but in no particular order. What does the mountain range look like? This used to mean writing some non-trivial code, but about a dozen years ago we added the scatteredInterpolant function to MATLAB and life got easier. This built-in function makes the scattered data interpolation problem go away. But now it's even easier than that! I don't have to read the doc or even know that the function exists. I just go to Copilot and enter something like this.

Across a 2D domain, I have a set of randomly scattered measurements of 
altitude points. That is, for a list of (x,y) tuples, I know z. 
Help me turn this into a regularly sampled surface.

For my list of measurements, I'll be using random samples from a 3D surface. See if you can guess what it is!

% Determine the target shape. Choose mode number from k = 1..8.
k = 1;
m = 40;
L = membrane(k,m);

% Get random measurements across the surface
npts = 100;
ix = unique(randi(numel(L),[npts,1]));
[y,x] = ind2sub([n,n],ix);
z = L(ix);

Here are my measurements. With only 100 points, can you see the shape?

plot3(x,y,z,'.') 
axis vis3d

Let's animate it to make it pop a little better.

So let's make an interpolated shape. This next part is the code that Copilot gave me.

% Given column vectors x, y, z (all same length)
% Choose grid resolution
n = size(L,1);

% Grid covering the data range
xqv = linspace(min(x), max(x), n);
yqv = linspace(min(y), max(y), n);
[Xq, Yq] = meshgrid(xqv, yqv);

% Interpolate using scatteredInterpolant
F = scatteredInterpolant(x, y, z, 'natural');
Zq = F(Xq, Yq);

% Plot as surface (or use contourf/imagesc)
surf(Xq, Yq, Zq)
axis vis3d

And there you have it! A slightly lumpy but recognizable reconstruction of the MathWorks logo (the output of membrane(1)) based on 100 randomly sampled points. Copilot made short work of my problem, giving me exactly what I was after. But all this playing around with scattered interpolants has made me hungrier for more. I'm curious how many points I need in order to see a particular shape.

An Interpolation Game

Let's make a game inside a MATLAB app. For this, I'm going to switch gears. Since this is a more complex task, I want to use one of our new prompts and the MATLAB MCP server that can be installed with Claude Desktop (Learn more about how to set this up from Mike's blog). Having access to this server makes everything go much faster. Here's a sketch of the app interface I want Claude to create for me.

The idea is that there are four possible candidates that I'm sampling from. How many samples do I need to guess which of the four candidates is being sampled?

Writing an app can be a complicated exercise. But it doesn't have to be when AI is helping you. I'm going to use one of our new prompts that is especially designed to make app creation a breeze. I'll modify the prompt with these directions.

## Prompt for Interpolant Guessing Game
Create a MATLAB programmatic app for demonstrating 
scattered interpolants.

We will demonstrate interpolants with a guessing game: 
how many points do you need to guess the correct shape?

We are using a small number of points to interpolate 
across and unknown shape. We have four candidate surfaces 
to guess from. These will be four randomly chosen modes 
from among the first 8 modes of the L-shaped membrane 
(where mode n is returned by membrane(n)).

### The Layout
See the diagram in the file @sketch.png. On the left is a 
plot that shows the current interpolant. On the right are 
the four candidate shapes in a 2-by-2 grid.

The interpolant on the left will start out with 10 sample points. 
Underneath the interpolant plot are two buttons: "+1 sample" and 
"+10 samples". 

In the bottom right is a "Guess" editable text field where the 
user is invited to make a guess about which candidate shape is 
being interpolated. If they enter a value and press return, they
will be told if they are correct or incorrect.

Starting with the prompt from GitHub, I pasted the text shown here into the section called, appropriately, "The Prompt" to get a sort of super-prompt. Then I sent Claude on its way. Very quickly it gave me this.

Nice! This is just what I was picturing. Everything worked as expected. I didn't have to worry about UI layout or button logic. It just worked. Here you're seeing an interpolation based on only 10 points. Which of the four potential candidates does this interpolated shape most likely match?

Now I'm going to use the buttons to add a bunch more measurements.

With 215 points, the fog has cleared. Can you see which candidate is being sampled? Why yes, it's Cleve Moler's old friend, the first vibrational mode of a membrane on a square domain with an invariant re-entrant corner, affectionately known around Natick as the L-shaped membrane. Looking good, Ellie!

It was fun exercising some basic MATLAB functionality using the latest Copilot. But then, leveraging the MCP Server, it was awesome to quickly create a game that builds on that learning and provides more insight about the nature of interpolation. AI lets you fly around a bigger design space. In the past, I would have had this same idea for a game, but I probably wouldn't have taken the time actually build it. Now it's more like the wave of a magical wand and VOOM! there it is.

Storyboarding with Live Script Skills

Ned Gulley — Tue, 04 Nov 2025 20:50:45 +0000

Last June I wrote about how I used a MATLAB MCP Server to write some useful code, but I didn't share the actual MCP server that I used. Now all can be revealed, because in the last week MathWorks has released an official MATLAB MCP Server. Try it! It's free! My fellow MathWorks bloggers, Yann and Mike, will tell you all about it.

But that's not what I'm going to talk about this week. Because we've been busy... in addition to the new MCP Server, we've published GitHub repositories full of resources to guide your usage of AI tools (see MATLAB Development & AI Coding Projects). Today I want to talk to you about Skills, a new kind of resource that can be used with Anthropic's Claude model.

For my demo, I'll be using Claude Code (learn more here). I'm typing in my requests to Claude Code and in response it is generating MATLAB code for me. I can then open it and execute it in the MATLAB desktop.

So what's a skill? A skill is a sort of latent prompt for a language model. It's a set of instructions that can be tucked out of the way until needed. That's what makes skills useful: they don't clog the resource pipeline when they're not needed. The skill that I'm going to demonstrate is for making plain text Live Scripts in MATLAB. For my demo, I'm going to use a well-known physical system: the double pendulum.

I'll use a technique that I call storyboarding. You may be familiar with the concept of storyboarding from the movies. The idea is that you draw rough sketches of how the action will play out. This saves you time and money when you're actually trying to move expensive things around the set.

In MATLAB terms, I'm going to write a brief sketch, section by section, of what I want my Live Script to look like. And then I'll let Claude fill in the specifics. This gets me to the result I want with minimal wasted effort.

So I can write something like

I will be modeling a double pendulum. Here are the equations of motion
EQUATIONS

That is, I'm literally writing the word "EQUATIONS" and assuming that Claude knows how to derive and fill in the equations. A little further down, I put this.

As an example of the "butterfly effect", here we will start off two 
simulations with only the tiniest difference between their two sets 
of initial conditions. Notice how quickly they diverge.
PLOT OF THETA1 AND THETA2 VS TIME

Again, I am confident that Claude can make the choices necessary to turn "PLOT OF THETA1 AND THETA2 VS TIME" into a useful plot. Along with my Markdown storyboard script I supply this top-level prompt to get the whole process started.

Build a MATLAB ODE for a double pendulum as specified in this diagram: @diagram.png
Use the file @storyboard.md as a template for a Live Script. 
Use the matlab-live-script skill.

I just have to make sure the skill file is in the right place, and now Claude has everything it needs to fill out the storyboard. A minute later I am rewarded with this Live Script. It's done exactly what I want, and the results look good.

I needed to verify that the equations were correct (they were) and then review the code for good design and safety. But even so, this storyboarding approach saved me a ton of work and got me quickly to an excellent result. Now I'm excited to try some more skills and prompts to see where they can take me.

Making Live Scripts with Generative AI

Ned Gulley — Tue, 23 Sep 2025 15:52:13 +0000

I've been having fun making MATLAB code with Large Language Models. You can try this yourself with MATLAB's Copilot feature. But since the AI world is moving so fast, I also like to do a little generative AI tourism, trying out the latest models and tools. Today I want to look at Anthropic's Claude Code.

Claude Code runs in a terminal window that can sit inside an IDE like Microsoft's VS Code. You do need a payment plan with Anthropic in order to make it work. So be aware that the demos I'm stepping through here involved me spending a little money. The total cost of the experiments I describe here was $0.63 using Claude's pay-as-you-go option.

What to code? Since we're just playing around, let's take a visually appealing topic: fractal attractor systems. I started off with a vague prompt, curious to see what it would come up with.

> Make me a MATLAB Live Script demonstrating the De Jong fractal attractor

The De Jong attractor is a two-dimensional system defined by these equations.

x_t+1 = sin(a · y_t) - cos(b · x_t)
y_t+1 = sin(c · x_t) - cos(d · y_t)

Claude gets right back to me with a result, DeJongFractalAttractor.mlx, but something is wrong.

Claude (I'm using the Sonnet 4 model here) knows about MATLAB's Live Scripts. And it knows that Live Scripts use the .MLX suffix. But it doesn't know how to create the required OPC format. Instead it writes out a plain text MATLAB script and gives it the .MLX suffix. The resulting file won't even open in MATLAB. If I change the suffix to .M, the file is revealed to be an old-school plain text MATLAB script, complete with %% section breaks.

I can use the PUBLISH command to turn this file into HTML, but we can do better now! One of my favorite recent additions to MATLAB is the plain text Live Script. With this format I get the best of all worlds. All the code, rich text, and images are in a single notebook file, so I don't have a dead HTML file with numerous nearby images hiding in a subfolder. Furthermore, that single file is a plain text .M file! So I don't have the hassle of a complex .MLX format that GitHub can't understand.

So after I change the suffix to .M and then open it as a Live Script and then save it as a MATLAB Live Code File .M file, I end up with something that looks pretty good. But that's a lot of steps to go through just to get to a decent output!

So this generative AI thing is kind of a bust, eh? After all, it fumbled my request. But wait! Here is the main point I want to make today: with some extra prompting, you can often teach the AI how you want it to behave. Out of the box, Claude doesn't know about plain text Live Script files. But I can teach it. I put some coaching prompts in a markdown file called Live_Script_rules.md. Here are some of the contents of that file.

## Live Scripts
- If creating a script, use the plain text Live Script format with the .m suffix
- DO NOT create .mlx scripts
- DO NOT create .m scripts that are not Live Scripts
- When creating new plain text Live Scripts, close with an appendix:
    %[appendix]{"version":"1.0"}
    %---
    %[metadata:view]
    %   data: {"layout":"inline"}
    %---
- Section heads should look like this:
    %%
    %[text] ## Section Title
- DO NOT do this: `%% Section Title`
- Normal text intended for a single paragraph should appear on a single line
- Equations in Live Scripts are formatted using LaTeX formtting like this.
    %[text] $ e = \\sum\_{\\alpha=0}^\\infty \\alpha^n/n! $
- Note the double backslashes
- Use implicit figure creation
- DO NOT use the "figure" command to create new figures
- DO NOT start scripts with CLOSE and CLEAR commands
- Bulleted lists in a rich text block must close with a backslash. Here is an example.
    %[text] - bullet 1
    %[text] - bullet 2
    %[text] - bullet 3 (note the trailing backslash for the last bullet) \

I can go back to Claude and say

> Please regenerate that file, but using these rules: @Live_Script_rules.md

Now the situation is much improved. As long as I keep this rules file in context, I can create beautiful new plain text Live Script files all day long. Here's one last prompt to show what I mean.

> Use the file DeJongFractalAttractor.m as a template and generate two more similar files for these attractors: Dadras attractor and Aizawa attractor

Since my rules were still in context, I was immediately rewarded with two more Live Scripts that met all my standards, no post-editing required.

I have found it very useful to remind myself that, whenever I'm not happy with the AI model's generated output, there is often a prompt that can rescue the situation. Once you find that extra prompt, you can make it a part of your practice, and the world gets better very quickly. So consider hesitating a bit before you declare a model to be stupid. Before you've made an effort to help it out. You might be able to salvage the situation and emerge victorious.

MATLAB Code Generation with the Help of an MCP Server

Ned Gulley — Tue, 17 Jun 2025 21:03:05 +0000

Everyone knows by now that AI services can generate code. For example, with the recent release of MATLAB R2025a, you can use the new Copilot feature to generate code for you from directly inside MATLAB. And all of the major Large Language Models (LLMs) do a remarkably good job writing MATLAB on demand.

It's less well known that you can get an AI service to write MATLAB code for you, then run it, then detect and fix any errors, and finally write a demo file for it. All without your intervention. What is the magic behind this? It's something called a Model Context Protocol, a standard originally introduced by Anthropic in late 2024. MCP defines how an LLM can find and use tools, including MATLAB. If we build an MCP Server that knows how to ask MATLAB to read, write, and run code, then we can close the loop and have the LLM complete an entire project before it checks in with us. MCP is one of the technologies that unlocks agents as a powerful new way of getting things done with AI.

Anyone who's generated code with an LLM knows that hallucination can be a serious problem. The AI can invent functions that simply don't exist. But an agentic workflow using MCP can make sure the code runs before you even see it. There might still be issues with the code you get back, but at least you'll know it runs and passes your tests.

Let's do an experiment. I've installed Claude Desktop on my laptop so it has access to my file system. I also have MATLAB R2025a installed directly on the same machine. With these elements in place, I can set up an MCP Server that can see both of them. The server is a little Python program that passes requests from Claude to MATLAB. Now we have all the ingredients we need to let Claude write code that it can run and debug without my intervention.

I was thinking about this recently and came across a perfect test case. I saw this Discussion note from retired MathWorker Steve Eddins. Steve says: I want to turn a Markdown nested list of text labels into a MATLAB directed graph (see his full blog post here: Fun with Simple Text Processing and Directed Graphs).

This looked like an ideal challenge for MCP-enabled Claude. I presented the problem and then sat back. Here's my initial prompt. It's literally the image and the sample Markdown from Steve's post along with these words: "Write MATLAB code that will parse this and turn it into a diagraph like this image."

It got right to work. Sure enough, the initial code had problems. But from each of three separate issues, it persevered and recovered. The first of these were errors that stopped the interpreter with an error message.

I was intrigued by the last issue. The code ran without error, but Claude was smart enough to notice that the result looked strange (an unconnected graph of nine nodes) and it fixed the code before returning to me. Eventually I was rewarded with this.

Look at the images, and you'll see that Claude's solution (using the Sonnet 3.7 model) was an excellent match for Steve's output. I won't make the case that the code quality is better than Steve's, given his many years of experience, and of course you'll want to be very cautious with any process that can create and run code on your machine. But the MCP process saves a lot of hassle for those of us who want to try out automatic code generation.

Happy Valentines! Caption This GIF

Ned Gulley — Fri, 14 Feb 2025 19:33:44 +0000

Mike is spreading some MATLAB Valentines joy over on the MATLAB Blog. Here is MathWorker Jonathan Gale's ode to the Mapping Toolbox and the Bonne spherical projection.

What would your caption for this animation be? Some ideas:

I love you THIS much!
You mean the world to me
What the world needs now is love, sweet love
I the world, literally
A Bonne bonbon for Valentines