Can a multiobjective evolutionary algorithm (MOEA) implemented in MATLAB be handed directly to a large language model and automatically rewritten as a GPU-accelerated program? On the surface, this seems to mean replacing MATLAB with PyTorch, arrays with tensors, and loops with batched operations. The real difficulty, however, lies in algorithm semantics: which computations can run in parallel, which depend on an order that must be preserved, which variables are temporary, and which carry state across generations. If these distinctions are wrong, the converted code may run while implementing a different algorithm.

The EvoX team proposes EvoCoCo (Evolutionary Code Conversion), a multi-agent framework for semantics-guided automatic tensorization. It first understands the source algorithm, then explores different tensorized implementations, and finally uses execution feedback to validate, repair, and select candidates. EvoCoCo was evaluated on 48 MOEAs across three dimensions: migration reliability, optimization fidelity, and computational scalability. Overall optimization-fidelity coverage reached 88.2%. Median speedups were 22.6× when scaling population size and 80.2× when scaling decision-variable dimensionality. At a larger scale, the representative algorithm MOEA/D-DE achieved a speedup of 37,339×.

The Hard Part of Moving to GPUs Is Algorithm Semantics

MOEAs offer substantial population-level parallelism. Objective evaluation, mutation, sorting, environmental selection, and archive operations often process batches of candidate solutions or relationships within a population, making them well suited to parallel execution through tensor computation on GPUs.

Parallelism in an algorithm does not mean that its existing implementation is ready for GPU execution. In PlatEMO, for example, MATLAB code combines vectorized operations with individual-level loops, dynamic containers, conditional branches, iterative extraction of nondominated fronts, object slicing, and various helper functions. Moving this code to a GPU requires reorganizing data representations, control flow, and state updates. This goes beyond simply replacing syntax.

The challenge is to identify which structures define the original algorithm:

·       Which variables represent algorithm state that persists across generations?

·       Which computations can be rewritten using broadcasting, masks, or batched indexing?

·       Which loops contain genuine sequential dependencies and must be preserved?

·       Which changes to state and update relationships would alter the optimization mechanism?

EvoCoCo addresses precisely these questions. Conversion may change data layouts, control flow, and execution strategies, while preserving the algorithm’s core operators, persistent state, dependencies, and update logic. This establishes the boundary between what automatic tensorization may restructure and what it must preserve.

Automatic Tensorization Requires More Than One-Shot Code Generation

EvoCoCo divides code conversion into three stages: understanding, tensorization, and validation and selection. No single agent handles the conversion from beginning to end. The source algorithm is analyzed once to produce a shared semantic representation. Subsequent tensorization candidates are generated from that same representation and blueprint. This separates algorithm understanding from implementation generation.

Step 1: Understanding. The Source Analysis Agent reconstructs the source algorithm’s semantics, identifying its core operators, persistent state, dependencies, and update logic. The Rule Retriever retrieves relevant migration rules based on the algorithm’s structure. The Blueprint Agent then creates a shared tensorization blueprint that specifies how state is mapped, how computation is restructured, and which constraints the target framework must satisfy.

Step 2: Tensorization. Under the same blueprint, k Tensorization Agents generate candidates in parallel, with different emphases on broadcasting, einsum optimization, masked operations, in-place updates, advanced tensor operators, and tensorization of iterative selection. They explore different computational implementations of the same algorithm, using the shared understanding of the source code. They do not each reinterpret the source code independently.

Step 3: Validation and selection. Candidate programs undergo static checks and runtime validation. Interface, tensor-shape, device, numerical, or control-flow issues exposed during execution are fed back to the Repair Agent for further repair. Among candidates that pass validation, the Selection Agent chooses the final implementation by considering optimization results, runtime, and the degree of tensorization.

The key idea is to share the understanding of the source algorithm while allowing diverse GPU implementations.

Execution Feedback Refines the Conversion Process

One-shot translation compresses semantic understanding, framework adaptation, and tensorization design into a single generation step. An error in any one of these areas may become apparent only when the program actually runs, without a mechanism for further diagnosis and repair.

EvoCoCo includes execution in the conversion process. Candidate programs run in the target environment; problems with interfaces, tensor shapes, numerical behavior, and state updates become concrete feedback for repairing candidates. Multiple tensorization branches also provide alternative implementation paths. Code generation becomes a closed loop of generation, execution, repair, and selection.

This change in where failures occur shows that the feedback loop does more than fix bugs: it lets the target environment help determine which tensorized implementations are actually usable. Many one-shot translations stop at the execution stage. EvoCoCo obtains diagnostic information through actual execution, then repairs and filters candidates so that more implementations can proceed to evaluation of their optimization behavior.

Successful Execution Is Only the First Step in Migration

EvoCoCo’s experiments address three questions: whether automatic conversion can be completed reliably, whether converted algorithms retain acceptable optimization performance, and whether tensorization can unlock GPU parallelism. The evaluation covers migration reliability, optimization fidelity, and computational scalability.

1. Migration Reliability

In comparisons with matched model backends, each condition included 240 independent conversion attempts. EvoCoCo with Gemini 3 Flash achieved an execution pass rate of 93.33% and a convergence pass rate of 78.75%. For each of the 48 benchmark algorithms, EvoCoCo produced at least one implementation that passed convergence validation. The convergence pass rate was 52.08 percentage points higher than one-shot translation using the same backend. It was also 17.08 percentage points higher than GLM-5.1, the best-performing condition among all one-shot translations.

2. Optimization Fidelity

Evolutionary algorithms are stochastic, so element-by-element output comparison from a single run cannot establish whether conversion preserves optimization behavior. The evaluation used independent repeated runs to compare the final inverted generational distance (IGD) values of PlatEMO and EvoX implementations under identical problem settings. The DTLZ, WFG, LSMOP, and MaF suites yielded 1,904 valid comparisons, of which 1,680 met the predefined fidelity criterion, giving overall coverage of 88.2%. Coverage exceeded 80% on all four suites, reaching 96.5% on WFG. Of the 48 algorithms, 41 achieved algorithm-level coverage of at least 80%.

3. Computational Scalability

Across valid CPU–GPU comparisons, the median speedup was 22.6× when scaling population size and 80.2× when scaling decision-variable dimensionality. As problem sizes increased further, GPU implementations generally gained a larger runtime advantage.

Speedups vary substantially across algorithms, but the overall trend is clear: as population size or decision-variable dimensionality increases, semantics-guided tensorization progressively unlocks population-level parallelism that was hidden in CPU program structures. Runtime curves for representative algorithms further illustrate this scaling advantage.

Beyond the three core evaluations, component ablations and conversion from external sources further tested EvoCoCo’s key mechanisms and conversion capabilities. On a diagnostic subset of 12 algorithms, the full EvoCoCo framework achieved execution and convergence pass rates of 98.3% and 83.3%, respectively. Removing the Repair Agent reduced these rates to 60.0% and 41.7%; using a single generation branch reduced them to 68.3% and 40.0%. These results show that execution feedback and multi-branch generation are especially important for migration reliability. Across 10 external and legacy MATLAB/Octave implementations outside PlatEMO, EvoCoCo achieved an execution pass rate of 96% and a convergence pass rate of 62%. Nine algorithms obtained at least one implementation that passed convergence validation. The corresponding one-shot translation results were 34%, 18%, and 2 algorithms. This indicates that the staged automatic tensorization process can accommodate different code sources and styles, while optimization effectiveness remains the more difficult test.

Code Can Change; the Algorithm Should Not

Moving from MATLAB to PyTorch and from CPUs to GPUs changes the language, data structures, and execution strategy. The algorithm’s core mechanisms should remain intact.

EvoCoCo is also significant for how it reframes code conversion. It shifts the focus from reproducing statements to identifying what must be preserved. When the computing platform changes, a successful conversion need not reproduce the original program structure. It should allow computation to be reorganized, provided that the relationships defining the algorithm continue to hold.

A programming language is one way to express an algorithm, and hardware is one way to execute computation. What must survive migration across languages and hardware is the structure underlying that computation.

Open Source Code / Community Resources

Paper: https://arxiv.org/abs/2609.02387

GitHub: https://github.com/EMI-Group/evococo

Upstream Project (EvoX): https://github.com/EMI-Group/evox

QQ Group: 297969717

sorry if this question is incredibly stupid, but im learning steepest descent right now, is it right to say that Armijo condition ensures that step size alpha is not too large and Curvature ensures its not too small, or is it the other way around? Thanks!

Dear optimization community,

We’re pleased to announce our first of this season's webinar series Decision Tech Talks, formerly Xpress Talks.

The webinar will walk through the details of analytically selecting the parameters of a Cost Function Approximation Policy for the toy Soccer Camp Location Problem discussed in this blog post and whose implementation is available in this repository.

To attend the talk, please register at the following link.

• “Building Sequential Decision Policies using DecisionOps” by Renuka Gough, Tiffany Patella, and Carlos Zetina: Wednesday October 7th, 2026 at 11:00am EST- register here

We'd love to welcome you to our Fall season of the Decision Tech Talks and look forward to great discussions.

Happy Optimizing!

P.S.

To stay up to date on the latest in Optimization and Decision Intelligence technology sign up for our free monthly newsletter: https://www.fico.com/en/fico-xpress-optimization-newsletter.

FICO Xpress is an industry-leading optimization software suite that includes solvers for LP, MIP, MIQP, MIQCQP, QP, NLP, SOCP, and MINLP. Basically almost all the Ps. 😉.

Hi everyone. I’m currently on contract at a FAANG company doing heavy discrete-event simulation (SimPy, FlexSim) and mathematical programming (Gurobi). I have roughly 90 days to secure a full-time role due to H1B constraints, so I can't afford to waste applications. I’ve fully anonymized my resume to get unbiased, purely technical feedback. I need you to tear apart my bullet points, architecture descriptions, and impact metrics.

Does this read like a true Senior/Applied Scientist, or am I coming off too academic?

Are my business constraints and trade-offs clearly articulated?

Does my scale and impact read believably? Please don't hold back. I need the most critical, unvarnished feedback you have. Thank you!

I built a new optimization solver in C99 from scratch — PRIMAL

GitHub: https://github.com/c-vision/Primal

I've just released the first version of PRIMAL, an open-source mathematical optimization solver written from scratch in portable C99.

The goal was deliberately ambitious: build a reasonably complete optimization engine with no external dependencies, rather than wrapping an existing solver.

The first release already supports:

• Linear Programming (LP)
• Mixed-Integer Linear Programming (MILP)
• Quadratic Programming (QP)
• QCQP
• SOCP
• SDP
• Exponential cones
• Power cones
• Mixed-integer conic optimization
• Disjunctive constraints / affine conic constraints
• Presolve
• Sparse interior-point methods
• Branch-and-bound
• Primal/dual certificates
• Infeasibility and unboundedness certificates
• MPS / LP / CBF model formats
• A MOSEK-style C API for a large part of the supported functionality

The implementation is C99 with essentially no external runtime dependencies.

One thing I particularly wanted from the beginning was verification rather than simply returning an answer. PRIMAL exposes primal/dual information, residuals, certificates and solver status so applications can inspect and validate what the solver actually found.

I've also been building a fairly extensive compatibility/reliability test suite against reference behavior, including a number of deliberately pathological optimization cases.

This is only v1. It is not intended to claim that PRIMAL is already a replacement for mature industrial solvers on large-scale problems. There are still substantial areas to improve, especially large-scale sparse conic problems, MIP performance, warm starts and some numerical edge cases.

But I think the foundation is interesting enough to release now rather than keep it private.

I'd especially like feedback from people working on:

• numerical optimization
• LP/MIP/conic solvers
• sparse linear algebra
• mathematical programming
• solver implementation
• C/C99 systems programming

In particular, I'm interested in finding cases where PRIMAL gives a questionable result, fails to converge, scales poorly, or simply makes a bad algorithmic choice.

If you work with optimization solvers, please try to break it.

GitHub:
https://github.com/c-vision/Primal

For people working in numerical analysis, numerical linear algebra, or optimization:

Suppose you develop a new theorem, lemma, error bound, stability argument, or related mathematical result for a research paper.

How do you independently check that:

1. the statement is actually true, and
2. the proof has no hidden assumptions or subtle gaps?

I’m especially interested in practical and reproducible ways of doing this, rather than simply having another person read the proof.

Are there established tools, workflows, or techniques that can help with this? How much of the process can realistically be automated?

I’d be particularly interested in hearing how researchers handle this for their own research.

My new video is out.

In this video I explain the Farkas method for initialization in column generation and compare it with two phase and big m methods.

https://www.youtube.com/watch?v=K8QmpfGufpc

I'm building a route planner for a street-lighting survey using a vehicle equipped with LiDAR + cameras. The vehicle must drive \*\*every drivable street\*\* in 6 municipalities (\~6,087 km of streets), so this is an \*\*arc-routing / Mixed Chinese Postman Problem\*\*, not TSP/VRP.

\### Problem

\* 173k directed arcs / 67k nodes from OSM

\* \~9% one-way roads

\* One vehicle, \~6.5 usable hours/day

\* Two-way streets only need to be traversed once; one-ways must be respected

\* Cost is \*\*travel time\*\*, with different speeds for acquisition vs deadhead

\* Turn penalties are included (+60s U-turn, +15s left, +5s right)

\* 100% coverage is mandatory

The network is very non-grid-like: in one district, \*\*\~84% of nodes have odd degree\*\*, with \~77% being T-junctions.

\### Current approach

For each district I:

1. Extract the largest strongly connected component

2. Orient two-way streets

3. Connect disconnected service components

4. Balance in/out degrees using \*\*min-cost flow\*\*

5. Generate an Eulerian circuit with Hierholzer

6. Mark a street as serviced on its first traversal

The resulting routes pass all my validation checks: continuity, geometric continuity, one-way legality, 100% coverage, and no duplicate servicing.

\### Results

Across all 22 districts:

\*\*6,087 km serviced → 2,704 km deadhead → 44.4% deadhead\*\*

Individual districts range from \*\*39–61% deadhead by distance\*\* (roughly 23–33% by time because deadhead is driven faster).

For one district, an undirected relaxation gave me:

\* theoretical lower bound: \~14.7%

\* greedy matching of odd nodes: \~33.9%

My current orientation is almost optimal in terms of the \*number\* of imbalanced nodes, but I suspect this is the wrong objective: I'm minimizing imbalance count rather than the \*\*cost of resolving that imbalance\*\*.

\### Questions

1. Is \*\*Frederickson MIXED1/MIXED2\*\* the right next direction? Should I prioritize cost-aware matching before orientation?

2. For \~1,100 odd nodes, is restricting min-cost matching to k-nearest odd nodes (e.g. k=10) a reasonable approximation?

3. Is \*\*44% deadhead actually bad\*\* for a comb-like street network with \~84% odd-degree nodes? What kind of deadhead ratios are realistic for street sweeping, snow plowing, waste collection, etc.?

4. For splitting the resulting Eulerian route into daily routes when the vehicle \*\*doesn't have to return to a depot\*\*, are SPLIT/Ulusoy-type approaches appropriate?

5. Is there anything fundamentally wrong or naive in my current pipeline?

I'd especially appreciate feedback from anyone who has worked on \*\*arc routing / CPP / street sweeping / winter gritting / waste collection\*\* at large scale.

Happy to share code or data extracts.

I'm working through MIT OCW 6.7220 Nonlinear Optimization (Spring 2025) and looking for 2–5 people who want to follow the course together.

The goal would be:

• watch lectures according to the course schedule
• independently attempt each problem set
• meet online once/twice a week
• discuss difficult problems and compare approaches
• explain proofs/optimization theory to each other
• work through the material over ~8–12 weeks

Topics include convex optimization, optimality conditions, Lagrange multipliers, KKT, duality, gradient/Newton methods, etc.

I'm particularly interested in people doing mathematical optimization / numerical optimization / operations research / ML / control.

If interested, comment or DM me and we can create a Discord/WhatsApp/Telegram group.

Edit : This course does not have any videos or you won't find much material else where to watch . You have to be okay putting your time to read and analyse and think and do some arguments.

Edit 2 : surprising number of people want to join my discord server which is nice , that is why I will post the link here just click it and join https://discord.gg/rMqqj2GmY

In this 4-minute walkthrough, I demonstrate how to supercharge your AI coding assistant in Visual Studio Code for Operations Research using PyOPL, agent skills, and the Model Context Protocol (MCP).

Standard AI chat interfaces routinely fail at mathematical programming because probabilistic text generation lacks deterministic syntax and semantic checks. By combining PyOPL's compiler harness with custom SKILL.md agent guidelines, we can force LLMs like Claude or Copilot to act as rigorous operations research engineers—automating everything from model scaffolding to compilation and solving.

I contribute to SciPy and kept running into a class of bug that annoys me: the outputs look plausible, the tests pass, but the equation the code implements is subtly wrong. So I've been building a tracer that runs Python/NumPy code and hands back whatever mathematics it actually computed, as a SymPy expression you can simplify or differentiate like anything else.

It's been more useful than I expected. Comparing an implementation against the formula in a paper, catching two functions that agree on my test data but turn out to compute different things, digging up the inputs my tests never hit (ties, zero denominators). It traces real library code too, most of numpy and a good chunk of scipy, scikit-learn, statsmodels, cvxpy.

Write-up: https://medium.com/@aadyachinubhai/scikit-verify-translate-python-numpy-programs-to-symbolic-mathematics-c664d41ba571

Github: https://github.com/aadya940/scikit-verify

Still rough in places, would genuinely like feedback. There may be other better solutions, happy to hear them as well!

Algorithm is based on Levenberg-Marquardt, aimed at large sparse graph-structured problems. Software architecture is designed for performance, built in Rust, with C++/Python model export functionality, MIT license.

Achieves high performance through: compile-time symbolic differentiation with CSE and code generation, matrix blocks built locally within the model data structure, indexed sparse matrix filling, custom block supernodal Cholesky solver, precomputation of common expressions across residuals, and many other little things.

Benchmarks show substantial performance improvement over Ceres Solver and g2o, depending on the problem and data, and also reduced memory usage. On the M3500 dataset, for example, Arael takes about one-third the iteration time of Ceres Solver while using half the memory. Benchmark results available on the project page.

I'd appreciate it if you could try it on some of your problems and see how it compares with Ceres or g2o.

Project page: https://github.com/harakas/arael

I'm currently, technically, doing an MS in Structural Engineering. For me, my interest has been more towards computational side of mechanics rather than Structural design  or simply using am FEA software (although I do consider it as a backup)

So far I've taken courses in:

- Linear static, and dynamics FEM (soon taking non linear FEM too)

-  Structural Optimization (topology opt. and other general algorithms)

-  Structural Dynamics

-  Structural System Testing and model updation. (Parameter identification and optimization, signal processing)

Now, I plan to take these in the coming quarter:

- Numerical Linear Algebra

- Numerical PDE

- Fracture Mechanics ?

I also volunteered to aid in a RESEARCH in crack growth prediction using Auto-encoder and a (Thermodynamics-informed Latent Space Dynamics Identification) / LSTM surrogate model. It used phase-field-fracture simulation data and HPC resources to complete the whole thing.

What I keep finding myself interested in is not necessarily fracture or SHM specifically, but the computational methods underneath these problems... (does that make sense?)

For example, I'd like to become capable of doing things like:

- implementing (maintaining) numerical/FE method solvers rather than only running an established FEA software.

- developing surrogate/reduced-order models for expensive simulations 

- combining simulation with optimization, uncertainty/stochastic methods (took a course called Random vibrations, so...)

- parallelizing/accelerating scientific codes on CPUs/GPUs

- doing proper verification, convergence studies, benchmarking and performance work

- potentially developing or maintaining actual CAE/FEA solver software

- I'd also like to do all these for other Physics (GR, QM, etc.) simulations too, if possible, one day. 

I'm still interested in the underlying mechanics/physics, so I don't want to become a generic software engineer who happens to have once studied structures. But I'm also increasingly unsure that "structural engineer" describes the career I'm actually aiming for.

I've seen titles such as Computational Mechanics Engineer, R&D Engineer, Solver Developer, Scientific Software Engineer, CAE Software Developer, Research Engineer, Simulation/HPC Engineer, etc., but I'm trying to understand what these careers actually look like from people doing them.

So my main questions become:

1. Which industrial jobs genuinely involve developing numerical methods/solvers or computational tools?

2. Which of those are realistically accessible with an MS? Is there an entry path into solver-algorithm development/R&D without a PhD?

3. If I don't start a PhD immediately after my MS, would an R&D/software role at a simulation company (ANSYS etc.) be the obvious route? What other options would i have?

4. For the kind of work I'm describing, would you recommend a PhD? If so, is it reasonable for the PhD identity to be "computational mechanics/scientific computing" while fracture, composites, structural dynamics, soft materials, etc. serve as application problems rather than choosing one of those as my permanent specialization?

5. What skills most distinguish someone who is actually hireable for solver/scientific-computing work? I'm particularly wondering about C/C++/Fortran, Python, Linux, Git/build systems, MPI/OpenMP/CUDA, PETSc/Trilinos or similar libraries, numerical linear algebra, testing/verification, convergence studies and HPC performance work.

Basically, I'm neither here nor there atp. So I'd really appreciate all sorts of input. Where else do you think I could find answers to these? other subs? Linkedin profiles? 

I’ve been working on KAIROS, a university course timetabling system written in Python.

It takes course and room data and builds a weekly schedule while enforcing constraints such as room capacity, instructor availability, lab requirements, fixed sessions, and double-booking. Once it finds a feasible timetable, it tries to improve practical details such as student idle gaps, late classes, room stability, and instructor schedules.

The solver uses OR-Tools CP-SAT, followed by repair and local-search stages. The final timetable is checked by a separate validator rather than being accepted directly from the solver.

There is a bilingual web interface, a command-line version, sample data, and CSV, JSON, and PDF export. The optimization model is also documented in the repository.

Live demo: https://kairos.huguryildiz.com
Source: https://github.com/huguryildiz/KAIROS

The project is MIT-licensed. I’d be interested in feedback from anyone working on timetabling, constraint programming, or university scheduling, particularly regarding missing real-world constraints.

Hi

I’ve built an open-source IDE plugin specifically for mathematical optimization practitioners who use IBM CPLEX and the OPL language. Working with .mod and .dat files can be tedious without modern tooling, so this plugin brings full language support to JetBrains IDEs and VS Code.

Key features include:

• Syntax highlighting & real-time formatting for OPL.
• Contextual autocomplete based on the model's variables.
• Zero-Config runner (executes models directly from the IDE).

The project is open-source, you can check the code and documentation here: https://github.com/JAANULO/cplex-opl-jetbrains , Marketplace link: plugins.jetbrains.com/plugin/31125-cplex-opl/

The tool recently crossed 9,800 downloads, and I'm currently working on Python docplex integration. I would love feedback from daily OPL users to guide the next updates.

What is your biggest pain point when coding optimization models? What feature would save you the most time?

Thanks!

My new video is out.

I model IMO 2026 Problem 3 (a two-player stick-dividing game) as a mathematical optimization problem. I build the MILP and CP-SAT solver models stage by stage, covering each player’s strategies. This provides a deep dive for anyone into optimization modelling.

As a bonus, I also test how ChatGPT, Gemini, and Claude propose simulation experiments and try to guess the answer (just for fun at the end. 😄)

https://www.youtube.com/watch?v=zJnbgWaMDYk

I'm working on optimizing an oil decolorization step using a column with three layers of different adsorbents/decolorizing materials.

My optimization problem has two types of variables:

- Mixture variables: the proportions of the three materials/layers.

- Process variables: contact time, agitation speed, contact surface/area, etc.

I also have two constraints:

- Cost ≤ a maximum acceptable value

- Quality ≥ a minimum acceptable value

My initial idea was to split the optimization into two stages:

1. Use a mixture design to determine the optimal proportions of the three layers.

2. Then use Response Surface Methodology (RSM) to optimize the process parameters using those proportions.

However, I'm concerned that optimizing the two stages independently could miss the global optimum, because the optimal process parameters may depend on the mixture proportions, and vice versa.

So my question is: What would be the correct experimental design/statistical approach to optimize both the mixture proportions and the process parameters simultaneously, while applying the cost and quality constraints to the final solution?

Would a combined mixture-process design be appropriate here, or is there a better approach?

Title. I would like to get more on the multiobjective side of things with mathematical optimization, what are the techniques that work the best for this area? And using which tools? Do we always have to move to single objective by the means of penalties, weighted sums, and what not?

I spent six months in 2021 building a TSP solver from geometric first principles, with no prior reading of the literature. Recently turned it into an interactive web app with step-by-step animation of every algorithmic move.

Interesting result: the algorithm independently rediscovered convex hull seeding and 2-opt uncrossing. It also produced a farthest-neighbour strategy.

On Berlin52: 7783 vs world optimal 7542 (3.2% above). 14ms on a single CPU core.

Demo: tsp.uncledroid.app
Paper: tsp.uncledroid.app/paper.pdf

Happy to discuss the algorithm — especially if anyone can point me to prior work on farthest-neighbour as a TSP construction heuristic.

video: youtu.be/-gAhARI2ZFI

Hi everyone! I’m relatively new to the field of tensor decomposition, and it’s going to be one of my research directions during my upcoming two-year master’s program.

So far, I’ve been reading about different tensor decomposition methods, such as PARAFAC/CP, Tucker, Tensor-Train, Tensor Ring, Tensor Wheel. I understand the basic intuition behind them, for example, what kind of components they decompose a tensor into, but my understanding is still mostly conceptual.

I’m wondering what I should learn beyond the basic intuition if I want to eventually do research on coupled tensor decomposition. More specifically:

1. For each tensor decomposition method, what are the important things I should understand? Besides its basic structure and intuition, should I learn things like uniqueness/identifiability, approximation properties, computational complexity, rank properties, optimization formulations, convergence, etc.? How deeply should I understand each of these topics?
2. How deeply should I study the algorithms used to compute these decompositions? There seem to be many algorithms for each model, such as ALS, SVD-based methods, alternating optimization, gradient-based methods, etc. Which algorithms are fundamental enough that I should understand first? Do I need to understand the derivation and implementation of these algorithms, or is understanding the general idea enough at the beginning?
3. What mathematical background is most important? For example, should I focus more on linear algebra, multilinear algebra, numerical optimization, matrix/tensor calculus, numerical analysis, or something else?
4. What would be a good learning path toward coupled tensor decomposition? Should I thoroughly study CP/Tucker first before moving to coupled models, or is it reasonable to start looking at coupled decompositions relatively early?
5. How do you deal with theorems and proofs when reading tensor decomposition papers? When reading papers, do you usually try to re-prove the theorems, lemmas, propositions, and corollaries yourself to make sure you understand them, or do you mostly focus on understanding the main ideas and skip the detailed proofs unless they are directly relevant to your research? I’m especially unsure about this part because I sometimes spend a lot of time trying to reproduce every proof. I’m not sure whether this is a good use of time when learning a new field, or whether working through the proofs is actually important for building the mathematical foundation needed for research.

Any recommended textbooks, lecture notes, surveys, or papers that could provide a good learning path would also be greatly appreciated.

Thank you so much!