Сможет ли ИИ решить физику?
Физика написана плохо
Вы когда-нибудь смотрели на формулу и пытались понять, что там написано? Для меня, как для программиста, физическая формула - это полный набор антипаттернов.
Односимвольные имена - есть.
Юникод символы в названии переменных - есть.
Отсутствие тестов - есть.
Неявные типы (физические размерности) - есть.
Даже просто прочитать формулу про себя - непростая задача, так как я не всегда знаю, как произносится та или иная греческая закорючка.
Как это прочитать?
Физические законы как Python код
Так появилась идея проекта Symplyphysics - описание физических законов на Python. Python выбран неспроста - в нём присутствует библиотека символьных вычислений SymPy. SymPy позволил мне решить проблему комбинаторного взрыва - например простая формула потребовала бы трёх функций:
F(m, a)
m(F, a)
a(F, m)
Вместо этого SymPy позволяет записать отношение между физическими величинами одним равенством и автоматически получать "перевернутые" отношения:
acceleration = symbols.acceleration
force = symbols.force
mass = symbols.mass
law = Eq(acceleration, force / mass)sourcecraft.dev
(Пример закона из acceleration_is_force_over_mass.py)
Из этого равенства можно получить и функцию вычисления силы, причём с автоматической проверкой размерностей:
@validate_input(mass_=mass, acceleration_=acceleration)
@validate_output(force)
def calculate_force(mass_: Quantity, acceleration_: Quantity) -> Quantity:
result_force_expr = solve(law, force, dict=True)[0][force]
result_expr = result_force_expr.subs({mass: mass_, acceleration: acceleration_})
return Quantity(result_expr)sourcecraft.dev
(Создание конкретной функции для получения силы с автоматической валидацией размерности и автоматическим “переворачиванием” исходной формулы)
Теперь физик, студент или любой другой любитель физики может увидеть закон в понятном виде. Вместо таинственного F - объект "force", с явно заданной физической размерностью и коротким описанием. Вместо - валидируемое, тестируемое и исполняемое выражение.
Под валидацией я имею в виду автоматическую проверку входных и выходных размерностей. Под тестируемостью - покрытие тестами на основе реальных данных. Исполняемость означает, что в выражение можно подставить нужные параметры в любых удобных единицах измерения и получить ответ или построить график.
Так выглядит простой тест закона:
@fixture(name="test_args")
def test_args_fixture() -> Args:
m = Quantity(1 units.kilogram)
a = Quantity(3 units.meter / units.second**2)
return Args(m=m, a=a)
def test_basic_force(test_args: Args) -> None:
result = newton_second_law.calculate_force(test_args.m, test_args.a)
assert_equal(result, 3 * units.newton)sourcecraft.dev
(Тестируем закон на референсных значениях)
В проекте есть и графики. Например, цикл Карно. Да, он выглядит не так красиво, как нам показывали на лекциях.
Рисуем цикл Карно
От формул к доказательствам
Следующим логическим шагом стало добавление доказательств.
Вспомните, как в школе или институте мы писали доказательства: берём несколько более базовых законов, добавляем граничные условия, проводим некоторые обоснованные трансформации - и вуаля, получаем нужную формулу. В Symplyphysics мы делаем то же самое, плюс получаем несколько бонусов бесплатно:
Циклы проверяются системой импортов в Python. Если два закона ссылаются друг на друга, то проект не соберётся.
SymPy берёт на себя большую часть работы при преобразованиях и математических операциях. Это не полностью доказанная корректность вывода, как в Lean, но в целом, SymPy можно верить.
Все неявные допущения нужно прописывать явно. Оказывается, школьные доказательства были не совсем верными и работают только при определенных условиях.
Я - базовый закон. Нет, я.
Так мы добавляли всё больше законов и всё больше доказательств, пока не появился ИИ.
Первые опыты. Как ИИ пытается жульничать
Конечно, первым делом я попробовал дать задачу ChatGPT, чтобы он написал мне очередное доказательство. Казалось бы, задача очевидная: посмотреть как устроены уже готовые доказательства в проекте, найти известный вывод, переписать доказательство на имеющихся примитивах проекта.
Но ИИ в такой простой задаче облажался по полной:
Вместо существующих базовых законов вставлял новые соотношения прямо в вывод формулы.
Брал закон, который требовалось доказать, преобразовывал его туда и обратно (round-trip) и считал, что задача выполнена.
Добавлял неоправданные предположения - например смена минуса на плюс без обоснования.
ИИ пытается в физику
Поэтому я считал, что эта задача - камень преткновения для ИИ. Так было до тех пор, пока не появился Fable.
Fable. Первые удачные доказательства
Когда вышел Fable, то я закинул ему задачу на добавление доказательств просто на удачу. Написал что-то вроде: "Посмотри как сделаны доказательства в проекте. Найди 3 наилучших кандидата для добавления доказательства и напиши их".
И неожиданно ИИ великолепно справился. Он не просто написал доказательство, которое было верно, но и выдержал стиль проекта. Он использовал удачные базовые законы и логически объединил несколько связанных формул.
Чтобы не быть голословным - оцените качество решения: symplyphysics#1188
Агент добавил вывод сразу трёх критических параметров газа Ван-дер-Ваальса - давления, температуры и молярного объёма.
Например, для критического давления, он использует уже существующее уравнение состояния и два условия критической точки (стационарной точки перегиба изотермы):
Затем решает систему уравнений для критического молярного объёма и температуры и подставляет результат обратно, чтобы получить критическое давление.
_critical_point_solved = solve(
(_inflection_point_eqn, flattangent_eqn),
(critical_point.volume, waals_law.temperature),
dict=True,
)[0]
criticalpressure_derived = isothermpressure.subs(_critical_point_solved)
assert expr_equals(_critical_pressure_derived, law.rhs)sourcecraft.dev
(Фрагмент доказательства из critical_van_der_waals_pressure.py)
Причём речь не об одном случайно удачном доказательстве. Например, в последующих запусках агент добавил доказательства для пяти разных законов: от релятивистского замедления времени до радиуса геостационарной орбиты. Он сам выбрал подходящих кандидатов и нашёл зависимости между существующими формулами.
На момент этого эксперимента GPT-6 Astra ещё не вышла, но подозреваю, что Astra тоже достаточно "интеллектуальна", чтобы повторить это достижение.
Получилось ли у AI доказывать физику?
Не совсем.
Обоснованность отдельных преобразований всё ещё выполняет человек. SymPy действительно умеет решать системы уравнений, что, в теории, устранило бы человеческий фактор в ряде доказательств. Но выбор нужных уравнений, условий применимости и допустимых ветвей решения - отдельная задача. Полностью автоматический вывод к тому же не всегда удобно читать.
Вот пример, когда мы явно избавились от знака при доказательстве закона. При выводе напряжения через интеграл электрического поля знак зависит от направления пути. Для постоянного поля сравниваются абсолютные величины:
В коде это специально поясняется комментарием, а заключительная проверка выглядит так:
assert expr_equals_abs(_voltage_derived, law.rhs)sourcecraft.dev
(Пример из voltage_is_electric_field_times_distance.py)
И главное: мы пока не знаем, что будет делать агент, когда нужной формулы или вывода просто-напросто не окажется в доступных источниках.
Что дальше?
Основная цель проекта - получить согласованный граф законов. Интересно, какие же базовые принципы лежат в основе всего и можно ли их описать в виде кода.
Там слоны до самого низа.
Сможет ли ИИ написать новое доказательство известного закона, которого нет в доступных источниках? Сможет ли ИИ написать новый закон, который потом можно будет проверить экспериментально?
Чтобы ответить на эти вопросы я планирую добавлять новые доказательства, сделать визуализацию графа законов и MCP сервер.
Если вам интересна формализация физики или опыт использования агентов для научных задач, буду рад обсудить это в комментариях.
Похожие проекты:
Physics Derivation Graph с графом физических выводов
Physlibс гораздо более строгой формализацией физики на Lean.
Проект: blackyblack/symplyphysics
Документация: symplyphysics.github.io
AI Agents Need More Than Better Prompts: They Need a Physics Framework
_What if an AI solving a physics problem had to leave behind more than a convincing explanation? What if it had to leave code, assumptions, source references, tests, and an honest record of what remains unknown?_
AI can explain physics beautifully. It can also confidently skip a condition, invent a mathematical operation, solve a subtly different problem, or mistake a plausible hypothesis for a scientific result. Better prompts help, but prompts alone are not a research infrastructure.
That is the problem the Phys infrastructure project is trying to address: give humans, physicists, and AI agents a shared, inspectable framework for representing physics, expressing assumptions, checking supported mathematical steps, and testing the code that carries those steps out.
The goal is not to claim that AI can automatically discover the laws of Nature. It is to make AI-assisted exploration more rigorous—and to make it easier to tell the difference between a good idea, a valid derivation, and a claim supported by physical evidence.
The real problem is bigger than hallucination
“Garbage in, garbage out” is often treated as a data-quality problem. In research, the garbage can enter much earlier than the calculation.
An agent may misunderstand the paper, use the wrong convention, omit a boundary condition, confuse an assumption with a conclusion, or formalize a claim that is easier to prove but no longer means what the researcher intended. A theorem prover can then verify a proof of the wrong proposition. Conversely, even a perfectly specified problem can be ruined by an invalid derivation or faulty implementation.
A trustworthy workflow must therefore distinguish at least five questions:
1. Is this the right question? Is the problem meaningful and scoped to a clear regime?
2. Did we capture the source correctly? Are the definitions, assumptions, equations, and limitations faithful to the paper or textbook?
3. Is the mathematical model appropriate? Does it express the physical idea we intend to study?
4. Does the result follow? Were the operations actually performed and checked?
5. Does the model describe Nature? Is there relevant empirical evidence—or is that still unknown?
No single test can answer all five. A source citation does not prove an equation. A passing unit test does not validate a physical theory. A replayed derivation does not establish empirical truth. And a formal proof only concerns the proposition and foundations that were actually supplied.
Phys aims to make these distinctions visible, structured, and testable instead of burying them in an AI-generated paragraph.
Why Go—and why code the solution?
Phys is being developed in Go. That is not because physics can be reduced to software, or because every equation can already be executed by the current libraries. It is because a Go project can make supported parts of a solution concrete: typed representations, explicit operations, reproducible test commands, dependency versions, and automated checks in one workflow.
Instead of accepting only a natural-language answer, a physics task can produce an inspectable research package: a problem statement, a source reference, declared assumptions, equations or derivation artifacts, tests for the supported steps, and a report that names unsupported work. The specification should be executable where it can be given precise machine-checkable meaning; interpretive or unresolved claims must remain explicit rather than being disguised as passing tests.
This changes the evaluation question from “Does the AI sound right?” to “What did it represent, what code ran, what did the tests establish, and what did it leave unverified?”
The layers of Phys
The project separates responsibilities that are easy to conflate:
- PhysArtifact provides canonical artifact identity and encoding. It helps identify which exact object is referenced; identity is not proof of correctness.
- PhysMath provides theory-neutral mathematical representations and a bounded set of implemented symbolic operations. It is not a universal computer algebra system or a numerical solver.
- PhysLib holds physical-framework-specific assumptions, equations, and semantics in phys-* packages. GR concepts should not be forced onto quantum mechanics or another framework just because an API is convenient.
- PhysTrace provides the derivation-specification guidance and workflow discipline: source mapping, capability audits, independent expected results, tests, provenance, and honest evidence levels.
The architecture intentionally separates the mathematical object from its physical interpretation, and both from evidence about the real world. Current capabilities must be checked against the code and executable rule registry—not inferred from a README or an attractive API name.
Math Reality Check: mathematics is the bridge, not the verdict
Link: MRC in markdown, MRC in pdf
The role of mathematics in physics is more subtle than “write an equation, then solve it.” Mathematics lets us make assumptions precise, derive consequences, expose internal contradictions, compare candidate models, and generate predictions that may be confronted with observation. It can reveal that a hypothesis has an impossible consequence under its own assumptions—or that several ideas which sound different share the same mathematical structure.
But mathematical consistency does not automatically make a hypothesis physically true. A model can be internally coherent and still fail to describe Nature. Conversely, an unfamiliar model should not be rejected merely because its notation looks strange; the relevant question is what its assumptions imply and whether those implications are coherent and empirically adequate.
This is the purpose of a Math Reality Check (MRC) in the Phys research vision: turn a hypothesis into concrete, checkable theoretical scenarios. State the assumptions and equations, derive the result, compare it with a clearly defined null model, and record the outcome. Where the problem admits a formal calculation, compute the result from the declared mathematics rather than relying on verbal plausibility. Where there is no empirical evidence, the Nature/Reality outcome remains UNOBSERVED or NOT AVAILABLE—not silently marked as confirmed.
MRC is not a machine that declares a Theory of Everything true. It is a discipline for asking what a hypothesis actually commits us to, what it predicts, which competing or null model it beats or fails to beat, and what evidence would change our minds.
That discipline should shape hypothesis formulation from the beginning. An AI agent should not merely invent an elegant equation and then defend it. It should list the assumptions, identify the regime, search for counterexamples, derive distinguishing predictions where possible, compare alternatives, and say what would falsify or constrain the idea.
Phys and Lean: complementary, not competing
Lean is an interactive theorem prover and programming language. Its kernel checks proof terms against formal propositions and their definitions and assumptions. Mathlib supplies a large reusable library of formal mathematics. These are powerful tools for asking whether a precise mathematical statement follows from declared foundations.
Phys is concerned with a different—but connected—part of the pipeline: did we formulate the right claim in the first place, preserve its physical assumptions and source meaning, and record what the derivation actually establishes?
A useful shorthand is:
- Phys helps make the research inputs explicit and auditable. What is the source claim? Which assumptions and conventions apply? Which operations are supported? What evidence exists for each step?
- Lean can check formal consequences rigorously. Given a suitable formal statement and foundations, does the proof type-check?
- Experiments and observations constrain physical truth. Neither a Phys replay nor a Lean proof alone establishes that a model describes Nature.
This is not a perfect wall between “input” and “output.” Lean can expose a bad formal statement, and Phys can test transformations and challenge incorrect outputs. But their strengths differ. A Lean proof may be completely valid while the theorem formalizes the wrong interpretation of a paper. A faithful Phys source map may document a claim accurately while an algebraic step remains unproved. We need both kinds of discipline.
A future integration could let Phys attach the source, assumptions, interpretation, regime, and provenance to a claim, then export a precisely scoped mathematical subproblem to Lean. The checked theorem and its dependency/axiom information could be linked back to the corresponding derivation step in Phys. That bridge is a proposal, not an existing integrated product. The useful principle is to preserve the context around a proof rather than treating a green checkmark as the end of scientific review.
Human judgment and autonomous agents both matter
Requiring a human to approve every algebraic transformation would waste the value of automation. Let agents do useful work on their own within explicit boundaries: enumerate candidate assumptions, search libraries, propose subgoals, try derivations, generate counterexamples, run unit tests, compare a hypothesis with a null model, and report which steps failed. They can iterate quickly and explore branches that a person might not have time to pursue.
But autonomy needs structure. Agent tasks should be bounded, reproducible, and reversible. The workflow should record the source and dependency versions, run tests in a controlled environment, distinguish generated candidates from accepted claims, and stop rather than inventing an unsupported rule or silently changing the specification.
Humans remain essential for choosing worthwhile questions, judging the intended meaning of a physical concept, reviewing source fidelity, deciding whether assumptions are reasonable, weighing empirical evidence, and taking responsibility for scientific conclusions. These judgments cannot be replaced by adding more retries to an agent loop.
The goal is not “human in every step” or “human out of every step.” It is human authority over meaning and acceptance, with machine autonomy for transparent exploration and checking wherever the task is well-defined.
What exists today—and what does not
Phys has moved beyond a slogan. The work includes a documented cross-project architecture, a theory-neutral mathematical library, physical-framework packages, source and derivation guidelines, and a workflow contract for two kinds of work: formalizing a derivation from a paper and solving a specified textbook or benchmark problem. The current paper-scale example includes a bounded Bohmian minisuperspace fixture based on a portion of the Dürr–Struyve Quantum Einstein Equations paper; it is not a formalization of the entire paper or proof of the theory's empirical truth.
Adversarial testing has also exposed an important failure mode: an AI solution can import a library without meaningfully using it, include dead or stubbed tests, invent a symbolic rule, or pass a test suite that never checks the intended physics. The workflow therefore requires actual API use to be exercised by tests, independent expected results where appropriate, and explicit reporting of gaps and limitations. “The tests pass” is evidence only for what the tests really test.
The boundaries matter too. Phys is currently focused on theoretical representation and supported symbolic operations—the work physicists often perform with pen and paper. Numerical solvers, Monte Carlo methods, a complete dimensional-semantics system, and autonomous scientific discovery are not delivered by the current infrastructure. The planned MCP setup and polished end-user demo are further work, not something this article claims is already deployed.
A practical first step: make every answer leave evidence
The public demonstration is designed around two reusable workflows:
Paper derivation: choose a bounded result from a physics paper, pin the source version, map the quantities and assumptions, audit the available capabilities, and create a conforming formalization package. Tests should distinguish what is represented from what is actually executed or replayed. Any unexpressible requirement stays a visible gap rather than a new, improvised schema field.
Textbook problem: identify the problem and its conventions, perform the capability audit, use Phys where it genuinely fits, and record exactly which APIs and tests exercise the claimed reuse. Any unsupported numerical computation stays local and is not attributed to Phys. The package reports the answer, reasoning, test outcomes, and limitations.
This gives people a way to see AI-assisted research as something other than a chat transcript. A student, researcher, or reviewer can ask: What is the source? What was assumed? What ran? What failed? What did the test establish? What remains a human judgment?
The project needs help from Go developers, physicists, mathematicians, formal-methods researchers, educators, and people who care about responsible open-source AI. Contributions can start small: reproduce an example, add an independent expected result, build a test that catches a plausible mistake, improve documentation, or review whether a formalized statement preserves the source's meaning. Academic groups can bring real paper fragments and expert review; industry partners can support testing, reproducible infrastructure, and integrations; sponsors can fund sustained maintenance and independent validation.
The bigger idea: a common ground for research
Today, a physicist may describe a model in a paper, a mathematician may formalize one of its theorems, a software engineer may implement a calculation, and an AI agent may propose a new hypothesis. Too often, these artifacts live in different languages and tools, with unclear links between the assumptions, the code, the proof, and the scientific claim.
Phys is an attempt to create common ground: a research artifact that people can read, agents can work with, and software can test. Go is the executable engineering layer for the current libraries and protocols. Lean and similar proof systems can provide stronger formal checking for suitable claims. Human reviewers preserve scientific meaning and judgment. Empirical work supplies the reality checks that mathematics alone cannot provide.
The promise is not that hallucinations disappear, or that a test suite will tell us the final truth about the universe. The promise is that unsupported claims become harder to hide, useful exploration becomes easier to reproduce, and AI can help more people participate in science without asking them to trust a confident answer blindly.
Phys is open source, and it needs collaborators. Explore the repositories, try the workflows, challenge the assumptions, and help us make research with AI more transparent, testable, and useful.
Explore the project
- PhysArtifact
- PhysMath
- PhysLib
- PhysTrace
Project status note: Phys–Lean integration, automated hypothesis discovery, and the public MCP demo are directions for future work, not claims of currently completed functionality. The current scope and capabilities should always be checked against the live repositories, implementation, and tests.
Mentions
I'm a little saddened that to casual observers, leanprover-community/mathlib4 and AI doing math are probably encountered as a singular highly disruptive event, when the former exists without the latter and is a marvel of modern librarianship.
@scottnarmstrong mathlib4#43703 They dont like AI Period even if its right.
Сможет ли ИИ решить физику? Физика написана плохо Вы когда-нибудь смотрели на формулу и пытались понять, что там написано? Для меня, как для программиста, физическая формула - это полный набор антипаттернов. Односимвольные имена - есть. Юникод символы в названии переменных - есть. Отсутствие тестов - есть. Неявные типы (физические размерности) - есть. Даже просто прочитать формулу про себя - непростая задача, так как я не всегда знаю, как произносится та или иная греческая закорючка. Как это прочитать? Физические законы как Python код Так появилась идея проекта Symplyphysics - описание физических законов на Python. Python выбран неспроста - в нём присутствует библиотека символьных вычислений SymPy. SymPy позволил мне решить проблему комбинаторного взрыва - например простая формула потребовала бы трёх функций: F(m, a) m(F, a) a(F, m) Вместо этого SymPy позволяет записать отношение между физическими величинами одним равенством и автоматически получать "перевернутые" отношения: acceleration = symbols.acceleration force = symbols.force mass = symbols.mass law = Eq(acceleration, force / mass)sourcecraft.dev (Пример закона из acceleration_is_force_over_mass.py) Из этого равенства можно получить и функцию вычисления силы, причём с автоматической проверкой размерностей: @validate_input(mass_=mass, acceleration_=acceleration) @validate_output(force) def calculate_force(mass_: Quantity, acceleration_: Quantity) -> Quantity: result_force_expr = solve(law, force, dict=True)[0][force] result_expr = result_force_expr.subs({mass: mass_, acceleration: acceleration_}) return Quantity(result_expr)sourcecraft.dev (Создание конкретной функции для получения силы с автоматической валидацией размерности и автоматическим “переворачиванием” исходной формулы) Теперь физик, студент или любой другой любитель физики может увидеть закон в понятном виде. Вместо таинственного F - объект "force", с явно заданной физической размерностью и коротким описанием. Вместо - валидируемое, тестируемое и исполняемое выражение. Под валидацией я имею в виду автоматическую проверку входных и выходных размерностей. Под тестируемостью - покрытие тестами на основе реальных данных. Исполняемость означает, что в выражение можно подставить нужные параметры в любых удобных единицах измерения и получить ответ или построить график. Так выглядит простой тест закона: @fixture(name="test_args") def test_args_fixture() -> Args: m = Quantity(1 units.kilogram) a = Quantity(3 units.meter / units.second**2) return Args(m=m, a=a) def test_basic_force(test_args: Args) -> None: result = newton_second_law.calculate_force(test_args.m, test_args.a) assert_equal(result, 3 * units.newton)sourcecraft.dev (Тестируем закон на референсных значениях) В проекте есть и графики. Например, цикл Карно. Да, он выглядит не так красиво, как нам показывали на лекциях. Рисуем цикл Карно От формул к доказательствам Следующим логическим шагом стало добавление доказательств. Вспомните, как в школе или институте мы писали доказательства: берём несколько более базовых законов, добавляем граничные условия, проводим некоторые обоснованные трансформации - и вуаля, получаем нужную формулу. В Symplyphysics мы делаем то же самое, плюс получаем несколько бонусов бесплатно: Циклы проверяются системой импортов в Python. Если два закона ссылаются друг на друга, то проект не соберётся. SymPy берёт на себя большую часть работы при преобразованиях и математических операциях. Это не полностью доказанная корректность вывода, как в Lean, но в целом, SymPy можно верить. Все неявные допущения нужно прописывать явно. Оказывается, школьные доказательства были не совсем верными и работают только при определенных условиях. Я - базовый закон. Нет, я. Так мы добавляли всё больше законов и всё больше доказательств, пока не появился ИИ. Первые опыты. Как ИИ пытается жульничать Конечно, первым делом я попробовал дать задачу ChatGPT, чтобы он написал мне очередное доказательство. Казалось бы, задача очевидная: посмотреть как устроены уже готовые доказательства в проекте, найти известный вывод, переписать доказательство на имеющихся примитивах проекта. Но ИИ в такой простой задаче облажался по полной: Вместо существующих базовых законов вставлял новые соотношения прямо в вывод формулы. Брал закон, который требовалось доказать, преобразовывал его туда и обратно (round-trip) и считал, что задача выполнена. Добавлял неоправданные предположения - например смена минуса на плюс без обоснования. ИИ пытается в физику Поэтому я считал, что эта задача - камень преткновения для ИИ. Так было до тех пор, пока не появился Fable. Fable. Первые удачные доказательства Когда вышел Fable, то я закинул ему задачу на добавление доказательств просто на удачу. Написал что-то вроде: "Посмотри как сделаны доказательства в проекте. Найди 3 наилучших кандидата для добавления доказательства и напиши их". И неожиданно ИИ великолепно справился. Он не просто написал доказательство, которое было верно, но и выдержал стиль проекта. Он использовал удачные базовые законы и логически объединил несколько связанных формул. Чтобы не быть голословным - оцените качество решения: symplyphysics#1188 Агент добавил вывод сразу трёх критических параметров газа Ван-дер-Ваальса - давления, температуры и молярного объёма. Например, для критического давления, он использует уже существующее уравнение состояния и два условия критической точки (стационарной точки перегиба изотермы): Затем решает систему уравнений для критического молярного объёма и температуры и подставляет результат обратно, чтобы получить критическое давление. _critical_point_solved = solve( (_inflection_point_eqn, flattangent_eqn), (critical_point.volume, waals_law.temperature), dict=True, )[0] criticalpressure_derived = isothermpressure.subs(_critical_point_solved) assert expr_equals(_critical_pressure_derived, law.rhs)sourcecraft.dev (Фрагмент доказательства из critical_van_der_waals_pressure.py) Причём речь не об одном случайно удачном доказательстве. Например, в последующих запусках агент добавил доказательства для пяти разных законов: от релятивистского замедления времени до радиуса геостационарной орбиты. Он сам выбрал подходящих кандидатов и нашёл зависимости между существующими формулами. На момент этого эксперимента GPT-6 Astra ещё не вышла, но подозреваю, что Astra тоже достаточно "интеллектуальна", чтобы повторить это достижение. Получилось ли у AI доказывать физику? Не совсем. Обоснованность отдельных преобразований всё ещё выполняет человек. SymPy действительно умеет решать системы уравнений, что, в теории, устранило бы человеческий фактор в ряде доказательств. Но выбор нужных уравнений, условий применимости и допустимых ветвей решения - отдельная задача. Полностью автоматический вывод к тому же не всегда удобно читать. Вот пример, когда мы явно избавились от знака при доказательстве закона. При выводе напряжения через интеграл электрического поля знак зависит от направления пути. Для постоянного поля сравниваются абсолютные величины: В коде это специально поясняется комментарием, а заключительная проверка выглядит так: assert expr_equals_abs(_voltage_derived, law.rhs)sourcecraft.dev (Пример из voltage_is_electric_field_times_distance.py) И главное: мы пока не знаем, что будет делать агент, когда нужной формулы или вывода просто-напросто не окажется в доступных источниках. Что дальше? Основная цель проекта - получить согласованный граф законов. Интересно, какие же базовые принципы лежат в основе всего и можно ли их описать в виде кода. Там слоны до самого низа. Сможет ли ИИ написать новое доказательство известного закона, которого нет в доступных источниках? Сможет ли ИИ написать новый закон, который потом можно будет проверить экспериментально? Чтобы ответить на эти вопросы я планирую добавлять новые доказательства, сделать визуализацию графа законов и MCP сервер. Если вам интересна формализация физики или опыт использования агентов для научных задач, буду рад обсудить это в комментариях. Похожие проекты: Physics Derivation Graph с графом физических выводов Physlibс гораздо более строгой формализацией физики на Lean. Проект: blackyblack/symplyphysics Документация: symplyphysics.github.io
Hmm. openai/math hat trotz Inklusion von kompilierten PDF files mehr als 3 mal so viele Sterne wie leanprover-community/mathlib4 Das kann doch so nicht bleiben Leute. Stern bedeutet “Fav” auch auf GitHub !!! Jetzt wollte ich das all modern infrastructure […]
just found that there's a game version of Lean 4 in development: leanprover-community/lean4game
AI Agents Need More Than Better Prompts: They Need a Physics Framework _What if an AI solving a physics problem had to leave behind more than a convincing explanation? What if it had to leave code, assumptions, source references, tests, and an honest record of what remains unknown?_ AI can explain physics beautifully. It can also confidently skip a condition, invent a mathematical operation, solve a subtly different problem, or mistake a plausible hypothesis for a scientific result. Better prompts help, but prompts alone are not a research infrastructure. That is the problem the Phys infrastructure project is trying to address: give humans, physicists, and AI agents a shared, inspectable framework for representing physics, expressing assumptions, checking supported mathematical steps, and testing the code that carries those steps out. The goal is not to claim that AI can automatically discover the laws of Nature. It is to make AI-assisted exploration more rigorous—and to make it easier to tell the difference between a good idea, a valid derivation, and a claim supported by physical evidence. The real problem is bigger than hallucination “Garbage in, garbage out” is often treated as a data-quality problem. In research, the garbage can enter much earlier than the calculation. An agent may misunderstand the paper, use the wrong convention, omit a boundary condition, confuse an assumption with a conclusion, or formalize a claim that is easier to prove but no longer means what the researcher intended. A theorem prover can then verify a proof of the wrong proposition. Conversely, even a perfectly specified problem can be ruined by an invalid derivation or faulty implementation. A trustworthy workflow must therefore distinguish at least five questions: 1. Is this the right question? Is the problem meaningful and scoped to a clear regime? 2. Did we capture the source correctly? Are the definitions, assumptions, equations, and limitations faithful to the paper or textbook? 3. Is the mathematical model appropriate? Does it express the physical idea we intend to study? 4. Does the result follow? Were the operations actually performed and checked? 5. Does the model describe Nature? Is there relevant empirical evidence—or is that still unknown? No single test can answer all five. A source citation does not prove an equation. A passing unit test does not validate a physical theory. A replayed derivation does not establish empirical truth. And a formal proof only concerns the proposition and foundations that were actually supplied. Phys aims to make these distinctions visible, structured, and testable instead of burying them in an AI-generated paragraph. Why Go—and why code the solution? Phys is being developed in Go. That is not because physics can be reduced to software, or because every equation can already be executed by the current libraries. It is because a Go project can make supported parts of a solution concrete: typed representations, explicit operations, reproducible test commands, dependency versions, and automated checks in one workflow. Instead of accepting only a natural-language answer, a physics task can produce an inspectable research package: a problem statement, a source reference, declared assumptions, equations or derivation artifacts, tests for the supported steps, and a report that names unsupported work. The specification should be executable where it can be given precise machine-checkable meaning; interpretive or unresolved claims must remain explicit rather than being disguised as passing tests. This changes the evaluation question from “Does the AI sound right?” to “What did it represent, what code ran, what did the tests establish, and what did it leave unverified?” The layers of Phys The project separates responsibilities that are easy to conflate: - PhysArtifact provides canonical artifact identity and encoding. It helps identify which exact object is referenced; identity is not proof of correctness. - PhysMath provides theory-neutral mathematical representations and a bounded set of implemented symbolic operations. It is not a universal computer algebra system or a numerical solver. - PhysLib holds physical-framework-specific assumptions, equations, and semantics in phys-* packages. GR concepts should not be forced onto quantum mechanics or another framework just because an API is convenient. - PhysTrace provides the derivation-specification guidance and workflow discipline: source mapping, capability audits, independent expected results, tests, provenance, and honest evidence levels. The architecture intentionally separates the mathematical object from its physical interpretation, and both from evidence about the real world. Current capabilities must be checked against the code and executable rule registry—not inferred from a README or an attractive API name. Math Reality Check: mathematics is the bridge, not the verdict Link: MRC in markdown, MRC in pdf The role of mathematics in physics is more subtle than “write an equation, then solve it.” Mathematics lets us make assumptions precise, derive consequences, expose internal contradictions, compare candidate models, and generate predictions that may be confronted with observation. It can reveal that a hypothesis has an impossible consequence under its own assumptions—or that several ideas which sound different share the same mathematical structure. But mathematical consistency does not automatically make a hypothesis physically true. A model can be internally coherent and still fail to describe Nature. Conversely, an unfamiliar model should not be rejected merely because its notation looks strange; the relevant question is what its assumptions imply and whether those implications are coherent and empirically adequate. This is the purpose of a Math Reality Check (MRC) in the Phys research vision: turn a hypothesis into concrete, checkable theoretical scenarios. State the assumptions and equations, derive the result, compare it with a clearly defined null model, and record the outcome. Where the problem admits a formal calculation, compute the result from the declared mathematics rather than relying on verbal plausibility. Where there is no empirical evidence, the Nature/Reality outcome remains UNOBSERVED or NOT AVAILABLE—not silently marked as confirmed. MRC is not a machine that declares a Theory of Everything true. It is a discipline for asking what a hypothesis actually commits us to, what it predicts, which competing or null model it beats or fails to beat, and what evidence would change our minds. That discipline should shape hypothesis formulation from the beginning. An AI agent should not merely invent an elegant equation and then defend it. It should list the assumptions, identify the regime, search for counterexamples, derive distinguishing predictions where possible, compare alternatives, and say what would falsify or constrain the idea. Phys and Lean: complementary, not competing Lean is an interactive theorem prover and programming language. Its kernel checks proof terms against formal propositions and their definitions and assumptions. Mathlib supplies a large reusable library of formal mathematics. These are powerful tools for asking whether a precise mathematical statement follows from declared foundations. Phys is concerned with a different—but connected—part of the pipeline: did we formulate the right claim in the first place, preserve its physical assumptions and source meaning, and record what the derivation actually establishes? A useful shorthand is: - Phys helps make the research inputs explicit and auditable. What is the source claim? Which assumptions and conventions apply? Which operations are supported? What evidence exists for each step? - Lean can check formal consequences rigorously. Given a suitable formal statement and foundations, does the proof type-check? - Experiments and observations constrain physical truth. Neither a Phys replay nor a Lean proof alone establishes that a model describes Nature. This is not a perfect wall between “input” and “output.” Lean can expose a bad formal statement, and Phys can test transformations and challenge incorrect outputs. But their strengths differ. A Lean proof may be completely valid while the theorem formalizes the wrong interpretation of a paper. A faithful Phys source map may document a claim accurately while an algebraic step remains unproved. We need both kinds of discipline. A future integration could let Phys attach the source, assumptions, interpretation, regime, and provenance to a claim, then export a precisely scoped mathematical subproblem to Lean. The checked theorem and its dependency/axiom information could be linked back to the corresponding derivation step in Phys. That bridge is a proposal, not an existing integrated product. The useful principle is to preserve the context around a proof rather than treating a green checkmark as the end of scientific review. Human judgment and autonomous agents both matter Requiring a human to approve every algebraic transformation would waste the value of automation. Let agents do useful work on their own within explicit boundaries: enumerate candidate assumptions, search libraries, propose subgoals, try derivations, generate counterexamples, run unit tests, compare a hypothesis with a null model, and report which steps failed. They can iterate quickly and explore branches that a person might not have time to pursue. But autonomy needs structure. Agent tasks should be bounded, reproducible, and reversible. The workflow should record the source and dependency versions, run tests in a controlled environment, distinguish generated candidates from accepted claims, and stop rather than inventing an unsupported rule or silently changing the specification. Humans remain essential for choosing worthwhile questions, judging the intended meaning of a physical concept, reviewing source fidelity, deciding whether assumptions are reasonable, weighing empirical evidence, and taking responsibility for scientific conclusions. These judgments cannot be replaced by adding more retries to an agent loop. The goal is not “human in every step” or “human out of every step.” It is human authority over meaning and acceptance, with machine autonomy for transparent exploration and checking wherever the task is well-defined. What exists today—and what does not Phys has moved beyond a slogan. The work includes a documented cross-project architecture, a theory-neutral mathematical library, physical-framework packages, source and derivation guidelines, and a workflow contract for two kinds of work: formalizing a derivation from a paper and solving a specified textbook or benchmark problem. The current paper-scale example includes a bounded Bohmian minisuperspace fixture based on a portion of the Dürr–Struyve Quantum Einstein Equations paper; it is not a formalization of the entire paper or proof of the theory's empirical truth. Adversarial testing has also exposed an important failure mode: an AI solution can import a library without meaningfully using it, include dead or stubbed tests, invent a symbolic rule, or pass a test suite that never checks the intended physics. The workflow therefore requires actual API use to be exercised by tests, independent expected results where appropriate, and explicit reporting of gaps and limitations. “The tests pass” is evidence only for what the tests really test. The boundaries matter too. Phys is currently focused on theoretical representation and supported symbolic operations—the work physicists often perform with pen and paper. Numerical solvers, Monte Carlo methods, a complete dimensional-semantics system, and autonomous scientific discovery are not delivered by the current infrastructure. The planned MCP setup and polished end-user demo are further work, not something this article claims is already deployed. A practical first step: make every answer leave evidence The public demonstration is designed around two reusable workflows: Paper derivation: choose a bounded result from a physics paper, pin the source version, map the quantities and assumptions, audit the available capabilities, and create a conforming formalization package. Tests should distinguish what is represented from what is actually executed or replayed. Any unexpressible requirement stays a visible gap rather than a new, improvised schema field. Textbook problem: identify the problem and its conventions, perform the capability audit, use Phys where it genuinely fits, and record exactly which APIs and tests exercise the claimed reuse. Any unsupported numerical computation stays local and is not attributed to Phys. The package reports the answer, reasoning, test outcomes, and limitations. This gives people a way to see AI-assisted research as something other than a chat transcript. A student, researcher, or reviewer can ask: What is the source? What was assumed? What ran? What failed? What did the test establish? What remains a human judgment? The project needs help from Go developers, physicists, mathematicians, formal-methods researchers, educators, and people who care about responsible open-source AI. Contributions can start small: reproduce an example, add an independent expected result, build a test that catches a plausible mistake, improve documentation, or review whether a formalized statement preserves the source's meaning. Academic groups can bring real paper fragments and expert review; industry partners can support testing, reproducible infrastructure, and integrations; sponsors can fund sustained maintenance and independent validation. The bigger idea: a common ground for research Today, a physicist may describe a model in a paper, a mathematician may formalize one of its theorems, a software engineer may implement a calculation, and an AI agent may propose a new hypothesis. Too often, these artifacts live in different languages and tools, with unclear links between the assumptions, the code, the proof, and the scientific claim. Phys is an attempt to create common ground: a research artifact that people can read, agents can work with, and software can test. Go is the executable engineering layer for the current libraries and protocols. Lean and similar proof systems can provide stronger formal checking for suitable claims. Human reviewers preserve scientific meaning and judgment. Empirical work supplies the reality checks that mathematics alone cannot provide. The promise is not that hallucinations disappear, or that a test suite will tell us the final truth about the universe. The promise is that unsupported claims become harder to hide, useful exploration becomes easier to reproduce, and AI can help more people participate in science without asking them to trust a confident answer blindly. Phys is open source, and it needs collaborators. Explore the repositories, try the workflows, challenge the assumptions, and help us make research with AI more transparent, testable, and useful. Explore the project - PhysArtifact - PhysMath - PhysLib - PhysTrace Project status note: Phys–Lean integration, automated hypothesis discovery, and the public MCP demo are directions for future work, not claims of currently completed functionality. The current scope and capabilities should always be checked against the live repositories, implementation, and tests.
How can there simultaneously be a pull request to math lib from Kevin Buzzard on showing that the unit sphere is a Riemannian manifold [1] from Sept 26, and a formalization of Ricci flow [2] from Sept 28??? [1] mathlib4#43657 [2] qinz1yang/differential-geometry
@zyansheep @Jay59009444 @olydis @nascentwisp @aramh it runs in the lean infoview! have you seen proofwidgets before? it's using the same approach leanprover-community/ProofWidgets4
Thanks Meta FAIR for citing my Formal Conjectures PR fixing a Poincare Conjecture misformalization. Note: This wasn't a mistake by the FC authors, but in fact an issue with Mathlib upstream! I fixed the same misformalization in Mathlib last month mathlib4#43606 t.co
@tanakh あとは標準的な数学ライブラリにおいても、この greatestFib のように、数学的には正しくても計算量が悪すぎる実装がされている場合もあるので、実際の計算に使いたい時は上手く代替の実装を作って計算量を改善する必要があります。 github.com/leanprover-community/mathlib4/blob/6c2…