Traditional dense cellular automaton simulations recompute every cell at every iteration, even when large regions remain unchanged. This becomes inefficient in one dimensional elementary cellular automata where activity is often sparse and localized. This project presents a hybrid sparse and parallel framework for one dimensional cellular automata implemented entirely in Wolfram Language. The framework classifies rules into four categories based on the behavior of homogeneous neighborhoods and , and introduces specialized sparse update algorithms for each category to reduce unnecessary recomputation. To evaluate performance, a benchmark framework is developed to measure runtime across different array sizes, activity spreads, and step counts. The benchmark results are used to construct runtime prediction models for both dense and sparse updates, which are then integrated into a reload balancing strategy that dynamically switches between the two methods during execution. The project also explores multi kernel parallel computation using Mathematica’s parallel kernel system with halo exchange between partitions . Experimental results show that sparse updates can significantly outperform dense scans under localized activity distributions, while dense updates remain preferable for highly distributed activity patterns . Although Mathematica’s built in CellularAutomaton remains substantially faster due to low level internal optimization, this work demonstrates that adaptive sparse optimization and hybrid update strategies can still be effectively studied within a high level symbolic programming environment.
f(000)
f(111)
Introduction
Introduction
Cellular automata (CA) are discrete dynamical systems in which each cell evolves according to a local update rule determined by neighboring cells . Despite their simple mathematical definitions, cellular automata exhibit highly complex emergent behavior and have applications in physics, biology, distributed systems, procedural generation, and computational theory.
Traditional cellular automaton simulations rely on dense updates, where every cell is recomputed at every iteration. While straightforward, this approach becomes computationally inefficient when large regions of the automaton remain homogeneous or inactive. In many one dimensional elementary cellular automata, activity is concentrated within relatively small localized regions, meaning that a large fraction of computation is wasted repeatedly updating stable background cells.
This project investigates sparse optimization and parallel computing techniques for one dimensional cellular automata implemented entirely in Wolfram Language. The framework begins with a dense baseline implementation, then introduces specialized sparse update methods for four different categories of rules. These categories are determined by the behavior of homogeneous neighborhoods, specifically and .
In addition to sparse updates, this project explores multi kernel parallelization in Mathematica. The one dimensional array is partitioned into consecutive regions, and each region is assigned to a separate kernel. Since cellular automata depend on neighboring cells, the implementation uses halo exchange between adjacent partitions to maintain correctness across boundaries. This parallel prototype shows how Wolfram Language kernels can be used for distributed CA updates, but it also reveals a synchronization bottleneck: when one partition takes longer than the others, every other kernel must wait.
This synchronization problem motivates the reload balancing strategy. Instead of choosing dense update or sparse update once for the entire simulation, the framework builds benchmark based runtime predictors and uses them to dynamically decide which update method should be used at each step. In the long term, this strategy can also be combined with the parallel partitioning system, so that sparse updates are used on low activity regions while dense updates are used on high activity regions.
Unlike low level implementations written in C or CUDA, Wolfram Language provides a high level symbolic programming environment with powerful functional programming, visualization, and modeling capabilities. However, this also introduces interpreter overhead, memory allocation costs, and kernel communication overhead. Therefore, the purpose of this project is not necessarily to outperform Mathematica’s built in CellularAutomaton, but to study how sparse updates, parallel kernels, and adaptive reload strategies behave in a high level computational language.
The remainder of this paper is organized as follows. First, a dense baseline implementation and a compiled optimization are presented to establish a reference point for performance comparisons. Next, the sparse update framework is introduced, including the candidate maintenance mechanism and the classification of elementary cellular automata into four categories based on the behavior of homogeneous neighborhoods. The benchmark framework and runtime prediction model are then described, providing the foundation for adaptive execution decisions. Following this, a prototype multi kernel parallel implementation is presented, along with an analysis of its synchronization and load balancing challenges. The reload balancing strategy is subsequently introduced, using benchmark driven runtime prediction to dynamically switch between dense and sparse updates. Finally, the results, limitations, and future directions of the framework are discussed.
Traditional cellular automaton simulations rely on dense updates, where every cell is recomputed at every iteration. While straightforward, this approach becomes computationally inefficient when large regions of the automaton remain homogeneous or inactive. In many one dimensional elementary cellular automata, activity is concentrated within relatively small localized regions, meaning that a large fraction of computation is wasted repeatedly updating stable background cells.
This project investigates sparse optimization and parallel computing techniques for one dimensional cellular automata implemented entirely in Wolfram Language. The framework begins with a dense baseline implementation, then introduces specialized sparse update methods for four different categories of rules. These categories are determined by the behavior of homogeneous neighborhoods, specifically
f(000)
f(111)
In addition to sparse updates, this project explores multi kernel parallelization in Mathematica. The one dimensional array is partitioned into consecutive regions, and each region is assigned to a separate kernel. Since cellular automata depend on neighboring cells, the implementation uses halo exchange between adjacent partitions to maintain correctness across boundaries. This parallel prototype shows how Wolfram Language kernels can be used for distributed CA updates, but it also reveals a synchronization bottleneck: when one partition takes longer than the others, every other kernel must wait.
This synchronization problem motivates the reload balancing strategy. Instead of choosing dense update or sparse update once for the entire simulation, the framework builds benchmark based runtime predictors and uses them to dynamically decide which update method should be used at each step. In the long term, this strategy can also be combined with the parallel partitioning system, so that sparse updates are used on low activity regions while dense updates are used on high activity regions.
Unlike low level implementations written in C or CUDA, Wolfram Language provides a high level symbolic programming environment with powerful functional programming, visualization, and modeling capabilities. However, this also introduces interpreter overhead, memory allocation costs, and kernel communication overhead. Therefore, the purpose of this project is not necessarily to outperform Mathematica’s built in CellularAutomaton, but to study how sparse updates, parallel kernels, and adaptive reload strategies behave in a high level computational language.
The remainder of this paper is organized as follows. First, a dense baseline implementation and a compiled optimization are presented to establish a reference point for performance comparisons. Next, the sparse update framework is introduced, including the candidate maintenance mechanism and the classification of elementary cellular automata into four categories based on the behavior of homogeneous neighborhoods. The benchmark framework and runtime prediction model are then described, providing the foundation for adaptive execution decisions. Following this, a prototype multi kernel parallel implementation is presented, along with an analysis of its synchronization and load balancing challenges. The reload balancing strategy is subsequently introduced, using benchmark driven runtime prediction to dynamically switch between dense and sparse updates. Finally, the results, limitations, and future directions of the framework are discussed.
The use of the built in CellularAutomaton function
The use of the built in CellularAutomaton function
Wolfram Mathematica already provides a built in function for one dimensional cellular automata:
In[]:=
Column[CellularAutomaton[30,{1,0,0,0,0,0},5]]
Out[]=
{1,0,0,0,0,0} |
{1,1,0,0,0,1} |
{0,0,1,0,1,1} |
{1,1,1,0,1,0} |
{1,0,0,0,1,0} |
{1,1,0,1,1,0} |
This function is extremely optimized internally and serves as the correctness reference throughout this project . However, the implementation details are hidden from the user, making it difficult to study how different update strategies behave under different activity distributions . Therefore, this project focuses on constructing a self implemented one dimensional cellular automaton framework directly in Wolfram Language . The purpose is not necessarily to outperform Mathematica’s built in implementation, but instead to explore sparse updates, dynamic workload behavior, and hybrid update strategies in a high level symbolic programming environment .
Baseline Dense Updates
Baseline Dense Updates
The first implementation is a straightforward dense update cellular automaton.
baseline=Function{rule,init,t}, Nest Boole/@BooleanFunction[rule,3]@@@Partition[Join[Take[#,-1],#,Take[#,1]],3,1]& ,init,t ;
The implementation follows the standard definition of elementary cellular automata . At every step, the entire array is scanned regardless of how many cells are actually changing.
The expression:
Join[Take[#,-1],#,Take[#,1]]
creates cyclic boundary conditions by appending the last element to the front and the first element to the back. This allows the automaton to behave as a circular array.
Join[Take[#,-1],#,Take[#,1]]
creates cyclic boundary conditions by appending the last element to the front and the first element to the back. This allows the automaton to behave as a circular array.
Next,
Partition[...,3,1]
constructs all neighborhoods of length three. Each neighborhood corresponds to.
Partition[...,3,1]
constructs all neighborhoods of length three. Each neighborhood corresponds to
{,,xi+1}
x
i-1
x
i
The expression:
BooleanFunction[rule,3]
converts the rule number into a Boolean lookup function with three inputs. Finally, Nest repeatedly applies the update function t times.
BooleanFunction[rule,3]
converts the rule number into a Boolean lookup function with three inputs. Finally, Nest repeatedly applies the update function t times.
The theoretical time complexity of this implementation is:
, where n is the array length and t is the number of simulation steps.
O(nt)
, where n is the array length and t is the number of simulation steps.
Although simple and mathematically clean, this method wastes a significant amount of computation when only a small region of the automaton is active.
FunctionCompile Optimization
FunctionCompile Optimization
Inspired by Shenghui Yang, to reduce Wolfram Language interpreter overhead, a second dense implementation was created using FunctionCompile.
baselineWithFunctionCompile=FunctionCompile Function Typed[rule,"MachineInteger"], Typed[init,"PackedArray"["MachineInteger",1]], Typed[t,"MachineInteger"] , Nest MapBitGet[rule,4*#[[1]]+2*#[[2]]+#[[3]]]&, Partition[Join[Take[#,-1],#,Take[#,1]],3,1]&, init,t ;
Instead of using symbolic Boolean evaluation, this version directly extracts rule bits using:
BitGet
BitGet
The neighborhood:
is converted into the binary index:
, which directly accesses the corresponding output bit inside the rule number.
(a,b,c)
is converted into the binary index:
4a+2b+c
, which directly accesses the corresponding output bit inside the rule number.
The use of packed machine integer arrays significantly reduces memory overhead compared to symbolic expressions. This implementation is noticeably faster than the original dense baseline.
Performance measurements:
Performance measurements:
In[]:=
length=1000000;arr=ConstantArray[0,length];arr[[1]]=1;
In[]:=
First@Timing@baseline[30,arr,10]
Out[]=
2.30342
In[]:=
First@Timing@baselineWithFunctionCompile[30,arr,10]
Out[]=
1.95081
In[]:=
First@Timing@CellularAutomaton[30,arr,10]
Out[]=
0.009046
Even after compilation, Mathematica' s internal implementation remains dramatically faster . This highlights one of the major limitations of Wolfram Language as a high level symbolic environment : user level code still suffers from interpreter overhead, memory allocation costs, and higher constant factors compared to low level internal implementations .
Sparse Updates
Sparse Updates
The main limitation of dense updates is that they recompute every cell at every step . However, in many cellular automata, especially those initialized with localized patterns, most regions quickly become homogeneous.
The sparse update framework attempts to avoid recomputing these stable regions.
The core observation is:
If a neighborhood is completely homogeneous:
or
then large regions of the automaton may evolve predictably without requiring explicit recomputation of every cell.
If a neighborhood is completely homogeneous:
{0,0,0}
{1,1,1}
then large regions of the automaton may evolve predictably without requiring explicit recomputation of every cell.
Initially, the plan was to store all active cells inside a hash map using Mathematica Association . However, although this maintains linear asymptotic complexity, the actual runtime became very slow because Wolfram Language hash structures introduce large memory access overhead .
Therefore, active cells are instead maintained as sorted contiguous intervals represented using arrays.
Candidate Expansion Functions
Candidate Expansion Functions
The following helper functions maintain the active candidate set .
In[]:=
shiftLeft[arr_, n_] := Module[ {res = arr - 1}, If[And[res != {}, res[[1]] == 0], Append[Drop[res, 1], n], res] ]
shiftLeft shifts every candidate position one cell to the left while preserving cyclic boundaries.
shiftRight[arr_,n_]:=Module {res=arr+1}, If And[res!={},res[[-1]]==n+1], Prepend[Drop[res,-1],1], res
Similarly, shiftRight shifts candidates to the right.
merge[lst1_,lst2_]:=Module {i=1,j=1,L1=Length[lst1],L2=Length[lst2],last=-1}, Table Which And[i>L1,j>L2],Nothing, i>L1,j++;lst2[[j-1]], j>L2,i++;lst1[[i-1]], lst1[[i]]<lst2[[j]],i++;lst1[[i-1]], lst1[[i]]>lst2[[j]],j++;lst2[[j-1]], True,i++;j++;lst1[[i-1]] ,{x,L1+L2}
merge performs a linear two pointer merge of two sorted arrays while removing duplicates. This approach avoids expensive hash table operations and keeps candidate maintenance entirely array based.
In[]:=
expandCandidates[arr_,n_]:=Fold[merge,{arr,shiftLeft[arr,n],shiftRight[arr,n]}]
The candidate region for the next step is expanded to include all current candidates and their immediate neighbors. This follows from the locality of one dimensional cellular automata: a cell can only influence adjacent cells in the next update step.
Four Types of Rules
Four Types of Rules
The sparse update framework separates elementary cellular automata into four categories based on:
and
f(000)
f(111)
These two outputs determine how homogeneous background regions evolve.
This classification is the central idea behind the project.
This classification is the central idea behind the project.
Type 01 Rules
Type 01 Rules
f(000)0
f(111)1
For these rules, homogeneous regions remain unchanged .
The implementation is:
In[]:=
sparseUpdate01=Function{rule,init,t,f},Module {arr=init,step=t,n=Length[init],cand}, neighborhood[i_]:=Table[arr[[Mod[i+j-1,n]+1]],{j,-1,1}]; cand=Range[n]; Whilestep-->0, cand=Table[If[SameQ@@neighborhood[x],Nothing,x],{x,cand}]; Table[arr[[x[[1]]]]=f[x[[2]]],{x,Map[{#,neighborhood[#]}&,cand]}]; cand=expandCandidates[cand,n]; ; arr ;
At every iteration, neighborhoods that are completely homogeneous are removed from the candidate set. Only potentially changing cells are recomputed.
This is the most efficient sparse update category because stable background regions require almost no work.
Type 10 Rules
Type 10 Rules
In this case, homogeneous regions flip every iteration.
Instead of rewriting the entire array every step, the implementation stores the current background state using:
u={0,1}
and alternates it with:
u=1-u
Instead of rewriting the entire array every step, the implementation stores the current background state using:
u={0,1}
and alternates it with:
u=1-u
Code:
This avoids a full dense rewrite while still correctly maintaining the alternating background behavior.
Type 00 Rules
Type 00 Rules
Here, all homogeneous regions eventually decay toward zero.
The implementation stores cells requiring reset using a linked structure built from arrays:
nxt
pre
The implementation stores cells requiring reset using a linked structure built from arrays:
nxt
pre
Code:
The linked array structure avoids repeated memory allocations while efficiently processing large homogeneous regions.
Type 11 Rules
Type 11 Rules
This category is symmetric to Type 00. Homogeneous regions converge toward one instead of zero.
Code:
Unified Sparse Dispatcher
Unified Sparse Dispatcher
The four implementations are selected automatically:
This creates a unified sparse cellular automaton interface while preserving specialized optimizations for each rule category.
Benchmark Framework
Benchmark Framework
To evaluate when sparse updates are useful and when dense updates are preferable, I designed a benchmark framework that tests both implementations under controlled initial conditions.
The purpose of this framework is not only to record raw runtime, but also to build a predictive model that can later be used by the reload balancing strategy.
The initialization function is:
This function generates one dimensional binary arrays for testing. The parameter n controls the length of the array, while s controls the spread of active cells.
This is useful because sparse update performance depends not only on the number of active cells, but also on how fragmented or spread out they are.
A simple visualization is:
This plot shows how different spread values create different activity distributions. Low spread produces a localized pattern, while high spread produces a more global distribution. This benchmark design is important because sparse updates are expected to perform best when active cells are localized, and worse when active cells are widely spread.
Benchmark Execution
Benchmark Execution
The benchmark execution function performs a single controlled timing measurement.
This function takes a cellular automaton implementation func, a rule number, an array length, a spread value, and a number of steps.
The seed is computed deterministically from the input parameters. This ensures that the same benchmark configuration always generates the same initial array. Without this, dense and sparse results could be measured on different random inputs, making the comparison unreliable.
The warmup call is included because Wolfram Language often has extra overhead during the first evaluation of a function. Running a short warmup before timing reduces this first call effect.
The actual runtime is measured using:
RepeatedTiming
RepeatedTiming
instead of only Timing, because RepeatedTiming repeatedly evaluates the expression until a stable average can be estimated within the given timing budget.
Example usage:
Example usage:
Possible output:
Another example:
Possible output:
These results show that sparse updates are not automatically faster. When the array is small or the active cells are highly spread out, sparse bookkeeping overhead can dominate. This is why a reload strategy is necessary instead of always using sparse update.
Runtime Prediction
Runtime Prediction
After collecting benchmark data, I fit a runtime prediction model for each implementation. Instead of using 3D point clouds and heatmaps, which are difficult to read in a paper, I use line plots that show the runtime trend more directly.
This function does three things. First, it runs benchmarks over all combinations of array size, spread, and step count. Second, it fits a quadratic regression model for runtime. Third, it generates two line plots: runtime versus array size, and runtime versus spread.
Example usage :
Example usage :
The first plot shows how runtime changes with array size. For dense update, the curves are expected to be relatively regular, since the whole array is always scanned. For sparse update, the growth may depend more strongly on the spread of activity.
The second plot shows how runtime changes with spread. Dense update should be less sensitive to spread, while sparse update usually becomes slower as spread increases, because more cells must be tracked and updated.
To directly compare dense and sparse updates, I use the following function.
The second plot shows how runtime changes with spread. Dense update should be less sensitive to spread, while sparse update usually becomes slower as spread increases, because more cells must be tracked and updated.
To directly compare dense and sparse updates, I use the following function.
Example usage:
Example usage:
The first comparison plot directly shows which method is faster. The lower curve is the better choice.
If this value is below 1, sparse update is faster. If it is above 1, dense update is faster . The crossing point gives the estimated reload threshold . This is more useful than the original 3 D figures because it directly shows the crossover between dense and sparse updates. One can observe that, before some point, the performance of the sparse update model has been higher than the dense update mdoel.
Parallel Computing
Parallel Computing
The next part of the project explores parallel computing using Mathematica’s multi kernel system.
The main idea is to divide the one dimensional array into multiple consecutive segments, send each segment to a separate kernel, and update them in parallel.
The prototype implementation is:
The first important step is launching kernels:
CloseKernels[];
LaunchKernels[2];
Kernels[]
CloseKernels[];
LaunchKernels[2];
Kernels[]
The array is divided into k consecutive regions:
bounds = Ceiling@Subdivide[0, n, k];
bounds = Ceiling@Subdivide[0, n, k];
Each kernel receives one segment:
“range”->{bounds[[i]]+1,bounds[[i+1]]}
“range”->{bounds[[i]]+1,bounds[[i+1]]}
and stores its local copy of the subarray:
“arr”->Take[arr,{bounds[[i]]+1,bounds[[i+1]]}]
“arr”->Take[arr,{bounds[[i]]+1,bounds[[i+1]]}]
Because cellular automata depend on neighboring cells, each partition needs information from neighboring partitions. This is handled using boundary values:
borderOld
borderNew
borderOld
borderNew
The function:
get[x_]
checks whether position x is inside the current kernel’s local range. If it is, the value is read from arrOld. Otherwise, the value is read from borderOld.
get[x_]
checks whether position x is inside the current kernel’s local range. If it is, the value is read from arrOld. Otherwise, the value is read from borderOld.
The lookup table:
lut=Reverse@IntegerDigits[r,2,8];
stores the rule output for all eight possible neighborhoods.
lut=Reverse@IntegerDigits[r,2,8];
stores the rule output for all eight possible neighborhoods.
The update itself is:
arrNew=
Table[
lut[[get[x-1]*4+get[x]*2+get[x+1]+1]],
{x,range[[1]],range[[2]]}
];
This computes each new cell by converting the three bit neighborhood into a lookup table index.
arrNew=
Table[
lut[[get[x-1]*4+get[x]*2+get[x+1]+1]],
{x,range[[1]],range[[2]]}
];
This computes each new cell by converting the three bit neighborhood into a lookup table index.
After every kernel finishes a step, it writes its new boundary values into borderNew. Then:
{borderOld,borderNew}={borderNew,borderOld};
prepares the boundary information for the next iteration.
{borderOld,borderNew}={borderNew,borderOld};
prepares the boundary information for the next iteration.
This implementation demonstrates correct parallel dense updates with cyclic boundary handling. However, it also reveals a performance problem. Since all kernels must synchronize after every step, the fastest kernel waits for the slowest one. This is especially harmful when different parts of the array have different activity levels.
For this reason, simple uniform partitioning is not enough for the final hybrid strategy. The reload method should not only choose between sparse and dense updates globally, but should eventually divide the array into regions where low activity segments use sparse update and high activity segments use dense update.
This parallel version is therefore important because it shows both the potential and the limitation of direct multi kernel parallelization in Wolfram Language. The code demonstrates how halo exchange works, while also motivating the need for dynamic reload balancing.
For this reason, simple uniform partitioning is not enough for the final hybrid strategy. The reload method should not only choose between sparse and dense updates globally, but should eventually divide the array into regions where low activity segments use sparse update and high activity segments use dense update.
This parallel version is therefore important because it shows both the potential and the limitation of direct multi kernel parallelization in Wolfram Language. The code demonstrates how halo exchange works, while also motivating the need for dynamic reload balancing.
Example usage
Example usage
Reload Between Sparse and Dense Updates
Reload Between Sparse and Dense Updates
The reload strategy uses the benchmark predictors to decide whether to run dense or sparse update during execution.
Unlike a fixed choice of algorithm, reload update checks the current state of the automaton and chooses the predicted faster method.
Unlike a fixed choice of algorithm, reload update checks the current state of the automaton and chooses the predicted faster method.
The complete global reload implementation is:
This helper estimates the spread of activity. It first finds all positions containing 1. Then it expands each active cell by one neighbor on both sides and computes the fraction of the array covered by this expanded active region.
This is more informative than simply using:
Count[arr,1]/Length[arr]
because sparse update performance depends not only on the number of ones, but also on how much of the array is near activity.
This is more informative than simply using:
Count[arr,1]/Length[arr]
because sparse update performance depends not only on the number of ones, but also on how much of the array is near activity.
The reload update function is:
The function receives:
rule
init
t
predictDense
predictSparse
rule
init
t
predictDense
predictSparse
The predictors are produced earlier by BenchmarkFramework.
At every step, the algorithm computes the current activity spread :
spread = activeSpread[arr];
Then it predicts the cost of one dense step:
denseTime=predictDense[n,spread,1];
and one sparse step:
sparseTime=predictSparse[n,spread,1];
If sparse update is predicted to be faster, the algorithm runs:
arr=sparseUpdate[rule,arr,1];
Otherwise, it runs:
arr=baseline[rule,arr,1];
spread = activeSpread[arr];
Then it predicts the cost of one dense step:
denseTime=predictDense[n,spread,1];
and one sparse step:
sparseTime=predictSparse[n,spread,1];
If sparse update is predicted to be faster, the algorithm runs:
arr=sparseUpdate[rule,arr,1];
Otherwise, it runs:
arr=baseline[rule,arr,1];
The function also records a methodHistory list so that we can inspect which method was chosen at each step.
Example usage
Example usage
Here, the dense runtime predictor is multiplied by 20. This does not change the correctness of the cellular automaton . It only simulates a setting where dense update is more expensive, which makes the reload decision more meaningful for testing . To visualize the reload decisions, I use the following plots :
This figure shows which update method is selected at each step . A value of 0 means dense update, while a value of 1 means sparse update . If the curve stays near 1, the reload strategy mostly chooses sparse update . If it switches between 0 and 1, the strategy is adapting to changes in the automaton state .
When the ratio is below 1, sparse update is predicted to be faster. When the ratio is above 1, dense update is predicted to be faster . Therefore, the crossing point around 1 represents the switching boundary between the two methods.
Conclusion
Conclusion
Acknowledgements
Acknowledgements
This project was created as part of the Wolfram Emerging Leaders Program (WELP : U) . I would like to express my sincere gratitude to my mentor, Daniele Ceravolo, for his guidance, feedback, and support throughout the development of this project . I would also like to thank the program directors, Rory Foulger and Eryn Gillam, for organizing and leading WELP : U, and for providing a collaborative environment that encouraged independent research, exploration, and innovation . Finally, I am grateful to Wolfram Research and the broader WELP community for creating an opportunity to p rsue this project and explore the intersection of cellular automata, parallel computing, and algorithmic optimization within the Wolfram Language ecosystem.
CITE THIS NOTEBOOK
CITE THIS NOTEBOOK
ReloadCA: adaptive sparse and parallel cellular automata in Wolfram language
by Austin Jiang
Wolfram Community, STAFF PICKS, June 1, 2026
https://community.wolfram.com/groups/-/m/t/3724930
by Austin Jiang
Wolfram Community, STAFF PICKS, June 1, 2026
https://community.wolfram.com/groups/-/m/t/3724930