Пополнение счета будет считаться присутствием в сети? А нахождение в роуминге при этом? Есть много вопросов по этой ситуации. Уведомлять как то будут что отключат?
Как автор писал и тем более отлаживал такие глубоко вложенные SQL запросы? Слабо верится что автор напрямую писал на каждый метод таких вложенные простыни кода.
Эти огромные SQL запросы можно же разбить на подзапросы? Я думаю автор писал и отлаживал отдельные подзапросы и использовал какую то программу, которая потом заменила вызовы подзапросов их телами. Простыни запросов автора выглядят нереальными для понимания и отладки.
Если писал отдельными подзапросами, то зачем в итоге объединил в одну простыню? Сервер не может работать с подзапросами? Или для оптимизации?
Я ваши желания понимаю, но вы попробуйте у себя на работе им последовать, мне будет интересно насколько быстро вас выставят на мороз или насколько быстро ваш продукт обойдут конкуренты. Для меня критерием является выбор покупателей, и конкуренция на рынке, за что покупатели платят деньги, а не о чем они просто мечтают и рассуждают, при этом многие их них не написали ни строчки кода.
Соглашусь с вами, я неверно посчитал... Надо же брать не среднюю длину слова, а длину максимального (длина прыжка), тогда да раз в 10-15 и более вполне возможна разница. Что-то я поспешил с расчётами.
Чтение из БД настолько медленнее чем обработка строк в памяти что тут вообще нет смысла обсуждать. Я хоть за нулевое время буду делать обработку строк, в итоге это уменьшит общие затраты на пару процентов максимум.
Это может быть важно в каких то сетевых протоколах, да там есть много мест для тонкой оптимизации. Там её и пременяют, тут я спорить не буду.
Если вы будете в реальности то большие данные не из воздуха берутся, и там уже будет буферное чтение и чтение по словам по токенам и голого чтения по памяти у вас просто не будет... И следовательно вы и не сможете этот алгоритм применить.
Давайте посчитаем насколько Jump может быть быстрее. Средняя длина слова я думаю 5-7 букв от языка зависит, на английском думаю в районе 5, значит в 5 раз в теории. В реальности последовательный перебор имет несколько меньше затрат, поэтому процентов на 20% быстрее остаётся примерно в 4-5 раз на практике. И это только если требования не изменятся, как только они усложнятся будет ещё меньше разница. Если вы хотите быстро, то такие расчёты выполняются раз и результат сохраняют. Вся работа по чтению и сохранению данных намного дольше чем сам алгоритм, итоговая разница десятки процентов максимум. Ну и зачем тогда, если на бизнес это не повлияет.
То что есть критические места для бизнеса я не спорю. Архитектура системы намного более тут критична чем супер оптимизация конкретного алгоритма, если она всего в 4-5 раз лучше, но с накладными расходами максимум 10-20%. А может и вообще меньше процента вносить в итоговый результат.
Это предложение не совсем универсальное, дело в тонкостях реализации метода Distinct. Вообще говоря он не гарантирует что порядок сохранится. Это актуально если работать с базами данных, там порядок может изменится. Его реализация для работы в памятью сохраняет порядок. К тому же если предикат отсеивает много элементов, то его лучше поднять выше сортировки.
У вас нигде в статье не написано что НЕ надо писать реализации типа Jump вот в чем моё уточнение. Либо если вы такое написали, то очень незаметно или неявно.
Я же, как и автор второй статьи прямо говорим что надо писать простые и эффективные (пусть и не самые эффективные алгоритмы) и знание стандартной библиотеки это сильно упрощает. Стремление к максимальной эффективности частного алгоритма зло в подавляющем большинстве случаев.
@Zara6502мне кажется вы не правы, в том плане что как раз в вашей статье все внимание уделено узко специализированному алгоритму. А его даже не надо было делать. Нужно было просто убрать неоптимальные моменты метода Split и всё. И это просто сделать. Т.е. нужно было сделать быстрый алгоритм ленивого перечисления слов в строке и всё. Ленивое перечисление это ключевой момент, так так позволяет избавится от большого потребления памяти. Дальше можно легко выполнять любую необходимую обработку слов. Да он будет в 2-5 раз дольше работать для частного случая, но его можно будет легко менять под большинство требований.
Риск купить украденный телефон среди активированных очень минимален. Там закупаются большие партии телефонов, которыми никто не пользовался, просто была выполнена подготовка (активация, перепрошивка) для продажи в России. Нет массовой кражи новых телефонов в Китае, и других странах, откуда эти телефоны поставляют. Есть риск получить прошивку с какими то скрытыми внедрениями, но и он минимален, обычно там меняется китайская прошивка на стандартную международную, которая имеет русский язык и не привязана к китайским сервисам.
Полностью поддерживаю автора, по концепции, не люблю я писать сложные алгоритмы которые тяжело поддерживать при изменении требований. Лучше написать простую и достаточно эффективную реализацию, которая пусть даже в 5-10 раз медленнее, но которую легко менять под изменения. Грубо говоря я бы сделал алгоритм который бы быстро и лениво возвращал следующее слово без учёта всяких других требований. А вот вокруг него уже можно натянуть какие хочешь требования бизнеса. Да конкретно для поиска самого длинного слова он будет примерно в 3 раза медленнее, но если требования будут меняться, добавляться, его поддерживать буде раз в 100 быстрее. А это важнее...
Насчёт конкретной реализации я думаю что у автора не самая удачная. Можно лучше и проще.
Уже из вашего ответа следует что 765 можно закодировать в 10 двоичных бит.
Есть альтернатива https://ru.wikipedia.org/wiki/Tox где идентификатор ты создаёшь сам. Повторить его без секретного ключа тяжело.
Т.е. достаточно СМС отправить, спасибо!
Пополнение счета будет считаться присутствием в сети? А нахождение в роуминге при этом? Есть много вопросов по этой ситуации. Уведомлять как то будут что отключат?
Через 50 лет во многих странах такую работу будут выполнять автономные/полуавтономные роботы. Зачем там нужно будет тело человека?
Сначала они заменять нам тело, а затем заменят нам мозги? Ой погоди... Это же уже происходит! Причём одновременно ???
Теперь я знаю зачем надо учить Питон, чтобы охотится за его инвазивными экземплярами.
Несколько чисто риторических вопросов...
Как автор писал и тем более отлаживал такие глубоко вложенные SQL запросы? Слабо верится что автор напрямую писал на каждый метод таких вложенные простыни кода.
Эти огромные SQL запросы можно же разбить на подзапросы? Я думаю автор писал и отлаживал отдельные подзапросы и использовал какую то программу, которая потом заменила вызовы подзапросов их телами. Простыни запросов автора выглядят нереальными для понимания и отладки.
Если писал отдельными подзапросами, то зачем в итоге объединил в одну простыню? Сервер не может работать с подзапросами? Или для оптимизации?
Я ваши желания понимаю, но вы попробуйте у себя на работе им последовать, мне будет интересно насколько быстро вас выставят на мороз или насколько быстро ваш продукт обойдут конкуренты. Для меня критерием является выбор покупателей, и конкуренция на рынке, за что покупатели платят деньги, а не о чем они просто мечтают и рассуждают, при этом многие их них не написали ни строчки кода.
Соглашусь с вами, я неверно посчитал... Надо же брать не среднюю длину слова, а длину максимального (длина прыжка), тогда да раз в 10-15 и более вполне возможна разница. Что-то я поспешил с расчётами.
Чтение из БД настолько медленнее чем обработка строк в памяти что тут вообще нет смысла обсуждать. Я хоть за нулевое время буду делать обработку строк, в итоге это уменьшит общие затраты на пару процентов максимум.
Это может быть важно в каких то сетевых протоколах, да там есть много мест для тонкой оптимизации. Там её и пременяют, тут я спорить не буду.
Если вы будете в реальности то большие данные не из воздуха берутся, и там уже будет буферное чтение и чтение по словам по токенам и голого чтения по памяти у вас просто не будет... И следовательно вы и не сможете этот алгоритм применить.
Давайте посчитаем насколько Jump может быть быстрее. Средняя длина слова я думаю 5-7 букв от языка зависит, на английском думаю в районе 5, значит в 5 раз в теории.
В реальности последовательный перебор имет несколько меньше затрат, поэтому процентов на 20% быстрее остаётся примерно в 4-5 раз на практике.
И это только если требования не изменятся, как только они усложнятся будет ещё меньше разница.
Если вы хотите быстро, то такие расчёты выполняются раз и результат сохраняют. Вся работа по чтению и сохранению данных намного дольше чем сам алгоритм, итоговая разница десятки процентов максимум. Ну и зачем тогда, если на бизнес это не повлияет.
То что есть критические места для бизнеса я не спорю. Архитектура системы намного более тут критична чем супер оптимизация конкретного алгоритма, если она всего в 4-5 раз лучше, но с накладными расходами максимум 10-20%. А может и вообще меньше процента вносить в итоговый результат.
Это предложение не совсем универсальное, дело в тонкостях реализации метода
Distinct. Вообще говоря он не гарантирует что порядок сохранится. Это актуально если работать с базами данных, там порядок может изменится. Его реализация для работы в памятью сохраняет порядок. К тому же если предикат отсеивает много элементов, то его лучше поднять выше сортировки.У вас нигде в статье не написано что НЕ надо писать реализации типа Jump вот в чем моё уточнение. Либо если вы такое написали, то очень незаметно или неявно.
Я же, как и автор второй статьи прямо говорим что надо писать простые и эффективные (пусть и не самые эффективные алгоритмы) и знание стандартной библиотеки это сильно упрощает. Стремление к максимальной эффективности частного алгоритма зло в подавляющем большинстве случаев.
@Zara6502мне кажется вы не правы, в том плане что как раз в вашей статье все внимание уделено узко специализированному алгоритму. А его даже не надо было делать. Нужно было просто убрать неоптимальные моменты метода Split и всё. И это просто сделать. Т.е. нужно было сделать быстрый алгоритм ленивого перечисления слов в строке и всё. Ленивое перечисление это ключевой момент, так так позволяет избавится от большого потребления памяти. Дальше можно легко выполнять любую необходимую обработку слов. Да он будет в 2-5 раз дольше работать для частного случая, но его можно будет легко менять под большинство требований.
Я не нашёл у `ReadOnlyMemory` метода SplitAny с одним параметром, похоже вы его сами написали?
Риск купить украденный телефон среди активированных очень минимален. Там закупаются большие партии телефонов, которыми никто не пользовался, просто была выполнена подготовка (активация, перепрошивка) для продажи в России. Нет массовой кражи новых телефонов в Китае, и других странах, откуда эти телефоны поставляют. Есть риск получить прошивку с какими то скрытыми внедрениями, но и он минимален, обычно там меняется китайская прошивка на стандартную международную, которая имеет русский язык и не привязана к китайским сервисам.
Полностью поддерживаю автора, по концепции, не люблю я писать сложные алгоритмы которые тяжело поддерживать при изменении требований.
Лучше написать простую и достаточно эффективную реализацию, которая пусть даже в 5-10 раз медленнее, но которую легко менять под изменения.
Грубо говоря я бы сделал алгоритм который бы быстро и лениво возвращал следующее слово без учёта всяких других требований.
А вот вокруг него уже можно натянуть какие хочешь требования бизнеса. Да конкретно для поиска самого длинного слова он будет примерно в 3 раза медленнее, но если требования будут меняться, добавляться, его поддерживать буде раз в 100 быстрее. А это важнее...
Насчёт конкретной реализации я думаю что у автора не самая удачная. Можно лучше и проще.
Да обновил до версии UPD3, видать невнимательно скопировал.
Этот вариант не проходит тесты, к сожалению. Jump return 15 should 14
Он возращает что самое длинное слово имеет длину 15, по моим расчётам должна быть 14.
Я использую такую регулярку для проверки.