Existe-t-il une relation directe entre la complexité d'un algorithme (tel que le meilleur / pire des cas de tri rapide) et la classe d'automates qui peuvent implémenter l'algorithme.
La question de savoir quelle classe d'automates peut implémenter un algorithme donné comme le tri rapide est délicate, car on ne sait pas ce qui compterait comme une implémentation de cet algorithme. Pour un tri rapide, les comparaisons effectuées doivent certainement être les mêmes, mais l'ordre dans lequel les comparaisons se produisent doit-il également être le même? Qu'en est-il de l'ordre des accès en lecture à des éléments spécifiques de l'entrée? L'ordre des opérations de copie, de déplacement et d'échange pour des éléments spécifiques?
Vous devrez spécifier un certain nombre d' oracles pour les opérations qui vous importent, mais vous êtes déjà dans une situation très spécifique basée sur l'algorithme, et assez loin des classes générales d'automates généralement étudiées. Le moyen de contourner ce dilemme est de parler de problèmes plutôt que d'algorithmes, et de formaliser les problèmes en parlant de langages.
Par exemple, existe-t-il une gamme de complexité que les automates de refoulement peuvent exprimer?
Pas vraiment, car un automate poussé ne peut lire son entrée qu'une seule fois et uniquement dans le sens direct. Cependant, si vous divisez la machine en une partie qui est autorisée à lire l'entrée vers l'avant et vers l'arrière comme elle le souhaite, et conservez un nombre fini de pointeurs vers des positions d'entrée spécifiques (NL), et une partie qui est un automate poussant qui reçoit son entrée de l'autre partie, alors vous obtenez la classe de complexité LOGCFL , qui est égale à SAC 1 (une classe de circuit).
Si vous ne séparez pas ces deux parties et d' ajouter juste une pile à NL, alors vous obtenez la classe des automates AuxPDA , ce qui équivaut à la classe de complexité P . Mais si vous décidez de limiter le temps d'exécution de ces automates (avec pile et stockage auxiliaire logarithmique) au temps polynomial, vous obtenez alors NAuxPDA P , qui est à nouveau égal à LOGCFL. (Et si vous insistez sur l'exécution polynomiale déterministe, supprimez la pile, mais autorisez le stockage auxiliaire polylogarithmique, alors vous obtenez SC .)
D'un autre côté, si vous gardez la restriction selon laquelle les automates ne peuvent lire son entrée qu'une seule fois et uniquement dans le sens direct, et exigez en outre qu'il ne puisse utiliser sa pile que d'une manière très déterministe directement basée sur l'entrée (c'est-à-dire le symbole d'entrée détermine si ces automates poussent quelque chose sur la pile, sautent quelque chose de la pile ou laissent la pile intacte), puis vous vous retrouvez avec un automate visiblement pushdown, qui reconnaît exactement les langages de mots imbriqués , qui peuvent également être reconnus dans l'espace logarithmique déterministe .