Y at-il des problèmes qui deviennent plus faciles avec leur taille?

C'est peut-être une question ridicule, mais est-il possible d'avoir un problème qui devient réellement plus facile à mesure que les intrants grossissent? Je doute que des problèmes pratiques se présentent de la sorte, mais peut-être pourrions-nous inventer un problème dégénéré qui possède cette propriété. Par exemple, il commence peut-être à se «résoudre» à mesure qu’il grandit ou à se comporter d’une autre manière bizarre.

Non, ce n’est pas possible: du moins, pas dans un sens asymptotique, où vous avez besoin que le problème continue de s’obtenir strictement plus facile, pour toujours, comme .$n \to \infty$

Soit le meilleur temps d'exécution possible pour résoudre un tel problème, où est la taille de l'entrée. Notez que le temps d'exécution est un décompte du nombre d'instructions exécutées par l'algorithme, il doit donc s'agir d'un entier non négatif. En d'autres termes, pour tout . Maintenant, si nous considérons une fonction , nous voyons qu’il n’existe pas de telle fonction décroissante de façon strictement monotone. (Quel que soit , il doit être fini, disons ; mais comme est monotone décroissant, etn T ( n ) ∈ N n T : N → N T ( 0 ) T ( 0 ) = c T T ( c ) ≤ 0 T ( c + 1 ) ≤ - 1 T ( n ) n 0 n ≥ n 0 T ( n $T(n)$$n$$T(n) \in \mathbb{N}$$n$$T: \mathbb{N} \to \mathbb{N}$$T(0)$$T(0)=c$$T$$T(c) \le 0$$T(c+1) \le -1$, ce qui est impossible.) Pour des raisons similaires, il n’existe pas de fonction décroissante asymptotiquement: on peut de même prouver qu’il n’existe pas de fonction de temps où il existe tel que pour tout , est strictement décroissante de façon monotone (toute fonction de ce type devrait finir par devenir négative).$T(n)$$n_0$$n \ge n_0$$T(n)$

Un tel problème ne peut donc pas exister pour la simple raison que les durées d'exécution doivent être des entiers non négatifs.

Notez que cette réponse ne couvre que les algorithmes déterministes (c'est-à-dire le temps d'exécution le plus défavorable). Il n’exclut pas la possibilité d’algorithmes aléatoires dont la durée d’exécution attendue décroît de façon strictement monotone, pour toujours. Je ne sais pas s'il est possible qu'un tel algorithme existe. Je remercie Beni Cherniavsky-Paskin pour cette observation .

Bien que ce ne soit pas tout à fait une réponse à votre question, l' algorithme de recherche de chaînes de Boyer-Moore s'en rapproche. Comme Robert Moore le dit sur sa page Web à propos de l'algorithme,

Notre algorithme a la propriété particulière que, grosso modo, plus le motif est long, plus l'algorithme va vite.

En d'autres termes, l'algorithme recherche généralement une instance d'une chaîne cible dans une chaîne source et une chaîne source fixe, plus la chaîne cible est longue, plus l'algorithme s'exécute rapidement.

Clairement, d'un point de vue purement mathématique, purement algorithme CS, cela est impossible. Mais en réalité, il existe plusieurs exemples concrets de la simplification de la mise à l'échelle de votre projet, dont beaucoup ne sont pas intuitives pour les utilisateurs finaux.

Directions : plus vos directions sont longues, plus elles deviennent parfois plus faciles. Par exemple, si je veux que Google Maps me donne des indications pour aller à l'ouest sur une distance de 3000 km, je pourrais me rendre sur la côte ouest et obtenir des instructions de conduite pour tout le pays. Mais si je voulais aller à 6000 km à l’ouest, je me retrouverais avec des instructions beaucoup plus simples: prendre un avion de New York à Hokkaido. Me donner une route de fond qui intègre le trafic, les routes, la météo, etc. est assez difficile sur le plan algorithmique, mais me dire de monter dans un avion et de rechercher des vols dans une base de données est comparativement beaucoup plus simple. Graphique ASCII de difficulté vs distance:

           |     /
           |    /
Difficulty |   /                  ____-------
           |  /           ____----
           | /    ____----
            ---------------------------------
                       Distance

Rendu : disons que je veux un rendu d'un visage et un rendu de 1000 visages; il s’agit d’une annonce publicitaire, les deux images finales doivent donc être de 10 000 pixels par 5 000 pixels. Rendre un visage réaliste serait difficile - avec une résolution de plusieurs milliers de pixels, vous devez utiliser des machines très puissantes - mais pour une foule de 1 000 visages, chaque visage ne doit comporter que dix pixels de large et peut facilement être cloné! Je pourrais probablement restituer 1000 visages sur mon ordinateur portable, mais rendre un visage réaliste à 10000 pixels de large prendrait beaucoup de temps et nécessiterait des machines puissantes. Graphique ASCII de difficulté par rapport aux objets rendus, montrant comment la difficulté de rendre n objets en une image d'une taille définie disparaît rapidement, puis revient lentement:

           | -    
           |- -                     _________
Difficulty |   --      ______-------            
           |     ------      
           |       
            ---------------------------------
                        Objects

Contrôle du matériel : beaucoup de choses avec le matériel deviennent beaucoup plus faciles. "Déplacer le moteur X 1 degré" est difficile et / ou impossible, et vous devez faire face à toutes sortes de choses que vous n'auriez pas à traiter pour "déplacer le moteur X 322 degrés".

Tâches de courte durée: Disons que vous souhaitez que l'élément X soit activé (très peu de temps) toutes les secondes. En augmentant la durée d'exécution de X, vous aurez besoin de logiciels et de matériel moins complexes.

Il y a des cas. Ce sont les cas où le critère de succès est fonction des données plutôt que d'essayer de trouver une réponse unique. Par exemple, les processus statistiques dont les résultats sont formulés avec des intervalles de confiance peuvent devenir plus faciles.

Un cas particulier auquel je pense est celui des problèmes qui passent de comportements discrets à des comportements continus, tels que les écoulements de fluide. Résoudre le petit problème avec un degré d'erreur maximum peut impliquer la modélisation de toutes les interactions discrètes, ce qui peut nécessiter un superordinateur. Les comportements continus permettent souvent des simplifications sans donner de résultats en dehors d’une erreur corrélée.

La question est intéressante et UTILE, car notre philosophie en informatique est de résoudre les problèmes plus nous lisons, plus la lecture est difficile. Mais, en réalité, la plupart des problèmes présentés de manière typique (difficile) peuvent être facilement représentés de manière "facile"; même en connaissant la réponse de DW (ce qui est faux en considérant que facile ne veut pas dire plus vite, veut dire "moins lent"; vous n'avez donc pas à trouver des moments négatifs, vous avez peut-être à trouver des moments asymptotiques).

L'astuce pour en trouver un consiste à mettre la partie de la solution comme une indication comme entrée et à considérer l'entrée du problème comme un paramètre constant.

Exemple: Quel est le plus long trajet en voiture entre Londres et Paris en évitant de visiter deux villes française et britannique et de ne pas visiter d’autres pays? considérez, vous devez aller à Birmingham avant Ashford, Orléans avant Versailles, La Rochelle avant Limoge, etc ...

Il est clair que ce problème avec les entrées longues sera plus facile qu'avec les entrées courtes.

Exemple d’utilisation: Imaginez un jeu géré par la machine et l’IA de l’ordinateur doit déterminer s’il doit explorer davantage le jeu pour trouver plus d’allusions, sinon, si le moment est venu de déduire quelle est la meilleure décision à prendre .

Prenons un programme qui prend en entrée ce que vous savez sur un mot de passe, puis tente de le déchiffrer. Je pense que cela fait ce que tu veux. Par exemple:

• Pas d'entrée-> La force brute craque sur tous les symboles et un mot de n'importe quelle longueur
• Longueur du mot de passe -> Force brute de tous les symboles d'un mot de cette longueur
• Symboles contenus -> Réduit la liste des symboles à vérifier
• ...
• Symboles contenus incluant les occurrences multiples et la longueur -> Calculer uniquement les permutations
• Tous les symboles dans le bon ordre -> fondamentalement résolu

Je devrais ajouter que c’est un truc, car le problème énoncé est inverse à la taille de la saisie. Vous pouvez laisser de côté une couche d'abstraction et dire que la taille d'entrée est grande sans entrée (vérifiez tous les symboles et la longueur des mots) et petite si vous entrez le mot de passe correct au début.

Donc, tout dépend de l'abstraction que vous permettez.

En fait, j'ai un problème qui diminue à mesure que les données augmentent. L'une de mes applications enregistre les attributs d'un produit particulier, par exemple le fromage. Les attributs sont par exemple le type de fromage, la marque, le pays, la région, le type de lait, etc. Chaque mois environ, je reçois une liste des nouveaux fromages arrivés sur le marché pendant cette période, ainsi que leurs attributs. Maintenant, ces attributs sont typés à la main par un groupe d'humains. Certains font des fautes de frappe ou ne connaissent tout simplement pas la valeur de tous les attributs.

Lorsque vous effectuez une recherche dans ma base de données, j'essaie de prédire à partir de statistiques le goût du fromage, en fonction de ces attributs. Qu'est-ce qui se passe, c'est que pour chaque attribut, je me retrouve avec une plage de valeurs; certains sont valides, d'autres sont invalides. L'élimination ou la correction de ces invalides n'est possible que si j'ai suffisamment de données. Il s'agit de faire la différence entre les valeurs réelles et le bruit, sans éliminer les valeurs rares mais valables.

Comme vous pouvez l’imaginer, avec un faible volume, le bruit est trop important pour que tout soit réglé correctement. Si vous avez 5 instances de Cheddar, 1 de Brie, 1 de Bri et 1 de Chedar, comment puis-je savoir lequel est correct et lequel est une faute de frappe? Avec plus de volume, les fautes de frappe ont tendance à rester très bas, mais les valeurs rares obtiennent quelques incréments cruciaux, les faisant échapper au bruit (adossé à l'expérience). Dans ce cas, je pourrais par exemple imaginer 50000 cheddar, 3000 brie, 5 bri, 15 chédar.

Alors oui, certains problèmes se résolvent d'eux-mêmes lorsque vous avez suffisamment de données.

Considérons le problème NP-complet 3-SAT. Si vous continuez à augmenter le problème en fournissant des entrées de la forme x_i = true / false, vous finissez par convertir les disjonctions individuelles en clauses à deux variables, créant ainsi un problème à 2 SAT résolument P, ou vous obtenez simplement une réponse vraie / fausse.

Dans le cas où il y a redondance dans les entrées x_i = true / false (même entrée fournie plusieurs fois, ou entrées contradictoires), vous pouvez facilement trier les entrées et ignorer les valeurs redondantes ou signaler une erreur si les valeurs sont en contradiction.

Dans tous les cas, je pense que cela représente un problème «réaliste» qui devient plus facile à résoudre à mesure que le nombre d’entrées augmente. L'aspect «plus facile» consiste à convertir un problème NP-complet en un problème P. Vous pouvez toujours jouer avec le système en fournissant des entrées ridicules telles que le tri prendrait plus de temps que forcer brutalement le problème.

Maintenant, un scénario vraiment cool serait que si nous sommes prêts à accepter, T (0) (en utilisant la notation de DW dans la réponse ci-dessus) peut être infini. Par exemple, T (0) pourrait être équivalent à résoudre le problème de Halting de Turing. Si nous pouvions concevoir un problème tel que l'ajout d'intrants supplémentaires le convertisse en un problème pouvant être résolu, nous aurions trouvé de l'or. Notez qu'il ne suffit pas de le convertir en un problème pouvant être résolu de manière asymptotique - car c'est aussi grave que de forcer le problème.

La question demande: "est-il possible d'avoir un problème qui devient réellement plus facile à mesure que les intrants grossissent?" Que se passe-t-il si les entrées sont des ressources à utiliser par l'algorithme pour travailler sur un travail? Tout le monde sait que plus il y a de ressources, mieux c'est. Vous trouverez ci-dessous un exemple dans lequel plus il y a d'employés, mieux c'est.

$n$
$t$$p$

$n$

3) Sortie:
La sortie représente les chemins entre les tâches à prendre par les employés. Chaque chemin est associé au nombre d'employés qui le suivent. Par exemple:

$n1$
$n2$
$n3$
$n4$
$n5$

4) Solution possible:
Une solution possible consiste à calculer d’abord le chemin le plus court vers les nœuds les plus proches, à partir de A. Ce sera un chemin aller. Ensuite, calculez récursivement le chemin de transfert pour chaque tâche visitée. Le résultat est un arbre. Par exemple:

          UNE
      avant JC
    DE

$n$$n1$$n2$$n2 \neq 0$

$n=\infty$$n = 1$

$n$