В качестве иллюстрации - ну, сойдёт. Хотя код откровенно попахивает, - и с названиями тут странно, и с побочными эффектами.
Общая идея простая:
перебираем все кандидаты в простые числа: 2, 3, 6k±1 (если там попадутся непростые, то пофиг, мы на их делители уже проверили раньше)
при каждом совпадении делим число, заменяе его на частное от максимальной степени делителя
отсечка - квадрат кандидата-в-делители больше текущего проверяемого числа
Ключевое отличие от наивного алгоритма - там отсечкой было бы "больше исходного числа".
Ну и как это можно переписать красивее (вкусовщина, конечно, но раз уж я критикую стиль, то критикуя-предлагаю)
def gen_prime_candidates():
'''
неограниченный генератор кандидатов в простые числа
'''
# возвращаем первые несколько чисел из известного списка
known = [2, 3] # можно написать хоть до сотни, хоть до тысячи
for p in known:
yield p
# остальные, так и быть, через сито с остатком 6
plast = known[-1] # последнее простое число из списка
k6 = plast//6*6 + 1 # следующее число, кратное 6
while True:
yield k6-1
yield k6+1
k6 += 6
def find_power_and_rest_log(n, dt, t=1):
'''
вспомогательная функция нахождения степени делителя
(за логарифмическое время)
n - делимое
dt = (d**t) - делитель в степени t
t - степень
результат - (p, n')
где n = n' * d**p = n' * (d**t)**u, p = t*u
'''
if n < dt or n % dt != 0:
return 0, n # не делится
# рекурсия позволяет сделать за логарифмическое время
p, n = find_power_and_rest_log(n, dt*dt, t*2)
if n % dt == 0:
p, n = p+t, n//dt
return p, n
# на самом деле, накладные расходы на рекурсию могут оказаться больше,
# чем на тупой линейный забег (для 64-битных целых это, очевидно, не более 64)
def find_power_and_rest_lin(n, d):
'''
вспомогательная функция нахождения степени делителя
(за линейное время)
n - делимое
d - делитель
результат - (p, n')
где n = n' * d**p
'''
p = 0
while n%d == 0:
p, n = p+1, n//d
return (p, n)
find_power_and_rest = find_power_and_rest_log # или ..._lin
def gen_divisors_and_powers(n):
'''
конечный генератор списка пар (делитель, показатель степени)
'''
for d in gen_prime_candidates():
# отсечка по квадрату
if d*d > n:
break
# находим степень делителя
p, n = find_power_and_rest(n, d)
if p != 0:
yield (d, p)
# отдаём последнее
if n > 1:
yield (n, 1)
def show_divisor_and_power(d, p):
return f'{d}' if p==1 else f'{d}^{p}'
def show_divisors_and_powers(n):
'''
формирует строку вида "2^a * 3^b * ..."
'''
# почему не сразу print в цикле,
# потому что пришлось бы реализовывать логику вставки оператора
# перед вторым и последующими элементами
return ' * '.join(
show_divisor_and_power(d,p)
for (d, p) in gen_divisors_and_powers
)
def print_divisors_and_powers(n):
print(n, '=', show_divisors_and_powers(n))
Пока яндекс не раздуплился с расшариванием-слежением геолокации (а эту фичу им тоже уже много лет предлагают, кстати), - запускайте телегу или вацап и смотрите там.
Кстати, надо бы в мах написать, чтобы они тоже прикрутили туда.
О! Раз уж тут представитель живой есть. КОГДА СДЕЛАЕТЕ КРУПНЫЕ ШРИФТЫ?
Тикет про отвратительное юзабилити с нерегулируемыми мелкими шрифтами висит у вас в бэклоге ЧЕТЫРЕ ГОДА. Год назад он был всё ещё в статусе "собираем пожелания", с каким-то гигантским количеством комментариев как от сотрудников, так и от юзеров с внешнего контура. Но на свистоперделки у вас руки доходят быстро, а на то, чтобы водитель не щурился и не рассматривал карту с лупой - лапки.
Я лично говорил - ну блин, сделайте хотя бы для внутренних бетатестров настройку, запихайте в самую пучину десятого уровня менюшек, - чисто чтоб можно было проверить, будет это полезно или бесполезно. Потому что людей с дальнозоркостью, вообще-то, дофига и больше! И нет, блин, не надо советовать выкручивать системные шрифты в телефоне на максимум! Вот как раз системные выставлены комфортно. Не буду я поганить интерфейс всего телефона ради интерфейса одного приложения.
И Тигран и Кукуц это читали. И неоднократно. И всем всё похер!
Когда модель видит кучу очень похожих друг на друга местоимений PERSON_1, PERSON_2 и т.д., то не возникают ли тут 3 проблемы?
1) Модель начинает галлюцинировать - додумывать номера просто потому, что где двое, там и третий? И эти выдуманные местоимения протекают обратно в ответ и сводят фильтр с ума.
2) Модель начинает путаться между существующими номерами, хаотично подставляя их в выдачу.
3) Модель обучается на фиктивных связях, - например, для неё PERSON_1 всегда в ROLE_1, - и это перевешивает связи в конкретном запросе.
Антибот ведь, насколько я понимаю, stateless? Анализирует только каждую сессию независимо?
Ну так напрашивается точно такой же защитный слой, только уже stateful... У которого не так уж много ручек настройки: общая полоса пропускания и правила охлаждения при аномальной активности одного пользователя (вал заявок с одного адреса, вал заявок на один телефон).
Соответственно, в бизнес-бизнес-логику уже будут прилетать очищенные заявки.
И это не против единичного нервического пользователя, а против изощрённых спамеров, которые надурили первый слой антибота.
А меры на стороне бизнес-логики не предполагаются?
Если стопятьсот заявок на один номер, то сразу в топку и номер во временный бан. Пусть лучше пользователь посидит без связи, чем утонет в завале смсок.
Если несколько заявок, то обслужить последнюю, а номер в кратковременный бан (порядка минут). Мера против внезапных рефрешей и фоновых вкладок.
Ну и профилировать общий поток заявок. Если бюджет рассчитан на, условно, 24*60*60 смс в день, то обрабатывать не более 1 смс в секунду, - а если разные пользователи одномоментно накидали в одну и ту же секунду, то случайным образом решать, кому повезло, а кому придётся на клиентской стороне повторить попытку.
Опять же, негарантированная доставка с негарантированным откликом. Если сервис перегружен и стал отвергать заявки, то вовсе необязательно сообщать об этом пользователю (злоумышленнику в том числе). Просто "если смс не пришло, попытайтесь ещё раз через минуту-другую". Неважно, почему, - может, у сотового оператора затуп.
Получается, - чтобы расшарить один умный указатель между несколькими ядрами, нужно сделать сразу несколько мероприятий.
1) Разнести счётчики и данные в памяти. Чтобы бизнес-логика могла расставлять барьеры по своему усмотрению (или вовсе не расставлять), а счётчики - ну это вынужденная задача синхронизации ядер.
2) В рамках одного потока минимально заниматься размахиванием счётчиков. Получить ссылку на данные, вот с ней и работать. Иначе потоки только и будут, что тупить друг об друга.
И если в C++ можно конструировать shared_ptr из двух блоков (shared_ptr(new Data(...)) вместо make_shared<Data>(...)), то в Расте это, получается, прибито гвоздями?
Но это закроет первую проблему, но не избавит от второй.
Возможно, скажу сейчас дикую вещь, но двойная косвенность тут должна помочь.
Первичный умный указатель на данные, расшаренные между потоками. Указывает на вторичный умный указатель на данные, расшаренные строго внутри потока.
(Я не знаю раст, поэтому напишу на плюсах, что я имею в виду)
struct Item {.....};
using ItemPtr = std::shared_ptr<Item>;
struct Batch { ItemPtr pi1, pi2, .... };
using BatchPtr = std::shared_ptr<Batch>;
using BatchWeakPtr = std::weak_ptr<Batch>;
void work1(ItemPtr pi) { ..... }
void thread1(BatchWeakPtr pwb) {
while (!stop)
{
.....
// если логика слабого указателя необходима, то ничего не поделаешь
if (auto pb = pwb.lock()) {
auto pi1 = pb->pi1;
// но мы хотя бы внутри работы с данными не будем дёргать сам pb
work1(pi1);
}
.....
}
}
void work2(ItemPtr pi) { ..... }
void thread2(BatchPtr pb) {
// а если время жизни пачки гарантированно на весь поток,
// то просто взяли нужный элемент, и больше пачку как таковую не беспокоим
auto pi2 = pb->pi2;
while (!stop)
{
.....
work2(pi2);
.....
}
// только надо внимательно последить за порядком отмирания ссылок
// а то мало ли, элемент без родительской пачки останется жить
// (автоматика RAII это нам обеспечит, но можно и руками написать)
pi2.reset();
pb.reset();
}
Скрытая проводка - это плюс к эстетике и минус к любому обслуживанию и переделкам. Тем более, если вся разводка проходит не под штукатуркой или внутренней панелью, а вообще снаружи, под слоями утеплителя и обшивки. Это же вообще раз-и-навсегда.
А ещё, как это увязывается с пожарной безопасностью в деревянном доме?
Удары неупругие. Когда сзади поджимают, спереди отнюдь не ускоряются.
Может быть, конечно, можно притянуть какую-то статистическую физику. Но хз как.
Число 3 в формуле универсальной газовой постоянной означает 3 степени свободы - направления движения в пространстве для газов, у которых вращением и иными колебаниями молекул можно пренебречь.
А с автомобилями "энергия" "столкновения" превращается во внутреннюю. Водитель начинает вибрировать, но в разгон это превратится очень не сразу.
Кроме того, автомобили существенно анизотропны. Они едут преимущественно вперёд. Хотя в ЮВА, особенно мотоциклы и рикши, демонстрируют броуновское движение.
Потому что в масштабах машин и улиц это какие-то капилляры получаются! Сплошной пограничный слой.
Ну и конечно, в гидрогазодинамике кинетическая энергия частицам сообщается через звуковые и ударные волны. А у машин свои собственные источники энергии, плюс никто не хочет разгоняться посредством упругих ударов.
"Дать пешеходам..." подземно-надземные переходы, после чего благодарные пешеходы и простихоспади урбанисты съедят рационализатора с говном.
А если наоборот, подземно-надземные магистрали, то градостроители и водители сделают то же самое. И ещё жители домов, рядом с окнами которых появятся эстакады, присоединятся к празднику.
Хотя в случаях с интенсивным трафиком машин и пешеходов - разнесение потоков в 3д - лучшее из худшего. Даже одиозные краб-и-креветка на проспекте Славы в СПб.
Вот это безапелляционное предложение каких-то взятых с потолка дистрибутивов как готовых решений - полностью подрывает доверие.
Почему бабушкось - это именно какой-то yet another noname Endless. (До такой степени нонейм, что даже википедия там на пяти языках, но без английского!)
А не Mint, например?
И какой критерий бабушкоси? Чтобы ездила на старом пне? Ну возьми старый кноппикс тогда, чо уж.
Пусть бабка патчит вторые кеды по советам анимешников.
хуже деятельного дурака только дурак инициативный )))
Стиль изложения
рубленый
Маяковский освоил
ИИ
Ну уж хомяк эта команда вполне может снести безо всякого судо.
В качестве иллюстрации - ну, сойдёт. Хотя код откровенно попахивает, - и с названиями тут странно, и с побочными эффектами.
Общая идея простая:
перебираем все кандидаты в простые числа: 2, 3, 6k±1 (если там попадутся непростые, то пофиг, мы на их делители уже проверили раньше)
при каждом совпадении делим число, заменяе его на частное от максимальной степени делителя
отсечка - квадрат кандидата-в-делители больше текущего проверяемого числа
Ключевое отличие от наивного алгоритма - там отсечкой было бы "больше исходного числа".
Ну и как это можно переписать красивее (вкусовщина, конечно, но раз уж я критикую стиль, то критикуя-предлагаю)
Интерфейсы в языке го - это прямо офигеть какая простота! Это гораздо, гораздо лучше воровства. Какое-то инженерное безумие.
Пока яндекс не раздуплился с расшариванием-слежением геолокации (а эту фичу им тоже уже много лет предлагают, кстати), - запускайте телегу или вацап и смотрите там.
Кстати, надо бы в мах написать, чтобы они тоже прикрутили туда.
О! Раз уж тут представитель живой есть. КОГДА СДЕЛАЕТЕ КРУПНЫЕ ШРИФТЫ?
Тикет про отвратительное юзабилити с нерегулируемыми мелкими шрифтами висит у вас в бэклоге ЧЕТЫРЕ ГОДА. Год назад он был всё ещё в статусе "собираем пожелания", с каким-то гигантским количеством комментариев как от сотрудников, так и от юзеров с внешнего контура. Но на свистоперделки у вас руки доходят быстро, а на то, чтобы водитель не щурился и не рассматривал карту с лупой - лапки.
Я лично говорил - ну блин, сделайте хотя бы для внутренних бетатестров настройку, запихайте в самую пучину десятого уровня менюшек, - чисто чтоб можно было проверить, будет это полезно или бесполезно. Потому что людей с дальнозоркостью, вообще-то, дофига и больше! И нет, блин, не надо советовать выкручивать системные шрифты в телефоне на максимум! Вот как раз системные выставлены комфортно. Не буду я поганить интерфейс всего телефона ради интерфейса одного приложения.
И Тигран и Кукуц это читали. И неоднократно. И всем всё похер!
Когда модель видит кучу очень похожих друг на друга местоимений PERSON_1, PERSON_2 и т.д., то не возникают ли тут 3 проблемы?
1) Модель начинает галлюцинировать - додумывать номера просто потому, что где двое, там и третий? И эти выдуманные местоимения протекают обратно в ответ и сводят фильтр с ума.
2) Модель начинает путаться между существующими номерами, хаотично подставляя их в выдачу.
3) Модель обучается на фиктивных связях, - например, для неё PERSON_1 всегда в ROLE_1, - и это перевешивает связи в конкретном запросе.
Антибот ведь, насколько я понимаю, stateless? Анализирует только каждую сессию независимо?
Ну так напрашивается точно такой же защитный слой, только уже stateful... У которого не так уж много ручек настройки: общая полоса пропускания и правила охлаждения при аномальной активности одного пользователя (вал заявок с одного адреса, вал заявок на один телефон).
Соответственно, в бизнес-бизнес-логику уже будут прилетать очищенные заявки.
И это не против единичного нервического пользователя, а против изощрённых спамеров, которые надурили первый слой антибота.
А меры на стороне бизнес-логики не предполагаются?
Если стопятьсот заявок на один номер, то сразу в топку и номер во временный бан. Пусть лучше пользователь посидит без связи, чем утонет в завале смсок.
Если несколько заявок, то обслужить последнюю, а номер в кратковременный бан (порядка минут). Мера против внезапных рефрешей и фоновых вкладок.
Ну и профилировать общий поток заявок. Если бюджет рассчитан на, условно, 24*60*60 смс в день, то обрабатывать не более 1 смс в секунду, - а если разные пользователи одномоментно накидали в одну и ту же секунду, то случайным образом решать, кому повезло, а кому придётся на клиентской стороне повторить попытку.
Опять же, негарантированная доставка с негарантированным откликом. Если сервис перегружен и стал отвергать заявки, то вовсе необязательно сообщать об этом пользователю (злоумышленнику в том числе). Просто "если смс не пришло, попытайтесь ещё раз через минуту-другую". Неважно, почему, - может, у сотового оператора затуп.
Получается, - чтобы расшарить один умный указатель между несколькими ядрами, нужно сделать сразу несколько мероприятий.
1) Разнести счётчики и данные в памяти. Чтобы бизнес-логика могла расставлять барьеры по своему усмотрению (или вовсе не расставлять), а счётчики - ну это вынужденная задача синхронизации ядер.
2) В рамках одного потока минимально заниматься размахиванием счётчиков. Получить ссылку на данные, вот с ней и работать. Иначе потоки только и будут, что тупить друг об друга.
И если в C++ можно конструировать shared_ptr из двух блоков (
shared_ptr(new Data(...))вместоmake_shared<Data>(...)), то в Расте это, получается, прибито гвоздями?Но это закроет первую проблему, но не избавит от второй.
Возможно, скажу сейчас дикую вещь, но двойная косвенность тут должна помочь.
Первичный умный указатель на данные, расшаренные между потоками. Указывает на вторичный умный указатель на данные, расшаренные строго внутри потока.
(Я не знаю раст, поэтому напишу на плюсах, что я имею в виду)
Скрытая проводка - это плюс к эстетике и минус к любому обслуживанию и переделкам. Тем более, если вся разводка проходит не под штукатуркой или внутренней панелью, а вообще снаружи, под слоями утеплителя и обшивки. Это же вообще раз-и-навсегда.
А ещё, как это увязывается с пожарной безопасностью в деревянном доме?
Тогда результатом будет "BAD(((((((" или "BAD)))))))"
Удары неупругие. Когда сзади поджимают, спереди отнюдь не ускоряются.
Может быть, конечно, можно притянуть какую-то статистическую физику. Но хз как.
Число 3 в формуле универсальной газовой постоянной означает 3 степени свободы - направления движения в пространстве для газов, у которых вращением и иными колебаниями молекул можно пренебречь.
А с автомобилями "энергия" "столкновения" превращается во внутреннюю. Водитель начинает вибрировать, но в разгон это превратится очень не сразу.
Кроме того, автомобили существенно анизотропны. Они едут преимущественно вперёд. Хотя в ЮВА, особенно мотоциклы и рикши, демонстрируют броуновское движение.
Потому что в масштабах машин и улиц это какие-то капилляры получаются! Сплошной пограничный слой.
Ну и конечно, в гидрогазодинамике кинетическая энергия частицам сообщается через звуковые и ударные волны. А у машин свои собственные источники энергии, плюс никто не хочет разгоняться посредством упругих ударов.
"Дать пешеходам..." подземно-надземные переходы, после чего благодарные пешеходы и простихоспади урбанисты съедят рационализатора с говном.
А если наоборот, подземно-надземные магистрали, то градостроители и водители сделают то же самое. И ещё жители домов, рядом с окнами которых появятся эстакады, присоединятся к празднику.
Хотя в случаях с интенсивным трафиком машин и пешеходов - разнесение потоков в 3д - лучшее из худшего. Даже одиозные краб-и-креветка на проспекте Славы в СПб.
Поддержка эндлесса - это сплошные баззворды. Попробуйте хотя бы найти историю версий на их офсайте.
а я просто не стал платить за алису-ай, и даже не подозреваю, что она там бесячит...
Вот это безапелляционное предложение каких-то взятых с потолка дистрибутивов как готовых решений - полностью подрывает доверие.
Почему бабушкось - это именно какой-то yet another noname Endless. (До такой степени нонейм, что даже википедия там на пяти языках, но без английского!)
А не Mint, например?
И какой критерий бабушкоси? Чтобы ездила на старом пне? Ну возьми старый кноппикс тогда, чо уж.
Пусть бабка патчит вторые кеды по советам анимешников.
Удивительно, что запилили отдельное приложение, а не запихнули в суперапп Го.
В лесу что-то сдохло?