s
Весело там в яндексе.
Size: a a a
2021 April 04
s
Правда, не знать, за сколько сортируется массив это лол.
SP
ну как же так. ДОЛЖЕН ЗНАТЬ ЯСКОЗАЛ
TK
В посте речь про алгоритмическую сложность. Если ты эмбедом занимаешься, то обязан знать, возможно.
EG
Про алгоритмическую сложность ты должен знать примерно в любом случае
TK
Асинк тем более вручную писать надо, да хоть через прерывания
EG
Иначе ты не увидишь где-нибудь квадрат и всё внезапно начнёт тормозить
SP
блядь проблема в том что нет никакой алгоритмической сложности. вот поц дрочил дефолтдикт, ты там блядь знаешь не кидает ли он эксепшен внутри если не находит элемент? ты там знаешь как он выделяет память? ты там знаешь насколько дорогой получается интерпретация относительно одного вызова сишной сортировки?
SP
у тебя может быть o(1) настолько долго и неоптимально выполняться что o(100) будет быстрее
EG
O(100) и O(1) это одно и то же, лолTK
Вот да
SP
юзаю постоянно кроссджоины
SP
давай не будем валять дурачка и не понимать что я имел ввиду
O(n) при n=100TK
И про то, что a и b могут быть итераторами, уже было добавлено, а это не одна, две лишние аллокации и сортировки.
Но оба решения бы устроили, на самом деле, думаю.
Но оба решения бы устроили, на самом деле, думаю.
TK
Вот квадратичное неприемлемо
SP
ну если они итераторы они итераторы
SP
это например говорит что решения когда ты одно можешь скопировать или менять инплейс не катит
TK
А для итераторов проще сразу создать одну коллекцию и не заниматься сортировкой