Тут плюс в том хотя бы, что есть понимание что человек 5 лет не пиво пил (если у него ВО). Ну и алгоритмическую сложность по своему коду должен навскидку представлять.
Но опять же, действительно, для составителя формочек такие знания излишни. Но как вариант, человека владеющего такими знаниями можно сразу отсекать. Работать ему в таком месте будет скучно, придумает ещё что ни будь… Как потом это разбирать если никто не рубит?
Поэтому, на первом этапе наилучшая сложность по времени:для почти упорядоченных данных — O(n),для рандомных данных — O(n log n).
По аналогии с бинарной кучей это можно сделать за O(n).
На втором этапе наилучшая сложность по времени такая же как и на первом:для почти упорядоченных данных — O(n),для рандомных данных — O(n log n).
Тут ошибка, в лучшем случае будет так же - O(n log n), просто коэффициент ниже. Перебор списка куч никуда не деть, их количество для определённого размера в среднем log2(n) / 2.
С определёнными интегралами есть один фокус (по типу как в первом примере), который их решение делает на уровне применения правил Лапиталя, а не вот то решение, что приведено. И физики им вполне успешно пользуются.
Ох ты, и 1-го оказывается достаточно (спасибо ermouth)
Если вы знаете среду (или язык программирования), которые совместимы с не типизированным лямбда исчислением и позволят формализовать содержимое главы в них и проводить вычисления\проверки, то обязательно напишите об этом в комментариях.
А чем типизированная не годится? Y-комбинатор просто вводится дополнительно.
Да и вроде в хаскеле довольно легко делается обвязка для интерпретации. (в учебнике была)
Броня должна согласовываться с умениями (увертка, паринг, щит, количество ударов) и всё станет куда веселее. Маг явно не может бить как воин, но они должны быть равны в возможностях.
Плохо когда формулы битвы разные.
Есть мобы с чем-то ценным, есть - для прокачки.
Плохо когда хиты мобов улетают в небеса по сравнению с игроками. ПКилить становится гораздо легче чем расти. Это большинство игр превращает в «царь горы».
Групповая игра должна давать преимущества, но не оверные.
Хромиум явно не показатель хорошего кода, эти Авгиевы конюшни ещё аукнутся. Scitter как раз пример, что всё проще может быть.
Не так оно бесполезно как кажется. Сетка хорошо ложится на оптику, а это быстрее полупроводниковой схемы.
рекурсию конечные автоматы реализовать не могут.
Для лексера придётся описать все разумные варианты.
Вы копнули очень интересную вещь, вам очень сильно повезло, на неё появился в последнее время спрос.
Но это сравни предпринимательству. По типу «составителя эссэ».
Автор статьи таких людей упоминает, говоря что это хорошо, но основной массе, к сожалению, кушать надо здесь и сейчас.
Тут плюс в том хотя бы, что есть понимание что человек 5 лет не пиво пил (если у него ВО). Ну и алгоритмическую сложность по своему коду должен навскидку представлять.
Но опять же, действительно, для составителя формочек такие знания излишни. Но как вариант, человека владеющего такими знаниями можно сразу отсекать. Работать ему в таком месте будет скучно, придумает ещё что ни будь… Как потом это разбирать если никто не рубит?
Тут надо смотреть на чём они расширяются. Вот недавно один известный банк отрицательно расширился. Пока за счёт подрядчиков, но всё же.
Имя у него интесное, пугающее
вот только есть одна проблема с этим в европе, за такую самодеятельность владельца могут лишить страховки, и вам придётся возмещать убытки.
Современный html не есть что-то такое большое.
Есть и легковесные вещи. Например, skiter, который тоже имеет кучу пользователей. И именно там, где требуется малая ресурсоёмкость.
Патерн нужный, но как его большинство реализует это ужас.
А всего-то виртуальные конструкторы в язык добавить, да генерик написать, возвращающий одиночный объект.
Смотрите с другой стороны. Майнинг не основная часть дохода.
Люди получают доход за то, что производят операции по переводу денег от одного кошелька к другому. Такие организации есть, банки и пр.
Считаем по подобию: например, систему переводов WU:
Смотрим объём переводов, доходы, цену акций; сопоставляем ...
Понял в чём проблема, алгоритм в статье не соответствует оригинальному.
В оригинале каждая нода должна соединяться с вершиной предыдущего дерева. И по сути основная часть сортировки происходит при построении.
И тогда действительно будет O(N) в лучшем случае.
в среднем - O(N * log(N)), в худшем - O(N * log(N)^ 2)
Худший случай получается из наибольшего пути по всем вершинам (log(N) + ... +1)
И что печально, проигрывает она всем подряд
Array size = 1000000
SmoothSort (Original Djikstra's algorithm)
sorted array: Compare Count= 1 999 963 Swap Count= 0
inverse array: Compare Count= 39 089 125 Swap Count= 17 049 406
randomic array: Compare Count= 53 794 331 Swap Count= 23 882 961
SmoothSort ( то что описано в статье)
sorted array: Compare Count= 8 063 084 Swap Count= 0
inverse array: Compare Count= 30 700 368 Swap Count= 12 211 388
randomic array: Compare Count= 42 651 444 Swap Count= 18 093 007
SmoothSort (то же самое, что в статье, только для 2^k-1 nums)
sorted array: Compare Count= 9 885 024 Swap Count= 0
inverse array: Compare Count= 30 822 280 Swap Count= 11 349 896
randomic array: Compare Count= 42 424 646 Swap Count= 17 071 620
HeapSort
sorted array: Compare Count= 37 692 069 Swap Count= 19 787 792
inverse array: Compare Count= 36 001 436 Swap Count= 18 333 408
randomic array: Compare Count= 36 792 726 Swap Count= 19 047 502
QuickSort
sorted array: Compare Count= 19 000 019 Swap Count= 0
inverse array: Compare Count= 19 000 036 Swap Count= 500 000
randomic array: Compare Count= 25 250 205 Swap Count= 4 911 581
так называемый Метод Фейнмана
вот здесь неплохо описывается https://dzen.ru/a/YUJHDfdhQUQLbe5a
Понекроманщу:
Поэтому, на первом этапе наилучшая сложность по времени:для почти упорядоченных данных — O(n),для рандомных данных — O(n log n).По аналогии с бинарной кучей это можно сделать за O(n).
На втором этапе наилучшая сложность по времени такая же как и на первом:для почти упорядоченных данных — O(n),для рандомных данных — O(n log n).Тут ошибка, в лучшем случае будет так же - O(n log n), просто коэффициент ниже. Перебор списка куч никуда не деть, их количество для определённого размера в среднем log2(n) / 2.
я рейтинги не ставлю, но на первый взгляд это очень неудобно читать и понимать
Если вы уж начали с матриц, то формулы можно так же в виде матриц и писать
Выводы формул и код если они большие лучше убрать в спойлеры, а на виду оставить лишь итог
С определёнными интегралами есть один фокус (по типу как в первом примере), который их решение делает на уровне применения правил Лапиталя, а не вот то решение, что приведено. И физики им вполне успешно пользуются.
Ох ты, и 1-го оказывается достаточно (спасибо ermouth)
Если вы знаете среду (или язык программирования), которые совместимы с не типизированным лямбда исчислением и позволят формализовать содержимое главы в них и проводить вычисления\проверки, то обязательно напишите об этом в комментариях.А чем типизированная не годится? Y-комбинатор просто вводится дополнительно.
Да и вроде в хаскеле довольно легко делается обвязка для интерпретации. (в учебнике была)
Тут похоже просто знание матана проверяют. Сразу 90% бездельников отсекается.
Меня больше удивляет когда по иностранным языкам экзамен проводят на технические дисциплины.
Генераторы СЧ нужно изолировать
Броня должна согласовываться с умениями (увертка, паринг, щит, количество ударов) и всё станет куда веселее. Маг явно не может бить как воин, но они должны быть равны в возможностях.
Плохо когда формулы битвы разные.
Есть мобы с чем-то ценным, есть - для прокачки.
Плохо когда хиты мобов улетают в небеса по сравнению с игроками. ПКилить становится гораздо легче чем расти. Это большинство игр превращает в «царь горы».
Групповая игра должна давать преимущества, но не оверные.
По сути, стейт-машина для выполнения асинхронного кода. Большим минусом: куча механических связок и запутывание логики, соответственно.
Для сценарного кода достаточно добавить асинхронные операции ожидания к UI.