Интересно, что не во всех языках такая структура имеет "неэтичные" коннотации.
В немецком вполне обычен и приличен оборот "ich entschuldige mich für ...", что обозначает "извините за ...", но дословно переводилось бы как "я извиняю себя за ...".
P.S. Я бы поставил на то, что через пару десятилетий и в русском форму "извиняюсь" признают частью нормы.
Не выявилось ли эффекта влияния качества фотографий? Т. е. что нейросеть не на объективные параметры квартиры смотрит, а на чёткость и резкость фотографий, выбранный ракурс, и т. п.
Ведь при сдаче квартир с дорогим ремонтом наверняка больше заморачиваются с созданием качественных и выигрышных фотографий.
Помимо того, что отметил mayorovp, при игнорировании чётных внутренний цикл будет делать вдвое меньше итераций. Например, при вычеркивании кратных числу 3 мы будем только итерироваться по числам 9, 15, 21, и т. п., и не будем тратить нисколько времени на вычеркивание заведомо бесполезных 12, 18, 24.
Решето Эратосфена можно дальше улучшить, например, только рассматривая и храня нечётные числа - это ускоряет примерно вдвое. (Аналогично, можно было бы отсечь и кратные трём, пяти, и т. д., но это уже сделает код более муторным. Отсечение чётных же делается буквально парой изменений в границах цикла и обращениях к массивам.)
Но при ваших объёмах попробовать сделать блочное решето точно имеет смысл, потому что вместо прыжков по почти терабайтным файлам будет работа чисто в ОЗУ с периодическим сбросом результатов очередного блока на диск. Реализация там не сильно сложнее - по сути, вы сначала делаете обычное решето до 10^6, а затем идёте по блокам. Каждый блок обрабатывается почти стандартным алгоритмом, только внешний цикл идёт по предпосчитанным выше простым, а внутренний - по кратным им числам, лежащим внутри блока.
А вообще обычно ссылаются на решето Аткина как на самое быстрое. Я не знаю, как оно будет вести при вашем профиле нагрузки, так как я его самостоятельно никогда не "щупал".
Не будет ли гораздо эффективнее разбить просеиваемые числа на блоки по, скажем, миллиарду бит в каждом? Тогда мы не будем пробегать по диску много раз, да и вообще весь текущий блок будет помещаться в ОЗУ, и сбросить его на диск надо будет лишь один раз простой одноразовой записью (а вообще, не зная вашей задачи, трудно сказать, нужно ли вообще будет хранилище на диске).
Чтобы выполнить просеивание в отдельно взятом блоке, достаточно знать простые до квадратного корня из верхней границы (т. е. в вашем случае нужны будут простые до миллиона).
P.S. На всякий случай - решето Эратосфена, особенно в такой "лобовой" реализации, как в статье - не самый лучший способ поиска всех простых.
Они уже успели "подумать" и, как ни странно, по-прежнему хотят отказываться. Например, см. "В Германии решили не продлевать эксплуатацию АЭС" https://ria.ru/20220308/aes-1777166163.html. Но это Германия. Бельгия, например, несколько дней назад решила отложить закрытие АЭС на 10 лет.
Он фигурирует в многочисленных списках бестселлеров, а, например, по оценкам Book of the Month Club эта книга занимает ни много ни мало второе место по значимости для американских читателей после Библии. Это уже поразительная похвала для книги, в которой каждый герой постоянно повторяется (чуть ли не по 10 раз высказывая одни и те же идеи, немного разными словами), гамма эмоций персонажей на уровне "Анна побледнела" (привет Чехову), лирическая линия до смешного угловата, нет никаких даже намёков на самокритику по отношению к заявленной идеологической концепции или хотя бы на самоиронию, и т. п.
Простите, я не филолог, и писать литературные рецензии - совсем не моё, да и книга всё равно, конечно, стоит прочтения хотя бы из-за числа отсылок к ней. Но я её читал сразу после прочтения "Анны Карениной" (школьные попытки прочитать которую я не считаю), и на этом фоне "атлант" оставил лишь впечатление недоумения.
Соглашусь с другими комментаторами, что наверняка у подобного рода методов будет много false positive и false negative. Например:
Если задача сводится к тому, чтобы неочевидным способом применить стандартный алгоритм, то само решение может на 95% состоять из кода этого алгоритма, который выучен наизусть или (если правила позволяют) скопирован откуда-нибудь из общедоступного источника.
Если задача - это какая-нибудь хитрая комбинаторика, в которой надо долго корпеть над бумажкой и получить какую-нибудь простую формулу, реализация которой будет занимать лишь несколько строк кода.
Наконец, мне кажется, если люди активно занимаются командным олимпиадным программированием в фиксированной команде, то у их стили программирования начинают сближаться - иногда до смешения.
Мне кажется, более перспективным направлением был бы сравнительный анализ по нескольким решениям, т. е. реализация критерия "участник X реализовал все задачи в одном стиле A, а одну задачу реализовал в совершенно непохожем стиле B". И то, здесь надо быть осторожным, потому что, может быть, этот "непохожий стиль" - какой-нибудь развесистый стандартный алгоритм, выученный или скопированный из общедоступного источника.
Целочисленное переполнение без понятного вектора атаки - как-то слабовато. Как правило, большинство переполнений безобидны (приведут к некорректной работе, но не взлому); исключения бывают, но редки.
На мой взгляд, при целенаправленном поиске уязвимостей надо включать только ASan, но не UBSan. Отчёты последнего разгребать тоже можно, но скорее только когда слишком много свободного времени...
Интересно, как с технической точки зрения база Oracle, как утверждается, умеет автоматически выбирать оптимальную схему хранения. Ведь она же не может преодолеть физические ограничения диска, однако тем не менее, как я понял из статьи, она по умолчанию обгоняет Postgresql?
В статье упоминается разделение Oracle'ом хранения на несколько файлов, но ведь на физическом уровне это не должно улучшать ни пропусную способность, ни задержку? И ещё интересно, как вообще оптимизации работают в Oracle - это какие-то адаптивные эвристики, которые переключают разные стратегии в зависимости от профиля нагрузки?
Я бы ослабил утверждение статьи - дело не в правильном или неправильном подходах, а в поиске баланса между стоимостью поддержки и потенциальным риском.
Если E2E-тесты покрывают только базовые сценарии, то рано или поздно что-нибудь "взорвётся" в других сценариях. Наличие юнит-тестов от этого не застрахует, т. к. обязательно возникнет какой-нибудь неучтённый особый случай (как правило - что-нибудь нестандартное на стыке разных компонент системы).
Поэтому смысл в "избыточных" (в терминах статьи) E2E-тестах всё равно есть. Но, конечно, до тех пор, пока в компании/команде хватает ресурсов на их написание и поддержку.
А как подбирались коэффициенты "+2 к штрафу" и "+5 к штрафу"? Есть ли контрпримеры? (Длинные слова, в которых алгоритм ошибочно переставляет ударение?)
Я согласен, что свобода слова - очень тонкий вопрос, и я совсем не сторонник полной и неограниченной свободы. Не хочется разводить здесь флейма на тему того, где проходит "правильная" граница, потому что есть тысячи аргументов за и против.
Но мне здесь был любопытен наглядный пример того, что называют "фреймингом": пока технология X применяется в стране политического оппонента и против него, мы будем расхваливать её положительные стороны и радоваться большей свободе слова; как только же технология X начинает применяться в собственной стране и против её текущей политической повестки, мы примемся твердить об отрицательных сторонах чрезмерной свободы слова.
P.S. Это особенно забавно в свете того, что все жители Германии регулярно отчехляют не-пренебрежимо-малую сумму денег на содержание СМИ (условный такой доп. налог), что обычно оправдывается в первую очередь тем, что так можно достичь политической независимости и объективности СМИ. Что на самом деле, как видно, на практике не работает.
Понятно, что это была ирония, но для тех, кто не в теме - да, в Германии тоже вполне случается так, что перед выборами обещают одно, а после делают ровно наоборот.
Например, CDU (христианско-демократический союз - до конца 2021 г. правящая партия) неоднократно заявляла: "нет Upload-фильтру!" (по-простому говоря, это об очередном завинчивании гаек на тему нежелательного контента). В том числе на их собственном сайте можно найти статью от 2019 г. с этим лозунгом. Однако в начале 2021 г. они провели закон, которые эти самые Upload-фильтры в полном объёме и вводит.
P.S. Пытаясь "замести следы", они было удалили эту статью со своего сайта год назад. После того как их на этом поймали, статью вернули, с припиской наверху "извините! но мы не смогли в полной мере осуществить описанную ниже программу".
На самом деле очень забавно отслеживать, как радикально в немецких СМИ поменялся образ Телеграма.
Пару лет назад, когда было активное противостояние с Роскомнадзором, в немецких СМИ буквально превозносили Телеграм и Дурова, почитая его за "впечатляющего борца за свободу и права граждан" и с сентенциями в духе "к счастью, у антиправительственных активистов в России есть помощь - в виде компьютерной программы Телеграм" (это буквальные слова - т. е. это мой перевод цитат из популярной газеты Welt). Теперь же, когда сотни тысяч и миллионы немцев стали выходить на антиправительственные демонстрации, в том числе самоорганизуясь с использованием Телеграма, все вдруг стали писать об изобилии в нём нелегального контента, о том, что его любят террористы, и т. п. (в том числе так стали писать в том же самом Welt).
Влияет ли расположение чипа на качество приёма сигнала? Или чем объяснить то, что одни телефоны определяют положение катастрофически хуже других?
Интересно, что не во всех языках такая структура имеет "неэтичные" коннотации.
В немецком вполне обычен и приличен оборот "ich entschuldige mich für ...", что обозначает "извините за ...", но дословно переводилось бы как "я извиняю себя за ...".
P.S. Я бы поставил на то, что через пару десятилетий и в русском форму "извиняюсь" признают частью нормы.
Не выявилось ли эффекта влияния качества фотографий? Т. е. что нейросеть не на объективные параметры квартиры смотрит, а на чёткость и резкость фотографий, выбранный ракурс, и т. п.
Ведь при сдаче квартир с дорогим ремонтом наверняка больше заморачиваются с созданием качественных и выигрышных фотографий.
Помимо того, что отметил mayorovp, при игнорировании чётных внутренний цикл будет делать вдвое меньше итераций. Например, при вычеркивании кратных числу 3 мы будем только итерироваться по числам 9, 15, 21, и т. п., и не будем тратить нисколько времени на вычеркивание заведомо бесполезных 12, 18, 24.
Решето Эратосфена можно дальше улучшить, например, только рассматривая и храня нечётные числа - это ускоряет примерно вдвое. (Аналогично, можно было бы отсечь и кратные трём, пяти, и т. д., но это уже сделает код более муторным. Отсечение чётных же делается буквально парой изменений в границах цикла и обращениях к массивам.)
Также есть модификации этого решета, которые совершают лишь линейное число модификаций: http://e-maxx.ru/algo/prime_sieve_linear.
Но при ваших объёмах попробовать сделать блочное решето точно имеет смысл, потому что вместо прыжков по почти терабайтным файлам будет работа чисто в ОЗУ с периодическим сбросом результатов очередного блока на диск. Реализация там не сильно сложнее - по сути, вы сначала делаете обычное решето до 10^6, а затем идёте по блокам. Каждый блок обрабатывается почти стандартным алгоритмом, только внешний цикл идёт по предпосчитанным выше простым, а внутренний - по кратным им числам, лежащим внутри блока.
А вообще обычно ссылаются на решето Аткина как на самое быстрое. Я не знаю, как оно будет вести при вашем профиле нагрузки, так как я его самостоятельно никогда не "щупал".
Не будет ли гораздо эффективнее разбить просеиваемые числа на блоки по, скажем, миллиарду бит в каждом? Тогда мы не будем пробегать по диску много раз, да и вообще весь текущий блок будет помещаться в ОЗУ, и сбросить его на диск надо будет лишь один раз простой одноразовой записью (а вообще, не зная вашей задачи, трудно сказать, нужно ли вообще будет хранилище на диске).
Чтобы выполнить просеивание в отдельно взятом блоке, достаточно знать простые до квадратного корня из верхней границы (т. е. в вашем случае нужны будут простые до миллиона).
P.S. На всякий случай - решето Эратосфена, особенно в такой "лобовой" реализации, как в статье - не самый лучший способ поиска всех простых.
Они уже успели "подумать" и, как ни странно, по-прежнему хотят отказываться. Например, см. "В Германии решили не продлевать эксплуатацию АЭС" https://ria.ru/20220308/aes-1777166163.html. Но это Германия. Бельгия, например, несколько дней назад решила отложить закрытие АЭС на 10 лет.
@Obsolete1989 Спасибо! Жалко только, что эту информацию нельзя вынести в шапку статьи, чтобы степень "диванности" этой аналитики была сразу понятна.
Он фигурирует в многочисленных списках бестселлеров, а, например, по оценкам Book of the Month Club эта книга занимает ни много ни мало второе место по значимости для американских читателей после Библии. Это уже поразительная похвала для книги, в которой каждый герой постоянно повторяется (чуть ли не по 10 раз высказывая одни и те же идеи, немного разными словами), гамма эмоций персонажей на уровне "Анна побледнела" (привет Чехову), лирическая линия до смешного угловата, нет никаких даже намёков на самокритику по отношению к заявленной идеологической концепции или хотя бы на самоиронию, и т. п.
Простите, я не филолог, и писать литературные рецензии - совсем не моё, да и книга всё равно, конечно, стоит прочтения хотя бы из-за числа отсылок к ней. Но я её читал сразу после прочтения "Анны Карениной" (школьные попытки прочитать которую я не считаю), и на этом фоне "атлант" оставил лишь впечатление недоумения.
Довольно скучная и однобокая книга; на мой взгляд - это атлант разрекламированной пустышки... Вот Ремарк или Кафка не теряют актуальности.
Соглашусь с другими комментаторами, что наверняка у подобного рода методов будет много false positive и false negative. Например:
Если задача сводится к тому, чтобы неочевидным способом применить стандартный алгоритм, то само решение может на 95% состоять из кода этого алгоритма, который выучен наизусть или (если правила позволяют) скопирован откуда-нибудь из общедоступного источника.
Если задача - это какая-нибудь хитрая комбинаторика, в которой надо долго корпеть над бумажкой и получить какую-нибудь простую формулу, реализация которой будет занимать лишь несколько строк кода.
Наконец, мне кажется, если люди активно занимаются командным олимпиадным программированием в фиксированной команде, то у их стили программирования начинают сближаться - иногда до смешения.
Мне кажется, более перспективным направлением был бы сравнительный анализ по нескольким решениям, т. е. реализация критерия "участник X реализовал все задачи в одном стиле A, а одну задачу реализовал в совершенно непохожем стиле B". И то, здесь надо быть осторожным, потому что, может быть, этот "непохожий стиль" - какой-нибудь развесистый стандартный алгоритм, выученный или скопированный из общедоступного источника.
Chrome? :) Там можно и подзаработать: https://bughunters.google.com/about/rules/5745167867576320 .
Ну либо драйверы всякие. Там обычно много чего находится (правда, многое на практике маловероятно при условии корректно работающего железа).
Целочисленное переполнение без понятного вектора атаки - как-то слабовато. Как правило, большинство переполнений безобидны (приведут к некорректной работе, но не взлому); исключения бывают, но редки.
На мой взгляд, при целенаправленном поиске уязвимостей надо включать только ASan, но не UBSan. Отчёты последнего разгребать тоже можно, но скорее только когда слишком много свободного времени...
Интересно, как с технической точки зрения база Oracle, как утверждается, умеет автоматически выбирать оптимальную схему хранения. Ведь она же не может преодолеть физические ограничения диска, однако тем не менее, как я понял из статьи, она по умолчанию обгоняет Postgresql?
В статье упоминается разделение Oracle'ом хранения на несколько файлов, но ведь на физическом уровне это не должно улучшать ни пропусную способность, ни задержку? И ещё интересно, как вообще оптимизации работают в Oracle - это какие-то адаптивные эвристики, которые переключают разные стратегии в зависимости от профиля нагрузки?
Я бы ослабил утверждение статьи - дело не в правильном или неправильном подходах, а в поиске баланса между стоимостью поддержки и потенциальным риском.
Если E2E-тесты покрывают только базовые сценарии, то рано или поздно что-нибудь "взорвётся" в других сценариях. Наличие юнит-тестов от этого не застрахует, т. к. обязательно возникнет какой-нибудь неучтённый особый случай (как правило - что-нибудь нестандартное на стыке разных компонент системы).
Поэтому смысл в "избыточных" (в терминах статьи) E2E-тестах всё равно есть. Но, конечно, до тех пор, пока в компании/команде хватает ресурсов на их написание и поддержку.
А как подбирались коэффициенты "+2 к штрафу" и "+5 к штрафу"? Есть ли контрпримеры? (Длинные слова, в которых алгоритм ошибочно переставляет ударение?)
Но ведь слова "зЕленый" же нет?
Я согласен, что свобода слова - очень тонкий вопрос, и я совсем не сторонник полной и неограниченной свободы. Не хочется разводить здесь флейма на тему того, где проходит "правильная" граница, потому что есть тысячи аргументов за и против.
Но мне здесь был любопытен наглядный пример того, что называют "фреймингом": пока технология X применяется в стране политического оппонента и против него, мы будем расхваливать её положительные стороны и радоваться большей свободе слова; как только же технология X начинает применяться в собственной стране и против её текущей политической повестки, мы примемся твердить об отрицательных сторонах чрезмерной свободы слова.
P.S. Это особенно забавно в свете того, что все жители Германии регулярно отчехляют не-пренебрежимо-малую сумму денег на содержание СМИ (условный такой доп. налог), что обычно оправдывается в первую очередь тем, что так можно достичь политической независимости и объективности СМИ. Что на самом деле, как видно, на практике не работает.
Понятно, что это была ирония, но для тех, кто не в теме - да, в Германии тоже вполне случается так, что перед выборами обещают одно, а после делают ровно наоборот.
Например, CDU (христианско-демократический союз - до конца 2021 г. правящая партия) неоднократно заявляла: "нет Upload-фильтру!" (по-простому говоря, это об очередном завинчивании гаек на тему нежелательного контента). В том числе на их собственном сайте можно найти статью от 2019 г. с этим лозунгом. Однако в начале 2021 г. они провели закон, которые эти самые Upload-фильтры в полном объёме и вводит.
P.S. Пытаясь "замести следы", они было удалили эту статью со своего сайта год назад. После того как их на этом поймали, статью вернули, с припиской наверху "извините! но мы не смогли в полной мере осуществить описанную ниже программу".
На самом деле очень забавно отслеживать, как радикально в немецких СМИ поменялся образ Телеграма.
Пару лет назад, когда было активное противостояние с Роскомнадзором, в немецких СМИ буквально превозносили Телеграм и Дурова, почитая его за "впечатляющего борца за свободу и права граждан" и с сентенциями в духе "к счастью, у антиправительственных активистов в России есть помощь - в виде компьютерной программы Телеграм" (это буквальные слова - т. е. это мой перевод цитат из популярной газеты Welt). Теперь же, когда сотни тысяч и миллионы немцев стали выходить на антиправительственные демонстрации, в том числе самоорганизуясь с использованием Телеграма, все вдруг стали писать об изобилии в нём нелегального контента, о том, что его любят террористы, и т. п. (в том числе так стали писать в том же самом Welt).
Вот и блокировки теперь подтянулись...