Уже, существуют приложения различных авторов для построения эпюр поперечной силы Q и изгибающего момента M, которые основаны на классическом подходе определения значений Q и M в заданном сечении балки. Я же, предлагаю строить эпюры Q и M на основе линий влияния Q и M в заданных сечениях балки, причём - многопролётной балки...
Спасибо за статью! Очень интересный подход к визуализации распределения простых чисел.
Я сам раньше много возился с простыми числами и начинал с классического ряда 2k+1 — то есть с нечётных чисел. Довольно быстро понял, что этого недостаточно. Чтобы хоть как-то подобраться к пониманию того, как простые числа распределены на самом деле, пришлось переключиться на числа, делящиеся на 2, потом на 3, потом на 4 и так далее. Постепенно, шаг за шагом.
Ведь простые числа не существуют в вакууме. Они всегда окружены числами, которые делятся на что-то ещё, кроме себя и единицы. И без анализа этой «составной среды» их природу не понять. Ваш подход со спиралями и классами вычетов по модулю 44, 710 — в каком-то смысле про то же самое: простые видны только на фоне того, что ими не является.
Вопрос автору: не пробовали ли вы строить аналогичные спирали не для самих простых чисел, а для их «расстояний до ближайшего составного»? Мне кажется, это могло бы дать дополнительный слой закономерностей.
Спасибо за подробный разбор. Тема автоматической фильтрации спама — действительно больная, особенно когда речь идёт о ложных срабатываниях (false positives). У меня схожая история, но в другой области: я разрабатываю веб-инструменты для строительной механики, и там тоже пришлось решать задачу автоматической фильтрации и классификации — правда, не писем, а расчётных схем и линий влияния.
Мне кажется, ваш подход с Google Script и регулярным запуском каждые 15 минут — очень элегантный. Особенно понравилась идея с проверкой MX и A записей для домена отправителя: простой и надёжный критерий.
Вопрос по практике: насколько агрессивно, на ваш опыт, Google относится к частым вызовам GmailApp.search() и Gmail.Users.Threads.remove()? Не возникало ли ограничений (квот) или временных блокировок при обработке, скажем, нескольких сотен писем за раз?
И ещё небольшое пожелание к статье: возможно, стоит добавить предупреждение, что при использовании метода «стирать всё, кроме белого списка TLD» на аккаунте, который получает письма с нестандартных доменов (например, .io, .ai, .tech), можно потерять легитимные письма.
В любом случае, спасибо за статью и за код в открытом доступе. Люблю, когда из практической проблемы рождается практическое решение.
Уже, существуют приложения различных авторов для построения эпюр поперечной силы Q и изгибающего момента M, которые основаны на классическом подходе определения значений Q и M в заданном сечении балки. Я же, предлагаю строить эпюры Q и M на основе линий влияния Q и M в заданных сечениях балки, причём - многопролётной балки...
Спасибо за статью! Очень интересный подход к визуализации распределения простых чисел.
Я сам раньше много возился с простыми числами и начинал с классического ряда 2k+1 — то есть с нечётных чисел. Довольно быстро понял, что этого недостаточно. Чтобы хоть как-то подобраться к пониманию того, как простые числа распределены на самом деле, пришлось переключиться на числа, делящиеся на 2, потом на 3, потом на 4 и так далее. Постепенно, шаг за шагом.
Ведь простые числа не существуют в вакууме. Они всегда окружены числами, которые делятся на что-то ещё, кроме себя и единицы. И без анализа этой «составной среды» их природу не понять. Ваш подход со спиралями и классами вычетов по модулю 44, 710 — в каком-то смысле про то же самое: простые видны только на фоне того, что ими не является.
Вопрос автору: не пробовали ли вы строить аналогичные спирали не для самих простых чисел, а для их «расстояний до ближайшего составного»? Мне кажется, это могло бы дать дополнительный слой закономерностей.
Спасибо за подробный разбор. Тема автоматической фильтрации спама — действительно больная, особенно когда речь идёт о ложных срабатываниях (false positives). У меня схожая история, но в другой области: я разрабатываю веб-инструменты для строительной механики, и там тоже пришлось решать задачу автоматической фильтрации и классификации — правда, не писем, а расчётных схем и линий влияния.
Мне кажется, ваш подход с Google Script и регулярным запуском каждые 15 минут — очень элегантный. Особенно понравилась идея с проверкой MX и A записей для домена отправителя: простой и надёжный критерий.
Вопрос по практике: насколько агрессивно, на ваш опыт, Google относится к частым вызовам GmailApp.search() и Gmail.Users.Threads.remove()? Не возникало ли ограничений (квот) или временных блокировок при обработке, скажем, нескольких сотен писем за раз?
И ещё небольшое пожелание к статье: возможно, стоит добавить предупреждение, что при использовании метода «стирать всё, кроме белого списка TLD» на аккаунте, который получает письма с нестандартных доменов (например, .io, .ai, .tech), можно потерять легитимные письма.
В любом случае, спасибо за статью и за код в открытом доступе. Люблю, когда из практической проблемы рождается практическое решение.