On vous donne, sous forme de liste ou de vecteur ou autre, un tas de 3-tuples ou autre, où les deux premières choses sont des chaînes, et la troisième chose est un nombre. Les chaînes sont des villes et le nombre est la distance entre elles. L'ordre des villes dans le tuple est arbitraire (c'est-à-dire que peu importe ce qui vient en premier et ce qui vient en second) car c'est la même distance dans chaque sens. En outre, il existe exactement un tuple pour chaque paire de citations connectées. Toutes les villes ne sont pas connectées. De plus, la distance est toujours positive (pas0
). Vous n'avez pas besoin de vérifier ces conditions, vous pouvez supposer que l'entrée sera bien formée. Votre travail consiste à renvoyer les villes dans une séquence cyclique, de sorte que, si vous commencez dans une ville et que vous revenez dans la même ville, le total des distances entre les villes sera minimum (exactement et en tout .) Vous pouvez supposer qu'une solution existe. Par exemple, disons qu'on vous donne
[("New York", "Detroit", 2.2), ("New York", "Dillsburg", 3.7), ("Hong Kong", "Dillsburg", 4), ("Hong Kong", "Detroit", 4), ("Dillsburg", "Detroit", 9000.1), ("New York", "Hong Kong", 9000.01)]
Vous pouvez générer l'un des éléments suivants (mais vous n'en avez besoin que d'un):
["Detroit","Hong Kong","Dillsburg","New York"]
["Hong Kong","Dillsburg","New York","Detroit"]
["Dillsburg","New York","Detroit","Hong Kong"]
["New York","Detroit","Hong Kong","Dillsburg"]
["Dillsburg","Hong Kong","Detroit","New York"]
["New York","Dillsburg","Hong Kong","Detroit"]
["Detroit","New York","Dillsburg","Hong Kong"]
["Hong Kong","Detroit","New York","Dillsburg"]
car c'est le trajet le plus court: 13,9
mais non
["Dillburg","Detroit","New York","Hong Kong"]
car ce n'est pas le plus court.
Voir en.wikipedia.org/wiki/Travelling_salesman_problem
Notation
C'est là que ça devient intéressant. Vous prenez le nombre de caractères que vous avez, puis vous les branchez dans la pire formule de notation O du pire cas. Par exemple, disons que vous écrivez un programme de force brute de 42 caractères. Comme nous le savons tous, le pire des cas est n!
où n
est le nombre de villes. 42! = 1405006117752879898543142606244511569936384000000000, c'est donc votre score. Le score le plus bas l'emporte .
Remarque: J'ai également soulagé cela par la suite, mais je ne savais pas comment le résoudre et j'espérais que personne ne le remarquerait. Les gens l'ont fait, je vais donc suivre la suggestion d'Issacg:
les seules options sont O (n!) et O (b ^ n n ^ a ln (n) ^ k), et toutes les limites doivent être aussi serrées que possible étant donné que la notation
la source
O(n!)
mais pasO(sqrt(n)*n^n/e^n)
niO(n!/100000000000000000000)
?O(n!)
etO(b^n*n^a*ln(n)^k)
, et toutes les limites doivent être aussi serrées que possible compte tenu de cette notation. OP devrait clarifier, cependant.O(n^2*2^n)
, ce qui est beaucoup moins queO(n!)
pour les grands n.Réponses:
Haskell, 259
J'ai pensé que je pourrais le raccourcir. peut être que je le ferais.
cela a une complexité temporelle de O (n ^ 2 * 2 ^ n) * donc le score est d'environ 6,2e82
* Je ne suis pas vraiment sûr, mais s'il y a un "ajout" à la complexité, ce n'est pas plus que polynomial, donc cela ne devrait pas beaucoup changer le score.
la source
Python 2,
237231228225 caractèresPuisqu'il s'agit d'un algorithme naïf, son score est probablement d'environ 225! ≈ 1.26e433.
la source
from itertools import*
serait plus court.("a", "a", 0)
, il faudrait une logique supplémentaire quelque part pour ignorer les bords de longueur nulle. (Et si vous êtes sur le Web, vous pouvez toujours tester avec quelque chose comme codepad.org. )sum
à chaque élément d'une permutation. N'est-ce pasO(n!*n)
?Julia, 213 caractères
n!n
Va probablement comme , donc ~ 2e407.Pour plus de lisibilité et pour démontrer l'utilisation, j'ai laissé dans certains sauts de ligne et onglets non marqués ainsi que des exemples d'entrée et un appel à la fonction. J'ai également utilisé un algorithme qui nécessite du
n!
temps, mais pas den!
mémoire, son légèrement plus réalisable à exécuter.la source
sum
sur chaque élément d'une permutation. Ne serait-ce pas O (n! * N)?Python 3-491
Je n'ai pas compté la longueur de la variable graphique d'entrée
g
. Cette solution utilise une programmation dynamique et a une complexité de n ^ 2 * 2 ^ n, pour un score total de ~ 6,39e147. Je suis encore assez novice dans le golf, alors n'hésitez pas à jouer si vous voyez un gros gaspillage de code quelque part!la source
Mathematica, 66 octets
Aucune idée de la complexité, donc le score se situe entre
10^23
et10^93
.la source
Rubis,
198180 octetsLa première ligne qui lit l'entrée n'est pas notée, car cela semble être ce que tout le monde fait. De plus, aucune nouvelle ligne finale n'est nécessaire pour le rubis.
Il génère simplement toutes les permutations des villes, alors mettez-moi de côté
O(n!*n)
. En fait, à y réfléchir, c'est plus lent encore que cela, car il trie tous lesO(n!)
chemins plutôt que de garder la trace des meilleurs jusqu'à présent.la source