Potência computacional máxima de uma implementação C

Se seguirmos o livro (ou qualquer outra versão da especificação da linguagem, se você preferir), quanta energia computacional pode uma implementação C?

Observe que “implementação C” tem um significado técnico: é uma instanciação específica da especificação da linguagem de programação C em que o comportamento definido pela implementação é documentado. A implementação de CA não precisa ser executada em um computador real. Ele precisa implementar o idioma inteiro, incluindo todos os objetos com uma representação de cadeia de bits e tipos com um tamanho definido pela implementação.

Para os fins desta pergunta, não há armazenamento externo. A única entrada / saída que você pode executar é getchar(ler a entrada do programa) e putchar(gravar a saída do programa). Além disso, qualquer programa que invoque um comportamento indefinido é inválido: um programa válido deve ter seu comportamento definido pela especificação C mais a descrição da implementação dos comportamentos definidos pela implementação listados no apêndice J (para C99). Observe que chamar funções de biblioteca que não são mencionadas no padrão é um comportamento indefinido.

Minha reação inicial foi que uma implementação C não passa de um autômato finito, porque tem um limite na quantidade de memória endereçável (você não pode endereçar mais que sizeof(char*) * CHAR_BITbits de armazenamento, pois endereços de memória distintos devem ter padrões de bits distintos quando armazenados em um ponteiro de bytes).

No entanto, acho que uma implementação pode fazer mais do que isso. Tanto quanto posso dizer, o padrão não impõe limite à profundidade da recursão. Assim, você pode fazer quantas chamadas de função recursivas quiser, apenas todas, exceto um número finito de chamadas, devem usar registerargumentos não endereçáveis ​​( ). Assim, uma implementação C que permite recursão arbitrária e não tem limite no número de registerobjetos pode codificar autômatos de empilhamento determinístico.

Isso está correto? Você consegue encontrar uma implementação C mais poderosa? Existe uma implementação C completa de Turing?

Conforme observado na pergunta, o padrão C requer que exista um valor UCHAR_MAX, de modo que cada variável do tipo unsigned charmantenha sempre um valor entre 0 e UCHAR_MAX, inclusive. Além disso, exige que todo objeto alocado dinamicamente seja representado por uma sequência de bytes que seja identificável via ponteiro do tipo unsigned char*, e que haja uma constante sizeof(unsigned char*)tal que cada ponteiro desse tipo seja identificável por uma sequência de sizeof(unsigned char *)valores do tipo unsigned char. O número de objetos que podem ser alocados dinamicamente simultaneamente é, portanto, rigidamente limitado a . Nada impediria um compilador teórico de atribuir os valores dessas constantes para suportar mais de 10 10 10 objetos, mas, de uma perspectiva teórica, a existência de qualquer limite, por maior que seja, significa que algo não é infinito.$UCHAR\_MAX ^{sizeof(unsigned\ char*)}$$10^{10^{10}}$

Um programa pode armazenar uma quantidade ilimitada de informações na pilha se nada do que estiver alocado na pilha tiver seu endereço ; assim, poderia-se ter um programa em C capaz de fazer algumas coisas que não poderiam ser feitas por nenhum autômato finito de qualquer tamanho. Assim, mesmo que (ou talvez porque) o acesso a variáveis ​​de pilha seja muito mais limitado do que o acesso a variáveis ​​alocadas dinamicamente, ele faz com que C seja um autômato finito em um autômato push-down.

Há, no entanto, outro problema: é necessário que, se um programa examinar as seqüências de tamanho fixo subjacentes dos valores de caracteres associados a dois ponteiros para objetos diferentes, essas sequências sejam únicas. Uma vez que existem apenas $UCHAR\_MAX ^{sizeof(unsigned\ char*)}$Seqüências possíveis de valores de caracteres, qualquer programa que criou um número de ponteiros para objetos distintos além do que não poderia estar em conformidade com o padrão C se o código examinasse a sequência de caracteres associados a esses ponteiros . Em alguns casos, seria possível para um compilador determinar que nenhum código jamais examinaria a sequência de caracteres associados a um ponteiro. Se cada "caractere" fosse realmente capaz de conter qualquer número inteiro finito, e a memória da máquina fosse uma sequência contável e infinita de números inteiros [dada uma máquina de Turing com fita ilimitada, seria possível imitar essa máquina, embora fosse muito lenta], então seria realmente possível tornar C uma linguagem completa de Turing.

Com a biblioteca de encadeamento do C11 (opcional), é possível fazer uma implementação completa do Turing, com profundidade de recursão ilimitada.

Criar um novo encadeamento gera uma segunda pilha; duas pilhas são suficientes para a integridade de Turing. Uma pilha representa o que está à esquerda da cabeça, a outra pilha, o que está à direita.

Eu acho que é Turing completo : podemos escrever um programa que simula um UTM usando esse truque (eu rapidamente escrevi o código manualmente, então provavelmente existem alguns erros de sintaxe ... mas espero que não haja erros (principais) na lógica :-)

• definir uma estrutura que possa ser usada como uma lista vinculada dupla para representação em fita

    typdef struct {
      cell_t * pred; // célula à esquerda
      cell_t * succ; // célula à direita
      int val; // valor da célula
    } cell_t 

O headserá um ponteiro para uma cell_testrutura

• definir uma estrutura que possa ser usada para armazenar o estado atual e um sinalizador

    typedef struct {
      estado int;
      sinalizador int;
    } info_t 

• em seguida, defina uma função de loop único que simule um Universal TM quando a cabeça estiver entre os limites da lista de links duplos; quando a cabeça atingir um limite, defina o sinalizador da estrutura info_t (HIT_LEFT, HIT_RIGHT) e retorne:

void simulate_UTM (célula_t * cabeça, info_t * informação) {
  while (true) {
    head-> val = UTM_nextsymbol [info-> estado, head-> val]; // escreve símbolo
    info-> state = UTM_nextstate [info-> state, head-> val]; // próximo estado
    if (info-> state == HALT_STATE) {// imprime se aceita e sai do programa
       putchar ((info-> estado == ACCEPT_STATE)? '1': '0');
       saída (0);
    }
    int move = UTM_nextmove [info-> estado, cabeça-> val];
    if (move == MOVE_LEFT) {
      cabeça = cabeça-> pred; // vire à esquerda
      if (head == NULL) {info-> flag = HIT_LEFT; Retorna; }
    } outro {
      cabeça = cabeça-> succ; // move para a direita
      if (head == NULL) {info-> flag = HIT_RIGHT; Retorna; }
    }
  } // ainda no limite ... continue
}

• em seguida, defina uma função recursiva que primeiro chame a rotina UTM de simulação e depois se chame recursivamente quando a fita precisar ser expandida; quando a fita precisa ser expandida na parte superior (HIT_RIGHT), não há problemas; quando ela precisa ser deslocada na parte inferior (HIT_LEFT), basta mudar os valores das células usando a lista vinculada dupla:

empilhador nulo (cell_t * top, cell_t * bottom, cell_t * head, info_t * info) {
  simulate_UTM (cabeça, informações);
  cell_t newcell; // a nova célula
  newcell.pred = top; // atualiza a lista vinculada dupla com a nova célula
  newcell.succ = NULL;
  top-> succ = & newcell;
  newcell.val = EMPTY_SYMBOL;

  switch (info-> clique) {
    caso HIT_RIGHT:
      empilhador (& newcell, bottom, newcell, info);
      quebrar;
    caso HIT_BOTTOM:
      cell_t * tmp = nova célula;
      while (tmp-> pred! = NULL) {// aumenta valores
        tmp-> val = tmp-> pred-> val;
        tmp = tmp-> pred;
      }
      tmp-> val = EMPTY_SYMBOL;
      empilhador (& newcell, bottom, bottom, info);
      quebrar;
  }
}

• a fita inicial pode ser preenchida com uma função recursiva simples que cria a lista vinculada dupla e, em seguida, chama a stackerfunção quando lê o último símbolo da fita de entrada (usando readchar)

void init_tape (célula_t * parte superior, célula_t * parte inferior, info_t * informação) {
  cell_t newcell;
  int c = readchar ();
  if (c == END_OF_INPUT) empilhador (& superior, inferior, inferior, informações); // não há mais símbolos, comece
  newcell.pred = top;
  if (top! = NULL) top.succ = & newcell; else bottom = & newcell;
  init_tape (& newcell, bottom, info);
}

EDIT: depois de pensar um pouco sobre isso, há um problema com os ponteiros ...

se toda chamada da função recursiva stackerpuder manter um ponteiro válido para uma variável definida localmente no chamador, tudo estará bem ; caso contrário, meu algoritmo não pode manter uma lista válida de vínculo duplo na recursão ilimitada (e, neste caso, não vemos uma maneira de usar a recursão para simular um armazenamento ilimitado de acesso aleatório).

Desde que você tenha um tamanho ilimitado de pilha de chamadas, você pode codificar sua fita na pilha de chamadas e acessá-la aleatoriamente rebobinando o ponteiro da pilha sem retornar das chamadas de função.

Edição : Se você só pode usar o carneiro, que é finito, essa construção não funciona mais, então veja abaixo.

No entanto, é altamente questionável por que sua pilha pode ser infinita, mas a ram intrínseca não é. Então, na verdade, eu diria que você nem consegue reconhecer todas as linguagens regulares, pois o número de estados é limitado (se você não contar o truque de rebobinar a pilha para explorar a pilha infinita).

Eu até especularia que o número de idiomas que você pode reconhecer é finito (mesmo que os próprios idiomas possam ser infinitos, por exemplo a*, tudo bem, mas b^ksó funciona para um número finito de ks).

EDIT : Isso não é verdade, pois você pode codificar o estado atual em funções extras, para que você possa realmente reconhecer TODOS os idiomas regulares.

Provavelmente, você pode obter todos os idiomas do Tipo 2 pelo mesmo motivo, mas não tenho certeza se você consegue colocar ambos, o estado e a constante da pilha na pilha de chamadas. Mas, de maneira geral, você pode efetivamente esquecer o carneiro, pois sempre pode dimensionar o tamanho do autômato para que seu alfabeto exceda a capacidade do carneiro. Então, se você pudesse simular uma TM com apenas uma pilha, o Tipo 2 seria igual ao Tipo 0, não seria?

Pensei nisso uma vez e decidi tentar implementar uma linguagem sem contexto, usando a semântica esperada; a parte principal da implementação é a seguinte função:

void *it;

void read_triple(void *back)
{
  if(read_a()) read_triple(&back);
  else reject();
  for(it = back; it != NULL; it = *it)
     if(!read_b()) reject();
  if(read_c()) return;
  else reject();
}

$\{a^n b^n c^n\}$

Pelo menos, acho que isso funciona. Pode ser que eu esteja cometendo algum erro fundamental, no entanto.

Uma versão fixa:

void *it;

void read_triple(void *back)
{
  if(read_a()) read_triple(&back);
  else for(it = back; it != NULL; it = * (void **) it)
     if(!read_b()) reject();
  if(read_c()) return;
  else reject();
}

Na linha da resposta do @ supercat:

As alegações de incompletude de C parecem estar centradas em torno de que objetos distintos devem ter endereços distintos, e o conjunto de endereços é considerado finito. Como @supercat escreve

Conforme observado na pergunta, o padrão C requer que exista um valor UCHAR_MAXtal que toda variável do tipo char não assinado sempre mantenha um valor entre 0 e UCHAR_MAXinclusive. Além disso, exige que todo objeto alocado dinamicamente seja representado por uma sequência de bytes que seja identificável por meio de ponteiro do tipo char não assinado *, e que haja uma constante sizeof(unsigned char*)tal que todo ponteiro desse tipo seja identificável por uma sequência de sizeof(unsigned char *)valores do tipo não assinado Caracteres.

unsigned char*$\mathbb{N}$$\{0, 1\}$sizeof(unsigned char*)$\{0, 1\}^{\operatorname{sizeof}(\mathit{unsigned\ char*})}$$\mathbb{N}$sizeof(unsigned char*)$\mathbb{N}$$\omega$

Nesse ponto, deve-se verificar se o padrão C realmente permitiria isso.

sizeof$\in \mathbb Z$