Это мой нетехнический подход к объяснению нотации Big O, в конце концов, он для всех.
Я изучил Big O из разных источников. Много раз я обнаруживал, что они всегда объясняют это математическими терминами. У меня нет проблем с математическими определениями, но вы можете согласиться со мной, что это не всем понятно.
Следуйте за мной, поскольку я немного отклоняюсь, возможно, вы помните тему предоставления 10 программистам одной проблемы для решения и того, как они возвращаются по крайней мере с 10 различными программами для решения проблемы. Как задающий вопрос, вы хотели бы знать одну важную вещь: как каждая из программ измеряет, когда она используется. Возможно, вы также поняли, что метрики — это новое крутое и хорошее руководство. На данный момент я предполагаю, что все программы, представленные программистами, не содержат ошибок. Аминь. Кстати, если вы не помните задачу дать 10 программистам одну задачу, ну вы ее сейчас поняли.
Если вы когда-нибудь будете решать проблемы, вы обязательно захотите использовать наилучший вариант, который могла придумать ваша голова на тот момент. Лично я использую одну хитрость — записываю план. Обычно это планы, затем снова планы, затем перепланированные планы, а затем снова планы и снова планы. К чему я веду, так это к тому, что поиск лучшего процесса может быть нервным и запутанным итеративным потоком.
Эти проблемы могут варьироваться от организации вашей дневной деятельности до решения гамильтоновой траектории графа. Итак, вы видите, мы все программисты, и нам всем нужно видеть Big O как любимца, вместе.
Big O описывает лучший и худший случай алгоритма, а пример алгоритма находится в шагах по приготовлению риса jollof. Он отвечает на вопрос: «Как меняется количество шагов по мере увеличения данных в этом алгоритме?». Этот вопрос очень важен в программировании. Мы имеем дело с большим количеством входных и выходных данных, и знание того, как увеличение входных данных влияет на программу, может быть полезным для стабильности вашей метрической таблицы.
Один из способов описания Biggy состоит в том, что он описывает верхнюю границу роста функции. Программу можно заменить функцией, но здесь нам нужна концепция функций, чтобы можно было получить простое графическое представление. Мне нравится смотреть на эту верхнюю границу с точки зрения нигерийского разза как «e bab — e bad». Вы знаете, максимальная высота, которую может достичь невысокий человек, находится там, где земля является осью x, а высота — осью y. Если у вас есть два примера невысоких людей, вы знаете, что e bab — e bad высоты этих линейных функций одинаковы. Это то же самое, что сказать, что если функция g(x) растет не быстрее, чем другая функция f(x), то говорят, что g принадлежит большому O(f). Чтобы углубиться, мы соглашаемся, что независимо от того, как долго мы ждем, e bab — e badодинаково для этих двух функций. Независимо от приращения ввода, большое О остается тем же. Программы, которые сравниваются таким образом, имеют одинаковые большие O.
В то время как Big O эффективно описывает наилучший и наихудший сценарии данного алгоритма, его обозначение, Big O(n), обычно подразумевает наихудший сценарий, если не указано иное, а n подразумевает количество входных данных или шагов. Отсюда и «эбад-эбад».
Хотя пишется как O(n), обычно произноситсябольшое O от n.
Мне также понравился этот объяснительный подход:
— https://medium.com/karuna-sehgal/a-simplified-explanation-of-the-big-o-notation-82523585e835
