В то время как другие ответы дают хорошие моменты, я чувствую, что все еще немного не согласен. Итак, я поделюсь своими мыслями по этому вопросу.
Короче говоря, я думаю, что постоянное «как есть» - это в лучшем случае упущенная возможность. Возможно, это лучшее, что мы можем получить на данный момент, но это далеко от идеала.
Но сначала я думаю, что короткая экскурсия не обязательна.
Когда у нас есть эффективный алгоритм?
Когда Даниэль Санк спросил меня, что я буду делать, если бы существовал алгоритм для вычисления простых чисел с помощью 106Фактор ускорения на тестовом наборе серьезных случаев, я сначала ответил, что сомневаюсь, что это будет связано с алгоритмическими улучшениями, но с другими факторами (или машиной, или реализацией). Но я думаю, что у меня другой ответ сейчас. Позвольте мне дать вам тривиальный алгоритм, который может учитывать очень большие числа в течение миллисекунд и тем не менее очень неэффективный :
- Взять набор п из (довольно больших) простых чисел.
- вычисление п2множество всех композитов с двумя факторами из п, Для каждого композита сохраните, какая пара простых чисел используется для его построения.
- Теперь, когда дан экземпляр из п2Просто посмотрите на факторизацию в нашей таблице и сообщите об этом. В противном случае сообщить об ошибке
Я надеюсь, что очевидно, что этот алгоритм является мусором, так как он работает только правильно, когда наш вход в п2, Тем не менее, можем ли мы увидеть это, когда алгоритм представлен в виде черного ящика и «по совпадению» только тест с входными данными изп? Конечно, мы можем попробовать протестировать множество примеров, но это очень легко сделатьп очень большой без алгоритма, неэффективного на входах от п2 (возможно, мы хотим использовать хэш-карту или что-то в этом роде).
Таким образом, не исключено, что наш алгоритм мусора, по совпадению, может показаться «чудесным» ускорением. Теперь, конечно, есть много методов проектирования экспериментов, которые могут снизить риск, но, возможно, более хитрые «быстрые» алгоритмы, которые все еще не работают во многих, но недостаточно примеров, могут обмануть нас! (также обратите внимание, что я предполагаю, что ни один исследователь не является злым , что усугубляет ситуацию!)
Итак, я бы сейчас ответил: «Разбудите меня, когда появится лучший показатель производительности».
Как мы можем сделать лучше, тогда?
Если мы можем позволить протестировать наш алгоритм «черного ящика» во всех случаях, мы не можем быть обмануты вышеизложенным. Однако это невозможно для практических ситуаций. (Это можно сделать в теоретических моделях!)
Вместо этого мы можем создать статистическую гипотезу для некоторого параметризованного времени выполнения (обычно для входного размера), чтобы проверить это, возможно адаптировать нашу гипотезу и протестировать снова, пока мы не получим гипотезу, которая нам нравится, и отклонение нулевого значения не кажется разумным. (Обратите внимание, что, вероятно, есть и другие факторы, которые я игнорирую. Я практически математик. Дизайн эксперимента не входит в мои компетенции)
Преимущество статистического тестирования на параметризацию (например, наш алгоритм O ( n3)? ) является то, что модель является более общей и, следовательно, ее «обмануть» сложнее, чем в предыдущем разделе. Это не невозможно, но, по крайней мере, статистические утверждения о том, является ли это обоснованным, могут быть оправданы.
Итак, что делать с константами?
Думаю только констатирую109 Ускорение, вау! »- плохой способ разобраться с этим делом. Но я также считаю, что игнорирование этого результата также плохо.
Я думаю, что наиболее полезно рассматривать любопытную константу как аномалию , т.е. это утверждение само по себе требует дальнейшего изучения. Я думаю, что создание гипотез, основанных на более общих моделях, чем просто «наш алгоритм требует X времени», является хорошим инструментом для этого. Так что, хотя я не думаю, что мы можем просто взять на себя соглашения CS здесь, полностью игнорировать «презрение» к константам - тоже плохая идея.