Я пытался объяснить кому-то, что C завершена по Тьюрингу, и понял, что на самом деле не знаю, действительно ли он технически завершен по Тьюрингу. (C как в абстрактной семантике, а не как в реальной реализации.)

«Очевидный» ответ (грубо говоря: он может адресовать произвольный объем памяти, поэтому он может эмулировать машину с ОЗУ, поэтому он завершается по Тьюрингу), на самом деле, насколько я могу судить, не совсем корректен, хотя стандарт C позволяет для того, чтобы size_t был сколь угодно большим, он должен быть фиксирован на некоторой длине, и независимо от того, на какой длине он фиксирован, он по-прежнему конечен. (Другими словами, хотя вы могли бы при произвольной остановке машины Тьюринга выбрать длину size_t так, чтобы она работала «правильно», нет способа выбрать длину size_t так, чтобы все останавливающие машины Тьюринга работали правильно).

Итак: завершен ли C99 по Тьюрингу?

Я не уверен, но я думаю, что ответ - нет, по довольно тонким причинам. Я спросил о теоретической информатике несколько лет назад и не получил ответа, который выходит за рамки того, что я здесь представлю.

В большинстве языков программирования вы можете моделировать машину Тьюринга:

• моделирование конечного автомата с помощью программы, использующей конечный объем памяти;
• моделирование ленты с помощью пары связанных списков целых чисел, представляющих содержимое ленты до и после текущей позиции. Перемещение указателя означает перенос заголовка одного из списков на другой список.

Конкретная реализация, работающая на компьютере, могла бы исчерпать память, если бы лента стала слишком длинной, но идеальная реализация могла бы точно выполнять машинную программу Тьюринга. Это можно сделать ручкой и бумагой или покупкой компьютера с большим объемом памяти и компилятором, ориентированным на архитектуру с большим количеством битов на слово и т. Д., Если программе когда-либо не хватает памяти.

Это не работает в C, потому что невозможно иметь связанный список, который может расти вечно: всегда есть какое-то ограничение на количество узлов.

Чтобы объяснить почему, мне сначала нужно объяснить, что такое реализация на Си. C на самом деле семейство языков программирования. Стандарт ISO C (точнее, конкретная версия этого стандарта) определяет (с уровнем формальности, который допускает английский язык) синтаксис и семантику семейства языков программирования. C имеет много неопределенного поведения и поведения, определенного для реализации, «Реализация» C кодифицирует все поведение, определяемое реализацией (список вещей для кодификации приведен в приложении J для C99). Каждая реализация C - это отдельный язык программирования. Обратите внимание, что значение слова «реализация» немного своеобразно: оно действительно означает языковой вариант, может быть несколько разных программ компилятора, которые реализуют один и тот же языковой вариант.

В данной реализации C байт имеет возможных значения CHAR_BIT . Все данные могут быть представлены в виде массива байтов: тип имеет максимум 2 CHAR_BIT × sizeof (t) возможных значений. Это число варьируется в разных реализациях C, но для данной реализации C оно является константой.$2^{\texttt{CHAR_BIT}}$t$2^{\texttt{CHAR_BIT} \times \texttt{sizeof(t)}}$

В частности, указатели могут принимать только . Это означает, что существует конечное максимальное количество адресуемых объектов.$2^{\texttt{CHAR_BIT} \times \texttt{sizeof(void*)}}$

Значения CHAR_BITи sizeof(void*)являются наблюдаемыми, поэтому, если у вас не хватает памяти, вы не можете просто возобновить работу своей программы с большими значениями для этих параметров. Вы будете запускать программу под другим языком программирования - другой реализацией Си.

Если программы на языке могут иметь только ограниченное число состояний, то язык программирования не более выразителен, чем конечные автоматы. Фрагмент C, который ограничен адресным хранилищем, допускает самое большее состояний программы, где n - размер абстрактного синтаксического дерева программы (представляющего состояние потока управления), поэтому это Программа может быть смоделирована конечным автоматом с таким количеством состояний. Если C более выразителен, это должно быть сделано с помощью других функций.$n \times 2^{\texttt{CHAR_BIT} \times \texttt{sizeof(void*)}}$$n$

C напрямую не навязывает максимальную глубину рекурсии. Реализация может иметь максимум, но также может не иметь. Но как мы общаемся между вызовом функции и ее родителем? Аргументы бесполезны, если они адресуемы, потому что это косвенно ограничило бы глубину рекурсии: если у вас есть функция, int f(int x) { … f(…) …}то все вхождения в xактивных кадрах fимеют свой собственный адрес, и поэтому число вложенных вызовов ограничено числом возможных адресов для x.

Программа AC может использовать неадресуемые хранилища в виде registerпеременных. «Нормальные» реализации могут иметь только небольшое конечное количество переменных, которые не имеют адреса, но теоретически реализация может позволить неограниченный объем registerпамяти. В такой реализации вы можете делать неограниченное количество рекурсивных вызовов функции, пока ее аргумент есть register. Но поскольку аргументы таковы register, вы не можете сделать на них указатель, и поэтому вам необходимо явно копировать их данные: вы можете передавать только конечный объем данных, а не структуру данных произвольного размера, состоящую из указателей.

С неограниченной глубиной рекурсии и ограничением, что функция может получать данные только от своего прямого вызывающего ( registerаргументы) и возвращать данные своему прямому вызывающему (возвращаемое значение функции), вы получаете мощность детерминированных автоматов выталкивания .

Я не могу найти способ пойти дальше.

(Конечно, вы можете заставить программу хранить содержимое ленты внешне, через функции ввода / вывода файла. Но тогда вы не будете спрашивать, является ли C завершенным по Тьюрингу, но является ли C плюс бесконечная система хранения полным по Тьюрингу, чтобы ответ - скучное «да». Вы также можете определить хранилище как вызов оракула Тьюринга  fopen("oracle", "r+"), fwriteначальное содержимое ленты и freadобратно конечное содержимое ленты.)

Добавление C99 va_copyк API с переменным аргументом может дать нам задний ход к полноте по Тьюрингу. Поскольку становится возможным повторять список переменных аргументов более одного раза в функции, отличной от той, которая первоначально получила аргументы, va_argsможно использовать для реализации указатель без указателя.

Конечно, реальная реализация API аргументов с переменным аргументом, вероятно, где-то будет иметь указатель, но в нашей абстрактной машине он может быть реализован с использованием магии.

Вот демонстрационная версия, реализующая 2-стопочный автомат с произвольными правилами перехода:

#include <stdarg.h>
typedef struct { va_list va; } wrapped_stack; // Struct wrapper needed if va_list is an array type.
#define NUM_SYMBOLS /* ... */
#define NUM_STATES /* ... */
typedef enum { NOP, POP1, POP2, PUSH1, PUSH2 } operation_type;
typedef struct { int next_state; operation_type optype; int opsymbol; } transition;
transition transition_table[NUM_STATES][NUM_SYMBOLS][NUM_SYMBOLS] = { /* ... */ };

void step(int state, va_list stack1, va_list stack2);
void push1(va_list stack2, int next_state, ...) {
    va_list stack1;
    va_start(stack1, next_state);
    step(next_state, stack1, stack2);
}
void push2(va_list stack1, int next_state, ...) {
    va_list stack2;
    va_start(stack2, next_state);
    step(next_state, stack1, stack2);
}
void step(int state, va_list stack1, va_list stack2) {
    va_list stack1_copy, stack2_copy;
    va_copy(stack1_copy, stack1); va_copy(stack2_copy, stack2);
    int symbol1 = va_arg(stack1_copy, int), symbol2 = va_arg(stack2_copy, int);
    transition tr = transition_table[state][symbol1][symbol2];
    wrapped_stack ws;
    switch(tr.optype) {
        case NOP: step(tr.next_state, stack1, stack2);
        // Note: attempting to pop the stack's bottom value results in undefined behavior.
        case POP1: ws = va_arg(stack1_copy, wrapped_stack); step(tr.next_state, ws.va, stack2);
        case POP2: ws = va_arg(stack2_copy, wrapped_stack); step(tr.next_state, stack1, ws.va);
        case PUSH1: va_copy(ws.va, stack1); push1(stack2, tr.next_state, tr.opsymbol, ws);
        case PUSH2: va_copy(ws.va, stack2); push2(stack1, tr.next_state, tr.opsymbol, ws);
    }
}
void start_helper1(va_list stack1, int dummy, ...) {
    va_list stack2;
    va_start(stack2, dummy);
    step(0, stack1, stack2);
}
void start_helper0(int dummy, ...) {
    va_list stack1;
    va_start(stack1, dummy);
    start_helper1(stack1, 0, 0);
}
// Begin execution in state 0 with each stack initialized to {0}
void start() {
    start_helper0(0, 0);
}

Примечание. Если va_listтип массива, то на самом деле существуют скрытые параметры указателя на функции. Так что, вероятно, было бы лучше изменить типы всех va_listаргументов на wrapped_stack.

Возможно, нестандартная арифметика?

Итак, похоже, что проблема заключается в конечном размере sizeof(t). Тем не менее, я думаю, что знаю обходной путь.

Насколько я знаю, C не требует реализации, чтобы использовать стандартные целые числа для своего целочисленного типа. Поэтому мы могли бы использовать нестандартную модель арифметики . Тогда мы установили sizeof(t)бы нестандартное число, и теперь мы никогда не достигнем его за конечное число шагов. Поэтому длина ленты машин Тьюринга всегда будет меньше «максимальной», так как максимум буквально невозможно достичь. sizeof(t)просто не число в обычном смысле этого слова.

Это одна из техничностей, конечно: теорема Тенненбаума . В нем говорится, что единственная модель арифметики Пеано является стандартной, что, очевидно, не подходит. Однако, насколько мне известно, C не требует реализаций для использования типов данных, которые удовлетворяют аксиомам Пеано, и не требует, чтобы реализация была вычислимой, так что это не должно быть проблемой.

Что должно произойти, если вы попытаетесь вывести нестандартное целое число? Ну, вы можете представить любое нестандартное целое число, используя нестандартную строку, поэтому просто передавайте цифры из передней части этой строки.

ИМО, сильным ограничением является то, что адресуемое пространство (через размер указателя) конечно, и это невозможно восстановить.

Можно утверждать, что память может быть «перенесена на диск», но в какой-то момент адресная информация сама превысит адресуемый размер.

На практике эти ограничения не имеют отношения к полноте по Тьюрингу. Реальное требование - позволить ленте быть произвольной длины, а не бесконечной. Это создало бы проблему остановки другого типа (как вселенная "вычисляет" ленту?)

Это так же фальшиво, как сказать: «Python не завершен по Тьюрингу, потому что вы не можете сделать список бесконечно большим».

[Редактировать: спасибо мистеру Уитледжу за разъяснение, как редактировать.]

Съемные носители позволяют нам обойти проблему неограниченной памяти. Возможно, люди подумают, что это злоупотребление, но я думаю, что все в порядке и, по сути, неизбежно в любом случае.

Исправить любую реализацию универсальной машины Тьюринга. Для ленты мы используем съемные носители. Когда головка стекает с конца или начала текущего диска, аппарат предлагает пользователю вставить следующий или предыдущий. Мы можем использовать специальный маркер для обозначения левого конца моделируемой ленты или иметь ленту, которая не ограничена в обоих направлениях.

Ключевым моментом здесь является то, что все, что должна делать программа на C, конечно. Компьютеру требуется только достаточно памяти для симуляции автомата, и он size_tдолжен быть достаточно большим, чтобы можно было адресовать тот (на самом деле, довольно маленький) объем памяти и дисков, которые могут иметь любой фиксированный конечный размер. Поскольку пользователю предлагается только вставить следующий или предыдущий диск, нам не нужно неограниченно большие целые числа, чтобы сказать: «Пожалуйста, вставьте диск с номером 123456 ...»

Я полагаю, что главным возражением, вероятно, будет участие пользователя, но это кажется неизбежным в любой реализации, потому что, кажется, нет другого способа реализации неограниченной памяти.

Выберите size_tбыть бесконечно большим

Вы можете выбрать size_tбыть бесконечно большим. Естественно, невозможно реализовать такую ​​реализацию. Но это не удивительно, учитывая конечную природу мира, в котором мы живем.

Практические последствия

Но даже если бы можно было реализовать такую ​​реализацию, возникли бы практические проблемы. Рассмотрим следующее утверждение C:

printf("%zu\n",SIZE_MAX);

SIZE_MAXSIZE_MAX$O(2^{size\_t})$size_tSIZE_MAXprintf

К счастью, для наших теоретических целей я не смог найти в спецификации никаких требований, которые гарантировали бы printfпрекращение для всех входных данных. Итак, насколько мне известно, мы не нарушаем здесь спецификацию C.

О вычислительной полноте

Осталось доказать, что наша теоретическая реализация является Тьюринг-Полной . Мы можем показать это, внедрив «любую машину Тьюринга с одной лентой».

Большинство из нас, вероятно, внедрили Машину Тьюринга как школьный проект. Я не буду вдаваться в подробности конкретной реализации, но вот часто используемая стратегия:

• Количество состояний, количество символов и таблица переходов состояний фиксированы для любой машины. Таким образом, мы можем представлять состояния и символы в виде чисел, а таблицу переходов состояний - в виде двумерного массива.
• Лента может быть представлена ​​в виде связанного списка. Мы можем использовать либо один двойной связанный список, либо два одинарных связанных списка (по одному для каждого направления от текущей позиции).

Теперь посмотрим, что требуется для реализации такой реализации:

• Способность представлять некоторый фиксированный, но произвольно большой набор чисел. Чтобы представить любое произвольное число, мы также выбираем MAX_INTбыть бесконечным. (В качестве альтернативы мы могли бы использовать другие объекты для представления состояний и символов.)
• Возможность создания сколь угодно большого связного списка для нашей ленты. Еще раз, нет никаких ограничений на размер. Это означает, что мы не можем создать этот список заранее, так как мы бы потратили навсегда только на создание нашей ленты. Но мы можем построить этот список постепенно, если мы используем динамическое выделение памяти. Мы можем использовать malloc, но есть еще кое-что, что мы должны рассмотреть:
  • Спецификация C позволяет mallocпотерпеть неудачу, если, например, доступная память была исчерпана. Таким образом, наша реализация по-настоящему универсальна только в том случае, если mallocникогда не потерпит неудачу
  • Однако, если наша реализация запускается на машине с бесконечной памятью, то нет необходимости mallocв сбое. Без нарушения стандарта C наша реализация гарантирует, что mallocникогда не подведет.
• Возможность разыменования указателей, элементов массива поиска и доступа к членам узла связанного списка.

Таким образом, приведенный выше список - это то, что необходимо для реализации машины Тьюринга в нашей гипотетической реализации на Си. Эти функции должны быть прекращены. Однако все остальное может быть прекращено (если это не требуется стандартом). Это включает в себя арифметику, IO и т. Д.

Основным аргументом здесь было то, что размер size_t конечен, хотя может быть бесконечно большим.

Для этого есть обходной путь, хотя я не уверен, совпадает ли это с ISO C.

Предположим, у вас есть машина с бесконечной памятью. Таким образом, вы не ограничены размером указателя. У вас все еще есть ваш тип size_t. Если вы спросите меня, что такое sizeof (size_t), ответ будет просто sizeof (size_t). Если вы спросите, например, больше ли это 100, ответ будет положительным. Если вы спросите, что такое sizeof (size_t) / 2, как вы могли догадаться, ответ по-прежнему sizeof (size_t). Если вы хотите распечатать его, мы можем договориться о выводе. Разница между этими двумя может быть NaN и так далее.

Суть в том, что ослабление условия для size_t конечного размера не нарушит уже существующие программы.

PS Распределение памяти sizeof (size_t) все еще возможно, вам нужен только исчисляемый размер, поэтому допустим, что вы берете все четы (или похожий трюк).

Да, это.

1. Цитируемый ответ

В качестве реакции на большое количество отрицательных ответов на мои (и другие) правильные ответы - по сравнению с пугающе высоким подтверждением ложных ответов - я искал менее теоретически глубокое альтернативное объяснение. Я нашел это . Я надеюсь, что это покрывает некоторые из здесь распространенных ошибок, так что немного больше понимания. Существенная часть аргумента:

[...] Его аргумент таков: предположим, кто-то написал определенную завершающую программу, которой может потребоваться при ее выполнении до некоторого произвольного объема памяти. Не изменяя эту программу, можно апостериорно реализовать часть компьютерного оборудования и его компилятор C, который обеспечивает достаточно памяти для размещения этого вычисления. Это может потребовать расширения ширины char (через CHAR_BITS) и / или указателей (через size_t), но программу не нужно будет модифицировать. Поскольку это возможно, C действительно является Turing-Complete для завершения программ.

Сложность этого аргумента в том, что он работает только при рассмотрении завершающих программ. У завершающих программ есть это замечательное свойство, заключающееся в том, что они имеют статическую верхнюю границу для своего требования к хранилищу, которую можно определить экспериментальным путем, запустив программу над желаемым вводом с увеличивающимися размерами хранилища, пока она не «подойдет».

Причина, по которой меня вводили в заблуждение, заключалась в том, что я рассматривал более широкий класс «полезных» бесконечных программ [...]

Короче говоря, потому что для каждой вычислимой функции есть решение на языке C (из-за неограниченных верхних границ), каждая вычислимая задача имеет программу на C, таким образом, C полна по Тьюрингу.

2. Мой оригинальный ответ

Существуют широко распространенные противоречия между математическими понятиями в теоретической информатике (такими как полнота по Тьюрингу) и их практическим применением, то есть методами в практической информатике. Полнота по Тьюрингу не является свойством физически существующих машин или моделей, ограниченных в пространстве и времени. Это просто абстрактный объект, описывающий свойства математических теорий.

C99 полон по Тьюрингу независимо от ограничений на основе реализации, как и практически любой другой распространенный язык программирования, поскольку он способен выражать функционально полный набор логических связок и в принципе имеет доступ к неограниченному объему памяти. Люди указали, что C явно ограничивает доступ к произвольной памяти, но это ничто, что никто не мог бы обойти, так как это дополнительно заявленные ограничения в стандарте C, в то время как полнота по Тьюрингу уже подразумевается без них :

Вот очень простая вещь о логических системах, которой должно хватить для неконструктивного доказательства. Рассмотрим исчисление с некоторыми аксиомными схемами и правилами, такими, что набор логических следствий равен X. Теперь, если вы добавите некоторые правила или аксиомы, набор логических последствий возрастает, то есть должен быть надмножеством X. Вот почему, например, например, , модальная логика S4 правильно содержится в S5, Точно так же, когда у вас есть под спецификация, полная по Тьюрингу, но вы добавляете некоторые ограничения сверху, они не предотвращают каких-либо последствий в X, т. Е. Должен быть способ обойти все ограничения. Если вы хотите не полный по Тьюрингу язык, исчисление должно быть сокращено, а не расширено. Расширения, которые утверждают, что что-то было бы невозможно, но на самом деле, только добавляют несогласованность. Эти несоответствия в стандарте C могут не иметь практических последствий, так же как полнота по Тьюрингу не связана с практическим применением.

Моделирование произвольных чисел на основе глубины рекурсии (т. Е. Это ; с возможностью поддержки нескольких чисел через планирование / псевдопотоки; теоретического ограничения глубины рекурсии в C не существует ) или использование файлового хранилища для имитации неограниченной памяти программы ( идея ) вероятно, только две из бесконечных возможностей конструктивно доказать полноту по Тьюрингу C99. Следует помнить, что для вычислимости сложность времени и пространства не имеет значения. В частности, допущение ограниченной среды для фальсификации полноты по Тьюрингу является просто циклическим рассуждением, поскольку это ограничение исключает все проблемы, которые превышают предполагаемую границу сложности.

( ПРИМЕЧАНИЕ . Я написал этот ответ только для того, чтобы не дать людям получить математическую интуицию из-за ограниченного мышления, ориентированного на приложения. Очень жаль, что большинство учеников прочтут ложный принятый ответ из-за того, что за него проголосовали фундаментальные недостатки рассуждения, так что больше людей распространят такие ложные убеждения. Если вы отрицаете этот ответ, вы просто являетесь частью проблемы.)