что значит не хардкодить для поля 3х3? Для поля 3х3 есть очевидно выигрышная стратегия, для поля 10x10 и больше — она уже не вычисляется. Понятно, что подходы должны быть принципиально разные. Причем в хорошем решении для размера NxN в любом случае будет захардкожен однозначно оптимальный и выигрышный алгоритм для N<= например 5-ти, а для N>=5 какая-то эвристика.
Это не недостаток, а обычное инженерное решение. Если дан частный случай, то излишнее обобщение приводит к потере точности
копипаста, либо разработка по одному и тому же туториалу без собственной архитектуры;
Значит ли это, что вы считаете плохой идеей переиспользовать уже существующее решение и видите необходимость в написании точно такого же (причем ладно существующее решение бы противоречило некоторым требованиям, но их нет, так-что такое себе)
отлично. Но вам не кажется, что в высокоуровневом коде на языке c# не стоит опираться на специальные флаги транслятора и правила стандарта, который знаете только вы?
чтобы восстановить это, можете сделать нечто в духе 6,5 — 0,0000000001 + 0,0000000001 или что-то такое. Идея в том, что вы никогда не знаете, как числа будут округляться в памяти, с учетом того, что помимо ограничений мантисы, в языках есть внутренние оптимизации.
в целом округлять таким образом не стоит, потому-что во многих языках нет гарантии, что 6.5 — это на самом деле 6.5, а не, например 6.4999999999999 за счет погрешности округления. Ну вернее в этом случае гарантия есть, но в других может и не быть, так-что старое доброе round(x+0.0000001) работает во всех (почти) случаях
и я не говорю о каких-то хардкорных оптимизациях с построением Ахо-корасика или дирамид, но если где-то можно легко и непринужденно поднять с O(n*n) до O(n) просто использовав хэш-таблицу, вместо кучи избыточных linq, делать это автоматически (а не когда начнет подгорать) вполне полезно
ну обычно подобные недочеты лежат где-то глубоко в системе, например на ДЛ уровне, и когда от нагрузочных тестов (если даже допустить, что нагрузка была правильно оценена) время отдачи начинает просядать, то в лучшем случае приходится профилировать и находить эту ошибку (если посмотрит человек, который алгоритмы знает), либо же добавлять какое-нибудь кэширование и ждать, пока она всплывет снова.
Я не хочу сказать, что это главное, что есть в разработчике, но и забивать, делая вид, что это никогда не пригодится не стоит. Может пригодиться. Причем обязательно там, где не ждешь (и даже не в самой большой системе)
Дело не только в отсеве кандидатов. Просто часто бывает такое, что в коде есть явные алгоритмические ошибки, которые сразу же бросаются в глаза задачколюбам, но незаметны даже для людей с 15-тилетним стажем, которые являются отличными программистами, разбираются в архитектуре, патернах, чем угодно. И в итоге в месте, где должно работать за O(n) или O(log(n)) вылезает квадрат, который можно обнаружить уже только на проде или ближе к нему. Ну как обнаружить, просто все начнет валиться по тайм-ауту
но тут дело не в том, что он ограничивает другие компании и продвигает свои сервисы в ВЫДАЧЕ. Просто некоторые сервисы яндекса уже встроены в поисковик (да и в целом, яндекс уже давно не просто поисковик, там и погода висит на главной и новости и много чего еще) и по-этому пользуются ими, а не выдачей.
вообще, это сильно зависит от такого, какое дерево выстраивают данные. Если это файловая система, то скорее всего максимальная глубина сильно меньше максимальной ширины одного уровня, следовательно затраченная память (и время на ее алокацию и очистку) меньше при DFS не смотря на использование стека.
Первый поток обходит дерево начиная с корня на всю глубину по «крайне левому» пути, т.е. всегда при перемещении вглубь поворачивает налево или другими словами всегда выбирает последний дочерний узел.
Параллельно первый поток собирает все пропущенные дочерние узлы и отправляет их в очередь (либо в стек) где их забирает другой поток, очередь или стек должны реализовывать многопоточный подход, и алгоритм повторяется, подставляя на место корня только-что взятый узел.
Зачем такая сложная логика, если можно просто при переходе по dfs в детей брать потоки из какого-то ограниченного пула.
^0 как автор в статье написал, лучше бы для возведения в степень использовали.
А тут можно было бы ~0
странная идея о том, что стандарт языка должен строиться на том, что 5% его пользователей пользуются латехом, и, следовательно, он не должен латеху противоречить и должен быть похож. Особенно когда язык далеко не о математике (по сравнению с другими языками).
Ну и что ~0 что ^0 вообще интуитивно никак не намекают на то, что они делают. Лучше уж какой-то префикс типо reverse и т. д.
Компетенции современного программиста под другим углом
с учетом того, что это 153-ая статья на тему важности soft-skills и того, что обратного никто особо не декларирует, угол не такой уж и другой, а какой и обычно
я слышал легенду (действительно не уверен, что это правда), что ООП был создан, чтобы можно было понятно интерпретировать бизнес-процессы в код. Ну, чтобы объектам реального мира соответствовали объекты кода с должным уровнем асбтракции. И взаимодействовали они между собой, как объекты реального мира с должным уровнем абстракции.
Но это не точно, было бы интересно почитать на эту тему.
Директива #region #endregion позволяет указывать блоки кода, которые можно будет сворачивать в IDE.
Я видел использование этой директивы, чтобы спрятать большие строки (например GraphQL-запрос на другой сервис), чтобы остальную часть кода можно было нормально читать. Причем в идеале такие запросы вынести в отдельный класс (или XML), но в ситуации с отдельным классом все-равно имеет смысл запаковать в region, наверное
алгоритм эратосфена и «находит» число по его текущему состоянию в массиве, а т.к. в дереве его нет, то будет считаться, что оно не простое, по-этому дерево можно строить только реверсивное, и хранить там НЕ простые числа, но тогда и выигрыш по памяти будет отсутствовать (на самом деле будет использоваться даже больше памяти).
И еще довольно интересно, как по сравнению с эратосфеном будет работать простая проверка всех чисел каким-нибудь быстрым вероятностным тестом простоты (причем с учетом того, что числа небольшие, тест может быть упрощен по вычислительной сложности).
Ну, интересно не настолько, чтобы самому писать BPSW, а настолько, что если бы кто-то это сделал, то почитать
Это не недостаток, а обычное инженерное решение. Если дан частный случай, то излишнее обобщение приводит к потере точности
Значит ли это, что вы считаете плохой идеей переиспользовать уже существующее решение и видите необходимость в написании точно такого же (причем ладно существующее решение бы противоречило некоторым требованиям, но их нет, так-что такое себе)
Я не хочу сказать, что это главное, что есть в разработчике, но и забивать, делая вид, что это никогда не пригодится не стоит. Может пригодиться. Причем обязательно там, где не ждешь (и даже не в самой большой системе)
Зачем такая сложная логика, если можно просто при переходе по dfs в детей брать потоки из какого-то ограниченного пула.
странная идея о том, что стандарт языка должен строиться на том, что 5% его пользователей пользуются латехом, и, следовательно, он не должен латеху противоречить и должен быть похож. Особенно когда язык далеко не о математике (по сравнению с другими языками).
Ну и что ~0 что ^0 вообще интуитивно никак не намекают на то, что они делают. Лучше уж какой-то префикс типо reverse и т. д.
с учетом того, что это 153-ая статья на тему важности soft-skills и того, что обратного никто особо не декларирует, угол не такой уж и другой, а какой и обычно
Но это не точно, было бы интересно почитать на эту тему.
Я видел использование этой директивы, чтобы спрятать большие строки (например GraphQL-запрос на другой сервис), чтобы остальную часть кода можно было нормально читать. Причем в идеале такие запросы вынести в отдельный класс (или XML), но в ситуации с отдельным классом все-равно имеет смысл запаковать в region, наверное
И еще довольно интересно, как по сравнению с эратосфеном будет работать простая проверка всех чисел каким-нибудь быстрым вероятностным тестом простоты (причем с учетом того, что числа небольшие, тест может быть упрощен по вычислительной сложности).
Ну, интересно не настолько, чтобы самому писать BPSW, а настолько, что если бы кто-то это сделал, то почитать