AI-assistance disclosure: I drafted this article with AI assistance, then edited it and fact-checked every number against the paper (arXiv:2611.14947).

Every accelerated MRI product hits the same trade. You skip k-space lines to cut scan time, and a network has to fill in what you skipped. The networks that win the reconstruction challenges do it with a stack of cascades, each with its own weights, so the model gets bigger every time you add a step. PromptMR+, which won both tasks of the CMRxRecon2024 challenge, is at 92.9M parameters. A team at Cedars-Sinai Medical Center in Los Angeles tried the opposite: reuse one good block at every step. The result is LoopMR, described in arXiv:2611.14947, with code and weights public under a non-commercial license.

What LoopMR does

LoopMR is an unrolled reconstruction network. It takes undersampled multi-coil k-space and the sampling mask, and returns a coil-combined image. It starts from the zero-filled image and coil sensitivity maps, which come from the sensitivity estimator of PromptMR+ (1.87M parameters). Then it runs the same loop 12 times.

In each pass, one Restormer block, a transformer that computes attention across channels rather than across pixels so it stays affordable at full MRI resolution, looks at the current image estimate and a few extra inputs. Those are the estimate pushed back through the acquisition mask, the zero-filled image, the difference between the two, and four latent images that act as the block’s memory of earlier passes. The block returns an image update and new latents. The update goes back to k-space, where a soft data-consistency step pulls it toward the k-space lines that were measured. The same block and the same two learned step sizes are used in every pass.

The block has 8.40M parameters and the whole model 10.27M. The released models also take five adjacent slices as input; on cardiac data those are adjacent time frames or weightings rather than slices.

What they tested it on

Brain: 67 fully sampled 12-coil T1-weighted volumes from Calgary-Campinas (CC359), with the exact split and Poisson-disc masks used by PromptMR+ (47 train, 10 validation, 10 test) at ×5 and ×10. Knee: 199 proton-density volumes from the fastMRI validation set, split 159 / 40, at ×4 and ×8. Heart: CMRxRecon2023 cine and T1/T2 mapping, 100 patients for training and 20 (76 files) for testing at ×4, ×8 and ×10. Carotid: an in-house set of 45 3D MPRAGE vessel-wall volumes from 6 to 27 receive coils at different centres, with the GRAPPA ×2 clinical reconstruction as reference, tested at ×6 and ×12.

The baselines are E2E-VarNet, PromptMR and PromptMR+. LoopMR came out ahead in PSNR and SSIM on all four datasets at every acceleration, and the difference against PromptMR+ was significant everywhere (p < 0.01, Wilcoxon signed-rank). Its SSIM was higher than PromptMR+ on 137 of 138 test cases. The margin was largest on the carotid data, where PSNR went up by 0.84 dB at ×6 and 0.76 dB at ×12 over PromptMR+.

If you read scans, look at the qualitative figures. On a CC359 slice at ×10, PromptMR+ draws a temporal sulcus as broken where the reference shows it continuous; LoopMR keeps it whole. On a fastMRI knee slice that carries a radiologist annotation from fastMRI+, LoopMR renders the subchondral bone edema closest to the reference. On the carotid set, it depicts the vessel wall closer to the reference than the other three methods. The featured image above shows the brain, knee and heart cases from Fig. 3, with error maps where brighter means further from the fully sampled image.

The finding behind the model

The authors also ran a controlled comparison. They trained the same model with one shared block and with distinct blocks at 6, 12 and 24 iterations. The shared version matched or beat the distinct one at every depth, with 5 to 20 times fewer parameters (10.2M against 52M, 102M and 202M). They then repeated the test with four block types. Shared transformer blocks (Restormer, SwinIR) held up or did better; shared CNN blocks (E2E-VarNet and PromptMR+ blocks) did worse, though the gap narrowed as the block grew. Their reading is that per-iteration weights mostly make up for a block that is too small, which would explain why older shared-weight models like MoDL, at about 0.1M parameters, lagged.

Two other details are useful if you build reconstruction pipelines. Going from 12 to 24 iterations bought little; a bigger block helped more than more passes. And training with a loss on every iteration, not only the final one, gives a model that produces a usable image after about four passes and stays stable past 12, for a cost of about 0.1 dB at the trained depth. The authors suggest that could power a fast preview on the console while the full reconstruction finishes.

Why a viewer or clinic team should care

LoopMR works on raw multi-coil k-space, before anything becomes a DICOM series. A PACS or a web viewer never sees the input it needs. So the direct users are scanner vendors, research sites that export raw data, and teams building reconstruction for low-field or custom sequences.

For a shop that builds clinical platforms around MRI, three things still apply. A 10M-parameter model is easier to ship, version and validate than a 93M one, and its peak memory on an H100 was 0.7 to 3.0 GB. A single block that you can run for a chosen number of passes fits a preview-then-final workflow better than a fixed cascade. And if you run research MRI with raw data access, this is a reconstruction baseline with public code, released weights and per-volume result files you can rerun without a GPU.

What it does not tell you yet

It is slower than PromptMR+. The saving is in parameters. Inference took 203 to 624 ms per slice on an H100, against 100 to 121 ms for PromptMR+.

Training sets are modest (47 training volumes on CC359). Whether distinct weights win back the advantage with large multi-site data is open.

Each model is trained for one dataset and one mask family (Poisson-disc on CC359, 1-D Cartesian elsewhere). The authors do not expect it to generalise to unseen anatomies or sampling patterns. It did hold its lead on unseen accelerations (×4 and ×16) and on fastMRI brain, which it never saw in training.

All undersampling is retrospective, and the carotid data is not public.

Quality was measured with PSNR and SSIM only. There is no radiologist reading, so hallucinated structure at high acceleration has not been assessed.

The PDF uses an IEEE Transactions on Medical Imaging template, but the arXiv listing does not state acceptance anywhere. Treat it as a preprint.

How to try it

The repository at github.com/hym97/LoopMR has training configs for CC359, fastMRI knee and CMRxRecon2023, evaluation scripts that follow each dataset’s official protocol, and a notebook committed with its outputs that reconstructs a CC359 slice at ×5 and ×10 and shows the image after 1, 2, 4, 8 and 12 passes. Weights for the three public datasets are on Hugging Face at hym97/loopmri, along with the PromptMR+ baselines the authors retrained for knee and heart. The stack is Python 3.10, PyTorch 2.8 and fastmri 0.3.0.

The license is the catch for commercial teams. The code and weights are CC BY-NC 4.0, the vendored PromptMR+ code is under a Rutgers non-commercial research license, and only the vendored SDUM code is Apache-2.0. You can study it, benchmark it and publish with it; you cannot put it in a product without talking to the authors. For other MRI reconstruction work on the blog, see LGGS, which uses a patient’s previous scan to speed up follow-up brain MRI, and GSMR3D for thick-slice brain MRI super-resolution.

Source and license

Paper: Yimeng He, Yibin Xie, Yi Zheng, Yifan Gao, Lixia Wang, Yin-Chen Hsu, Yufeng Wang, Meng Lu, Debiao Li and Xiuzhen Huang, “One Block Is Enough: LoopMR for Accelerated MRI Reconstruction”, arXiv:2611.14947 (eess.IV, 11 November 2026). All authors are with Cedars-Sinai Medical Center, Los Angeles (Biomedical Imaging Research Institute and Department of Computational Biomedicine); Debiao Li and Xiuzhen Huang are the corresponding authors. Code: github.com/hym97/LoopMR, CC BY-NC 4.0 (vendored PromptMR+ code under Rutgers’ non-commercial research license, vendored SDUM code Apache-2.0). Weights: huggingface.co/hym97/loopmri, CC BY-NC 4.0. Data: Calgary-Campinas, fastMRI and CMRxRecon2023 under their own terms; the carotid set is in-house. Featured image: Fig. 3 of the paper, PromptMR+ and LoopMR rows only, panels cropped and scaled.

Originally published on pycad.co, the canonical version: https://pycad.co/blog/loopmr-accelerated-mri-reconstruction-one-looped-block/

LoopMR: Accelerated MRI Reconstruction With One Looped Block was originally published in Python in Plain English on Medium, where people are continuing the conversation by highlighting and responding to this story.

For years I made the same embarrassing assumption. I believed that real AI had to be written in something fast and serious, like C++, and that Python was the friendly toy language people used before graduating to the grown up tools.

Then I opened the source of an actual modern AI project and went looking for the serious code. I found Python. Almost everywhere. Training scripts, data pipelines, evaluation loops, the glue holding the whole thing together.

That did not make sense to me. Python is slow. Everybody says so. So why does the most important technology of this decade run on it?

It took me an embarrassingly long time to find the answer, and it changed how I think about programming languages. Here is what I learned.

The Short Answer: Why Python Is Used for AI

Python for AI works because Python acts as the control layer, not the engine. Researchers write readable Python to describe models and experiments, while libraries like NumPy, PyTorch, and TensorFlow hand the heavy math to fast C, C++, and GPU code underneath. You get the speed of low level code with the writing speed of a scripting language.

That is the whole secret. The rest of this article explains how it happened, what the 2026 data says, and where Python still genuinely struggles.

It Started as an Accident

Python was created by Guido van Rossum and first released in 1991. It was designed to be readable, not to be fast, and certainly not to run neural networks. Nobody was planning an AI revolution.

What happened next was a slow, almost boring build up inside the scientific community:

Scientists wanted a free alternative to expensive proprietary tools for crunching numbers.

NumPy arrived and gave Python fast array math, with the real work done in compiled C underneath.

SciPy and Matplotlib added scientific algorithms and plotting.

IPython, and later Jupyter notebooks, let people mix code, charts, and notes in one place.

scikit learn gave beginners a consistent way to try classical machine learning in a few lines.

By the time deep learning exploded, Python was already the place where numerical people lived. The tools, the tutorials, and the habits were all there. The AI boom did not choose Python. It walked into a house that was already furnished.

5 Reasons Python Won the AI Race

1. It reads like pseudocode
2. Machine learning is full of ideas that change weekly. Researchers need to try a thought in an afternoon, not a month. Python’s clean syntax lets you express a model almost the way you would sketch it on paper.
3. Less time fighting the language means more time testing ideas. In research, that speed of iteration beats raw execution speed almost every time.

2. It is a glue language

This is the part I missed for years. Python is rarely doing the heavy computation itself. It calls into optimized libraries written in C, C++, and CUDA that run on GPUs.

When you write one line to multiply two giant matrices, Python simply passes the instruction along. The compiled code does the work. Python is the steering wheel. It was never meant to be the engine.

3. The ecosystem has gravity

Once NumPy, pandas, scikit learn, TensorFlow, and PyTorch all lived in Python, everything else followed. New research code shipped in Python. New tutorials were written in Python. New hires already knew Python.

That is a network effect. Each new library made the next developer more likely to choose Python, which made the next library more likely to be built for Python. It is extremely hard for a rival language to break that loop.

4. Notebooks made experimenting feel like a conversation

Jupyter notebooks let you run a small piece of code, look at the result, tweak it, and run it again. For exploring data and debugging models, that feedback loop is hard to beat. It made Python feel less like programming and more like thinking out loud.

5. Research culture picked it as the default

When a new paper comes out, the code that comes with it is overwhelmingly likely to be Python. TensorFlow, released by Google in 2015, helped push deep learning into the mainstream. PyTorch arrived from Facebook’s AI research group in 2016 and became a favorite in research because it felt like writing ordinary Python rather than describing a separate computation graph.

Later, platforms like Hugging Face made sharing and using pretrained models a few lines of Python. Each step pulled the field deeper into the same language.

The Two Language Secret Nobody Mentions

Here is the layered picture that finally made everything click for me.

Layer What it does Typical language

Your experiment Defines the model, data flow, and training loop Python

Framework Organizes tensors, gradients, and layers Python on the surface, C++ underneath

Math kernels Runs matrix operations at high speed C, C++, CUDA

Hardware Executes the math in parallel GPUs and other accelerators

Python lives at the top, where humans work. Fast languages live at the bottom, where machines work. Each layer does what it is best at.

So when someone says “Python is slow, so it cannot power AI,” they are looking at the wrong layer. The slow part is a thin layer of instructions. The fast part is everything those instructions trigger.

What the Data Says in 2026

Popularity depends on who is counting, and the sources do not agree. That is actually the interesting part.

Source:What it measures What it shows

Stack Overflow Developer Survey 2025 What developers say they use Python used by about 57.9 percent, up 7 percentage points from 2024

TIOBE Index, October 2026 Search activity about the language Python still ranks first, though its share is lower than its 2025 peak

GitHub Octoverse 2025 Contributor activity on GitHub TypeScript overtook Python and JavaScript in August 2025

My honest read: Python is not winning every race. JavaScript still leads in reported usage, and TypeScript now leads GitHub by contributor count, partly because AI coding assistants favor typed languages in everyday web work.

But for building and training AI itself, Python remains the default. Stack Overflow linked its jump in adoption to AI, data science, and back end development.

Where Python Genuinely Hurts

I promised an honest verdict, so here are the real problems.

The Global Interpreter Lock (GIL). For decades, the GIL meant only one thread could run Python code at a time, which limited multi core use for CPU heavy Python code. Teams worked around it with multiprocessing, which adds complexity and memory use.

Raw speed. Pure Python loops are slow. Performance critical code gets pushed down into compiled libraries, which is exactly why the two language setup exists.

Packaging and environments. Anyone who has fought with conflicting library versions knows this pain. It is the least glamorous problem in the ecosystem and one of the most common.

GPU memory and deployment. Python overhead matters less during training and more when you squeeze out latency in production, where teams often move serving code to other languages.

Python 3.14 Changes the GIL Story

Python 3.14 shipped in October 2025 with official support for a free threaded build that runs without the GIL. It is a separate build, so the standard version still keeps the lock.

Why this matters for AI: GPU heavy work already escapes the GIL, but the CPU side of pipelines, such as data preprocessing, evaluation, and multi agent systems, can now use multiple cores in a single process.

Early reports show real gains and real caveats:

One hands on test reported a file reading task dropping from about 18.8 seconds to 5.1 seconds with threads on the free threaded build.

The same test found a multiprocessing version of a matrix task running slower on the free threaded build than on the standard one, so it is not a magic switch.

Free threaded builds carry some extra memory use, and many third party C extensions still need updates before they work well.

Even Guido van Rossum has reportedly cautioned that the importance of removing the GIL can be overstated. His point is that Python’s real advantage is its ecosystem, not its threading model.

That matches my own conclusion. The language wins because of everything built around it, not because it is the fastest.

Will Something Replace Python?

Challengers exist. Julia targets numerical computing and rejoined the TIOBE top 20 in October 2026. Mojo aims to combine Python style syntax with systems level speed. Rust is increasingly used for fast tooling and data infrastructure.

None of them has the thing Python has: a decade and a half of libraries, tutorials, jobs, and habits. Replacing a language is easy. Replacing an ecosystem is not.

More likely, the future looks like the present with more layers. Python on top, faster languages doing more of the underlying work, and the boundary between them getting smoother.

If You Are Learning AI, Here Is What I Would Do

Learn core Python first. Functions, classes, lists, dictionaries, and reading error messages.

Get comfortable with NumPy and pandas. Almost everything else sits on top of them.

Train a small model with scikit learn. Understand data splits, overfitting, and evaluation before touching deep learning.

Move to PyTorch. Build a tiny neural network by hand, then use pretrained models.

Learn a little about what is underneath. Know what a GPU does and why tensor operations are fast. That knowledge separates people who use libraries from people who understand them.

Frequently Asked Questions

Why is Python used for AI and machine learning?

Python is readable, quick to experiment in, and surrounded by a huge ecosystem of libraries like NumPy, PyTorch, TensorFlow, and scikit learn. It acts as the control layer while fast compiled code does the heavy computation underneath.

Is Python too slow for AI?

Not for most AI work. The heavy math runs in optimized C, C++, and GPU code that Python simply calls. Python itself is slow for raw loops, but those loops are rarely where AI time is spent.

Is Python still the best language for AI in 2026?

For building and training models, yes, it remains the default. TypeScript has overtaken it on GitHub by contributor count and JavaScript leads in reported usage, but those measure broader software work rather than AI model development.

What is the GIL and does it matter for AI?

The Global Interpreter Lock lets only one thread run Python code at a time. Python 3.14 offers an optional free threaded build without it, which can help CPU heavy parts of AI pipelines, though library support is still maturing.

How Python Quietly Became the Brain Behind Modern AI was originally published in Python in Plain English on Medium, where people are continuing the conversation by highlighting and responding to this story.

The forward formula

The monthly payment on a fixed-rate loan has four parts:

payment = principal_and_interest + property_tax / 12 + insurance / 12 + hoa

Principal and interest uses the standard amortisation formula, with r the monthly rate and n the number of monthly payments:

principal_and_interest = loan × r / (1 − (1 + r)^−n)

When the rate is 0, this becomes loan / n.

Turning it around

Write the loan as price × (1 − down_share) and the tax as price × tax_rate. Everything that depends on the price then collapses into one number, the monthly cost per dollar of price:

per_dollar_of_price = (1 − down_share) × r / (1 − (1 + r)^−n) + tax_rate / 12

Insurance and HOA dues do not depend on the price, so they come off the budget first:

max_price = (budget − insurance / 12 − hoa) / per_dollar_of_price

The code

def payment_per_loan_dollar(annual_rate_pct, years):
    n = years * 12
    if annual_rate_pct == 0:
        return 1 / n
    r = annual_rate_pct / 100 / 12
    return r / (1 - (1 + r) ** -n)

def max_home_price(budget, down_pct, annual_rate_pct, years,
                   tax_pct_of_price, insurance_per_year, hoa_per_month=0):
    per_dollar = ((1 - down_pct / 100) * payment_per_loan_dollar(annual_rate_pct, years)
                  + tax_pct_of_price / 100 / 12)
    return (budget - insurance_per_year / 12 - hoa_per_month) / per_dollar

def monthly_payment(price, down_pct, annual_rate_pct, years,
                    tax_pct_of_price, insurance_per_year, hoa_per_month=0):
    loan = price * (1 - down_pct / 100)
    pi = loan * payment_per_loan_dollar(annual_rate_pct, years)
    return pi + price * tax_pct_of_price / 100 / 12 + insurance_per_year / 12 + hoa_per_month

price = max_home_price(2400, down_pct=10, annual_rate_pct=6.0, years=30,
                       tax_pct_of_price=1.2, insurance_per_year=1500)
print(round(price))                                                   # 355694
print(round(monthly_payment(price, 10, 6.0, 30, 1.2, 1500), 2))       # 2400.0
print(round(max_home_price(2400, 10, 7.0, 30, 1.2, 1500)))            # 325571

The second print is the test: feed the price back into the forward formula and you should get the budget again.

The worked example, step by step

Every input here is an example assumption, including the interest rate. It is not a forecast or a typical value.

• Budget: 2,400 a month, all-in. 10 % down, 30 years, 6.0 % a year (example assumption).
• Property tax: 1.2 % of the price a year (example assumption; it varies a lot by location). Insurance: 1,500 a year. No HOA.
• Monthly rate r = 0.06 ÷ 12 = 0.005, n = 360. Principal and interest per loan dollar = 0.00599551.
• Per dollar of price: 0.9 × 0.00599551 + 0.012 ÷ 12 = 0.00539595 + 0.00100000 = 0.00639595.
• Insurance is 1,500 ÷ 12 = 125 a month, leaving 2,400 − 125 = 2,275 for the price-dependent parts.
• Max price: 2,275 ÷ 0.00639595 = about 355,694.

Check with a price of 355,694: the loan is 320,124.60, principal and interest 1,919.31, tax 355.69, insurance 125.00, total 2,400.00.

The last line of the code shows how sensitive the answer is. Same budget, 7.0 % instead of 6.0 % (again an example, not a prediction): about 325,571, roughly 30,000 less.

What the formula leaves out

Private mortgage insurance, which a lender may add when the down payment is under 20 %. Closing costs, moving costs, repairs, utilities. Your credit, the loan type, and what a lender will actually offer. Treat the result as an upper bound for the budget you chose, and choose that budget from your own finances, not from what a lender approves.

Try it in the browser

The same payment formula, plus a price limit from an income guideline, runs in a free calculator, nothing stored: home affordability and monthly payment calculator.

Disclosure: I built the calculator linked above and make Viewingshub, a planned assistant (not available yet) for contacting listing agents and keeping track of home viewings. Written with AI assistance and checked by me.

From monthly budget to home price: inverting the mortgage payment formula in Python was originally published in Python in Plain English on Medium, where people are continuing the conversation by highlighting and responding to this story.

This is not legal advice: charge interest or a fee only if your contract or invoice terms allow it and your local law does too.

The formula

interest     = invoice amount × yearly rate × days late ÷ 365
interest/day = invoice amount × yearly rate ÷ 365
amount due   = invoice amount + interest + flat late fee

Three details matter:

• Days late count from the due date, not the invoice date. An invoice is only late once it is due.
• Simple interest: the rate applies to the invoice amount only, never to interest already added.
• A monthly rate converts by multiplying by 12 as simple interest: 1.5 % a month is 18 % a year.

The function

from datetime import date

def late_interest(amount, yearly_rate_pct, due, today, flat_fee=0.0):
    days_late = max(0, (today - due).days)
    per_day = amount * yearly_rate_pct / 100 / 365
    interest = amount * yearly_rate_pct / 100 * days_late / 365
    return {
        "days_late": days_late,
        "interest_per_day": round(per_day, 2),
        "interest": round(interest, 2),
        "amount_due": round(amount + interest + flat_fee, 2),
    }

print(late_interest(3200, 10, due=date(2026, 9, 30), today=date(2026, 11, 7), flat_fee=40))
# {'days_late': 38, 'interest_per_day': 0.88, 'interest': 33.32, 'amount_due': 3273.32}

The inputs are an example, not a recommendation: a 3,200 invoice, a yearly rate of 10 % and a flat fee of 40 are assumptions for this example. Substitute what your terms actually say.

Step by step:

• Days late: 30 September to 7 November is 38 days.
• Interest per day: 3,200 × 0.10 ÷ 365 = 0.8767, shown as 0.88.
• Interest: 3,200 × 0.10 × 38 ÷ 365 = 33.32.
• Amount due: 3,200 + 33.32 + 40 = 3,273.32.

Why the function does not multiply the rounded daily figure

0.88 × 38 = 33.44, twelve cents more than 33.32. If you round the daily interest first and then multiply, the error grows with every day. Compute the total from the unrounded values and round once at the end; show the daily figure on the reminder only as information.

Where the rate comes from

Use the rate written in your contract or invoice terms. Some countries also set a statutory rate for late payments between businesses, usually as a reference rate plus a margin, and those reference rates change over time. In the UK, for example, GOV.UK describes statutory interest on late commercial payments as 8 % plus the Bank of England base rate, where no other rate is agreed in the contract. Check the official page for your country on the day you calculate, and pass the result in as yearly_rate_pct.

Some places also cap late fees or interest, and rules for consumers are often stricter than for business customers. That is a legal question the arithmetic cannot answer.

Put the working on the reminder

List the original amount, the due date, the days late, the rate, the interest and any fee, each on its own line. A client who can recompute the figure has less to dispute.

Without code

The same formula runs in a free calculator, no sign-up, nothing stored: late invoice interest calculator.

Disclosure: I built the calculator linked above and make Clientsroster, a Notion template for freelancers that tracks leads, clients, projects and which invoices are due, paid or overdue. Written with AI assistance and checked by me.

Late-payment interest on an overdue invoice, as a Python function was originally published in Python in Plain English on Medium, where people are continuing the conversation by highlighting and responding to this story.