Quantum State, Non-Locality, and Interpretation

As someone coming from a materials science and engineering background, I've always approached quantum mechanics with a pragmatic mindset: it's a tool to make useful predictions. My guess is most in applied disciplines have a smiliar perspective. But sometimes I find myself asking detailed questions on the language used to describe the theory itself. I mean what does non-local actually refer to? When you try to find out just plain boring explanations I think your meet with assumptions that both reader and author are on the same standing about the meaning of words. This poor assumption is where I think, or at least I found for me, the confusion surrounding QM stems from sloppy language and mismatched conceptual frameworks, particularly around the nature of the quantum state space (i.e., wave function) and the term non-locality. I'm going to write about how I've come to understand the perspectives on the foundations of quantum mechanics.

Quantum State/Wave Function

I will use the quantum state and wave function interchangeably, but this is ironic because I've just lambasted about the lack of clarity in the language used to describe QM. The specifics are the quantum state is a complex-valued vector in a Hilbert space, while the wave function is the projection² of this quantum state onto a physical space(i.e., our 3D space and 1D time) basis of position eigenstates.

The Core Question: What Is the Quantum State?

At the heart of QM is the quantum state/wave function ($\Psi$), a complex-valued mathematical or physical object, depending on your view, that is used to compute probabilities of outcomes of observables, thats really all its utility! The fundamental nature of the quantum state is where things become difficult to wrap your head around (for a review see [2]). The nature of the quantum state, $\Psi$ has two "beliefs"¹, which are:

1. It is an ontological object, meaning it is something real, part of the physical world we observe and exist in.
2. Or it is an epistemological object meaning it is a representation of our knowledge or information about the world that we inhabit.

The view one takes fundamentally determines how one interprets the foundations of quantum behavior: entanglement and "non-local" (more on this next) correlations. But from a "shut-up and calculate" [1] perspective, it doesn't matter.

Non-Locality

In QM, the word "non-locality" is thrown around often, but it's crucial to disentangle (😆) its usage in physical reality versus mathematical contexts. Non-locality is an underpinning concept of the mathematical formalism of QM; it refers to a property of a mathematical space (not our physical space and time) that has a structure allowing for correlations (i.e., entanglement) which appear coordinated over spatial separations without a direct mediating causal signal limited by the speed of light. This 'acausal' nature of correlations in the mathematical formalism is distinct from, and does not enable violation of the principles of causality in physical spacetime as described by special relativity. How can this be? What such space has that feature? Turns out in information theory, the space of all possible distributions of probability over a finite set of outcomes has such a property.

Digression: Bell's Theorem

Bell's theorem shows that no theory of local hidden³ variables can reproduce all the predictions of QM [3]. John S. Bell formulated this as an mathematical inequality, which if violated, rules out the possibility of combining locality AND hidden variables.

So far all experiments have verified violation of Bell's inequality, and thus we can have a local theory with hidden variables or a non-local theory without hidden variables. The former (i.e., local hidden variables) is not consistent with any observations and thus is not considered a valid theory. This means we must give up either locality or hidden variables (or both). Various interpretations of QM make different choices: Copenhagen and QBism interpretations maintain locality by giving up hidden variables, while Bohmian mechanics maintains hidden variables by embracing non-locality. The theorem doesn't force us to conclude QM is inherently non-local, its more that it depends on your interpretational framework.

Physical Space (Spacetime)

In physical spacetime, which has a continuous geometric structure defined by coordinates, metrics, and causality, locality is built-in. Things happen through the continuity of the space and time. Events occur at points in space and time. Forces and interactions are local as they propagate through space over time and cannot influence distant points instantaneously without violating causality. Putting it more basic, point A cannot go to point B without going through the points in between.

This geometric structure ensures that:

• Causality is respected.
• Influence is constrained by light cones.
• Distances and continuity matter.

Hilbert Space (Quantum State Space)

In contrast, the quantum state lives in Hilbert space, which is a mathematical geometric space, again its mathematical not the physical space that we are familiar with. It has a structure:

• Inner product
• Norms
• Angles

This allows for some very important and convenient mathematical results. But again, it is not directly apart (embedded?) of spacetime, and therefore:

• Does not need to have spatial locality, i.e., the distance between two points can be disjointed in this space.
• Does not need to obey causal propagation in this geometric space.
• Can encode non-local correlations purely as part of its informational structure

I think this is a big reason people often get confused. More over we are usually taught from the position basis projection² perspective of the quantum state onto physical space so it makes this decoupling something we have to backtrack on to understand. Physics PhDs and mathmeticians probably have no issues here, but others I think might (I know I did!). The key point is Hilbert space is geometric, but not physically local in our familiar spacetime. The language used in our courses/textbooks tends to blend physical and mathematical notions carelessly.

Two Views of the Quantum State

Ontological Interpretation

If you treat the Quantum State as a real object in the physical world, then you're saying there exists an object -- the quantum state -- that is part of everything. This assumption then leads to:

• The Quantum State can be non-local in that it encodes information (i.e., entanglement), even if in a projected position-basis that information is spatially separated systems.
• It evolves unitarily even across space-like separations.
• Measurement collapse (i.e., observables/observational outcomes) is a physical process, albeit a non-unitary one.

This leads to ideas like Many-Worlds and Bohmian mechanics [4]. It demands that we expand our notion of physical reality beyond just local spacetime. Space and time are still very much local, but the quantum state is not.

Epistemological Interpretation

If one views the quantum state as just a tool that encodes information (as in Copenhagen or QBism [5]), then it's not a real object. It reflects an observer's state of belief about outcomes.

• Measurement collapse isn't physical, it's a Bayesian update (i.e., we got more info from observing).
• Entanglement reflects only non-local information, not non-local causes.
• No signal travels faster than light—only correlated expectations are updated.

This is why the quantum state can have non-local structure without violating causality. It's not describing the world directly as it is but describing what we know (or can infer) about it.

In this view, quantum mechanics becomes an information theory, with the quantum state as a formal device for encoding and updating expectations.

• This "information" doesn't have to live in physical space.
• It can exist in mathematical abstract spaces (e.g., Hilbert space), where correlations span across what would be distant points in spacetime.
• There's no requirement for continuity, geometry, or causality in this mathematical space.

This aligns with modern perspectives from quantum information theory, where entanglement is a resource, and non-locality is an informational, not physical, phenomenon.

Thoughts on how to communicate this

First, its okay to be verbose and expressive when explaining. We can say things like:

• Our reality of physical geometry means space and time is always local because it is continuous, if we say otherwise then causality is violated and we've got a problem because we don't observe this nor does general relativity tell us this!
• Mathematical geometries which refers to abstract concepts like Hilbert space have a structure that has similar properties of physical geometry (i.e., a metric⁴), but does not have to maintain locality. Things can be far apart in this geometric space and still be connected by the metric (i.e., entanglement).

Making these distinctions should help fade the confusion with these conceptual aspects. I could be wrong, but I think it helps.

The quantum state, depending on your interpretation, is either a very weird, non-local physical object or an informational object living in a non-local, non-physical space. Either way, the math is consistent and making predictions occurs without conflict. The confusion is in the language we use to describe such perspectives, well at least its confusing for me.

Footnotes

---

1. Yes, seems like a strange word to use, surely I can't mean ones evidence lacking perspective and feelings about something. But this is exactly what I mean. I think whether you view the quantum state as an ontological or epistemological object is a question of your prior. ↩

2. Hilbert space states can be projected onto physical space through a choice of basis—commonly the position basis $( |x\rangle )$. The Hamiltonian operator, which encodes dynamics and interactions, is expressed in this basis to produce differential equations in space and time (e.g., the Schrödinger equation). This projection allows abstract quantum states to manifest as real-space amplitudes and enables direct modeling of physical interactions in quantum field theory and many-body systems. ↩↩

3. Hidden variables are variables that are not directly observable, but are used to explain the results of experiments, they are not part of the quantum state. ↩

4. A metric is a function that defines the distance between any two points in a space. Its a "ruler" that can be adjusted to work correctly in the space of interest. ↩

References

[1] N.D. Mermin, Could Feynman Have Said This?, Physics Today 57 (2004) 10–11. https://doi.org/10.1063/1.1768652.

[2] Leifer, M. S. (2014). Is the quantum state real? An extended review of $\psi$-ontology theorems. Quanta, 3(1), 67-155. https://doi.org/10.12743/quanta.v3i1.22.

[3] Brunner, N., Cavalcanti, D., Pironio, S., Scarani, V., & Wehner, S. (2014). Bell nonlocality. Reviews of Modern Physics, 86(2), 419–478. https://doi.org/10.1103/RevModPhys.86.419.

[4] Maudlin, T. (2011). Quantum Non-Locality and Relativity: Metaphysical Intimations of Modern Physics (3rd ed.). Wiley-Blackwell. URL.

[5] Fuchs, C. A., Mermin, N. D., & Schack, R. (2014). An introduction to QBism with an application to the locality of quantum mechanics. American Journal of Physics, 82(8), 749-754. https://doi.org/10.1119/1.4874855.

---

Reuse and Attribution

uv python package manager

The python package manager ecosystem has become more refined and improved over the last 14 years since I started programming in python. When I first started with python pypi and conda were the de facto package managers, with conda being the more popular one because it did a better job with managing dependencies and system libraries. As time has gone by, pypi became better at managing dependencies and conda became ideal for very complex environments -- although containerization and virtual environments have made this less an issue.

One of the problems with just relying on pypi or conda is that a lot of the mainstream data science and ML/AI libraries are large and heavy so the setup time can be grueling in terms of time (and disk space!). And because the focus has shifted to virtual environments and containerization for python scripts, projects, and packages, the package managers really haven't kept up with the times.

A recent project called uv has focused on trying to make the python package manager experience more streamlined and faster. The biggest concern by the community is that uv is written in Rust and thus breaks the convention of python developers being able to read and maintain the package manager codebase. But since I'm not a core python developer, I'm not going to worry about that.

Poetry

For a while I used poetry as my package manager. I liked it a lot, but uv seems to be much faster from start to finish for setting up a new project. However, I wouldn't write poetry off yet and to be honest just vanilla python -m venv is still a good solution.

How to use uv

First things first is installing uv itself. I'm going to do this from a linux perspective, so bear that in mind. I typically like to install using the install script approach but you can also use pip if you prefer to:

curl -fsSL https://get.uv.dev | sh

and from pypi:

pip install uv

you can also use cargo or configure with a uv docker image, but I don't think most will do that.

Python versions

With uv you can easily install different versions of python by running uv python install <version> which will make the python version available to use with a script, project, or package. To list the python versions available to uv you can just do uv python list.

Running scripts

The overall structure of uv is to assume a pyproject.toml file is present in the current working directory and that this can be used to create a virtual environment and install the dependencies. The beauty is uv aims to manage all this under the hood so you don't have to worry about it. So you just need to have your pyproject.toml file and use:

uv run <script_name>.py

where the run command is doing all the coordinating work for you to run your script. However if you have a script that doesn't have any dependencies, i.e. using vanilla python, you can just run the script you would just do uv --run --no-project <script_name>.py. However this is rarely the case for most python scenarios, so it's not very useful. Additionally, in many cases you're just using numpy, scipy, matplotlib, etc. But it might not make sense to create a pyproject.toml file for just a single script. The uv project has a very elegant and clean solution for this. You just specify the dependencies in the script itself with specific markup. Here is what it looks like:

# /// script
# requires-python = ">=3.10"
# dependencies = [
#   "numpy",
#   "scipy",
#   "matplotlib",
# ]
# ///

import numpy as np
import scipy as sp
import matplotlib.pyplot as plt

Now when you run this script with uv run <script_name>.py it will install the dependencies and run the script.

Script Dependencies

I don't know exactly where or how uv configures the script dependencies environment, but essentially it's created some cached virtual environment in the .uv (or in .cache?) directory for your script that it can reference. It seems smart enough to know when the environment for the script already exists and doesn't need to be recreated.

In my opinion this is one of the best features of uv because you don't have to manage the venv directly in the folder or elsewhere.

Creating venv

If you're working on a project or have forked some repo, you can create a virtual environment using uv with the following command:

uv venv .venv

There are a bunch of options for setting things like python version etc., just type uv venv --help to see the options.

Then as with any python virtual environment you activate it in your shell using source .venv/bin/activate and treat it like a normal python virtual environment.

The one thing that is a bit strange is how you add python packages to your .venv, you can't just use pip install <package> because that will install the package globally, rather you have to use uv pip install <package>.

If you're contributing to an existing python project and need to install it in development mode you can do the normal pip but you have to use uv pip install -e .. Some different options are highlighted here.

Creating a project

The last kind of configuration setup you can use uv for is to create a project. What this does is create the minimal pyproject.toml file and a the virtual environment. You can do this with the following command:

uv init --name <project_name>

If you plan on making this a python package, app, or lib you can add the flags --package, --app, or --lib. I think the main difference is the folder structure so it's typically like this:

lib_project/ ├── utilities/ │ ├── __init__.py │ └── function.py ├── tests/ │ ├── __init__.py │ └── test_function.py

app_project/ ├── main.py ├── tests/ │ ├── __init__.py │ └── test_main.py

package_project/ ├── src/ │ ├── __init__.py │ └── main.py ├── tests/ ├── docs/ ├── pyproject.toml

uv folder Structure

The above is my guess but don't quote me on it. Could be very different from what uv actually creates.

requirements.txt

If you have a requirements.txt file, you can use uv pip install -r requirements.txt to install the dependencies. I believe if you do this though you'll need to manage dependencies exclusively with uv pip and can't do things like uv add <package> or uv remove <package>.

It would be nice if uv did what pyscaffold or cookiecutter do and create a more comprehensive project setup. I like the way those tools handle repo details, pre-commit hooks, docs, etc. I can never remember all the configuration options I prefer, so having a basic but complete setup would be great.

This is uv for you! I've been using it most of the time for my python related stuff. The only issue that I've run into is sometimes it fails to install a package because of some compatibility issue with my system, but it's hard to figure out what the issue is. I know it's a uv issue because if I just use my system python pip it works fine. I would say if you like poetry then you'll probably like uv as well and find value in the speed-up you gain in setting this up. It would be nice if VSCode had some kind of extension for uv to make it easier to setup things, but not exactly sure how much value that would actually add to be honest.

Reuse and Attribution