Есть ещё один интересный способ. Не лучше и не хуже других. Так же, как и "вот и песенке конец". Для кого-то лучше сработает одно, для кого-то - другое.
Суть в том, чтобы укорачивать повторяемый фрагмент, начиная, например, сразу с 1 секунды и до тех пор, пока это не превратится в монотонный звук (монотонный - не в смысле одного чистого тона, а в смысле очень короткого фрагмента, условно говоря, длиной в 1-10 миллисекунд). Потом резко оборвать его. Вся процедура может занимать секунды 3. Если мелодия снова всплывает (обычно не сразу), повторить. И так несколько раз. Повторять можно сразу с этого монотонного звука.
В wait мы передаем заблокированный std::unique_lock, wait снимает временно блокировку и усыпает (не всегда: когда предикат в wait истинный может и не уснуть).
Подкорректирую последовательность операций.
Wait сначала проверяет предикат (если он есть), а потом уже снимает блокировку и начинает принимать уведомления, усыпляя поток. Причём, делает это фактически атомарно (т.е. между снятием блокировки и началом приёма уведомлений другой поток вклиниться не может – это тоже важно). После пробуждения устанавливает блокировку обратно (здесь тоже обычно есть оптимизация, из-за которой рекомендуют notify ставить перед unlock'ом) и снова идёт на проверку предиката.
Если предикат есть и возвращает true, никаких unlock'ов не будет.
Мысли разумные. Нет плохих инструментов (языков, фреймворков), есть неуместные/неоптимальные в данной конкретной ситуации.
Что касается обработки ошибок с очисткой, с этим отлично справляется scope_exit (класс, которого несложно реализовать и самому). И читаемость прекрасная. Правда, для этого нужен C++.
С Си, конечно, сложнее. Вспомнилась функция pthread_cleanup_push, но тут появляются лишние сущности в виде функций.
Индустрия очень активно развивается. Нужно, во-первых, идти в ногу со временем (ИИ, боты). Во-вторых, сокращать издержки (ибо конкуренция), а последствия от компромиссного инструмента юзер уж как-нибудь переживёт (а может, ещё и ТЗ написано технически не очень грамотно или бюджет мал — если говорить об аутсорсе). В-третьих, во всей этой суматохе оценить последствия не всегда просто. Или сложно сменить инструмент, если уже написано 100 тонн кода. Etc.
Вы забыли сказать, что современные проги не только тормознутые, но и безбожно жрут память (снова привет, Electron) :)
А скорость отзывчивости интерфейса (особенно на мобилах) — это вообще боль.
Вы правильно заметили, что во главе угла находятся деньги. Чат боты помогают разгрузить операторов, а значит и нанять меньше людей. Наверняка есть довольно много тех, кто задаёт откровенно нубские вопросы, и чат-боты таким помогают (это я про саппорт-ботов). Не все же гики, как мы. Но пора уже добавлять в настройки функцию "отключить бота". Ламаки эту настройку не найдут, а нам жить станет легче, и даже лояльность к бреду повысится — к бабке не ходи. Всё равно ж ВСЕ диалоги начинаются со слов "Здравствуйте. Оператор" (лично у меня, по крайней мере, а у вас?) :)
Использование Electropython'овт тоже сокращает издержки на разработку (человеко-часы). Чего стоит скорость исполнения и потребление памяти против скорости (удешевления) разработки?
Вот смысл периодически меняющегося интерфейса мне не совсем понятен. Видимо, стараются не отставать от трендов. Но зачастую "получается как всегда". Человек привыкает, что функция А находиться там, Б сям, а В - в том углу. После очередного "улучшения" интерфейса всё меняется местами, и приходится искать все фичи заново. А когда привыкаешь, грядёт новый апгрейд.
Пр поводу 100500 кнопок и настроек, ИМХО, всегда было хорошим решением — включение режима эксперта, кнопки "Расширенные настройки", настройки меню и пр. В целом Office 20xx вполне позволяет настроить интерфейс под себя. Сделать монстра, как на скрине, может каждый при желании. Но конечно, не каждая прога такое позволяет. Но опять же, больше фич (некоторые из которых — пожелания пользователей) — больше конкурентоспособность.
Собственно, мы подошли к корню проблемы — конкуренция. Если бы не было такой жёсткой конкуренции, погоня за деньгами была бы, наверное, не такой оголтелой. Ведь больше денег — больше возможности роста и уничтожения/пожирание конкурентов, возможности выделиться.
Для 1011-й степени: (0+2021)*(1+2020)*...*(1009+1012)*(1010+1011) = 2021^1011 = Prod[i=0..1010; i+(2021-i)].
Немного кода
# power 3
n = 1
for i in range(337):
n *= i*12+5
n = n ** 3
m = 1
for i in range(337):
for j in range(3):
m *= i*6+j + i*6+(5-j)
print(f'{n} == {m} ?')
print(n == m) # True
print()
# power 337
n = 1
for i in range(3):
n *= i*1348+673
n = n ** 337
m = 1
for i in range(3):
for j in range(337):
m *= i*674+j + i*674+(673-j)
print(f'{n} == {m} ?')
print(n == m) # True
print()
# power 1011
n = 2021 ** 1011
m = 1
for i in range(1011):
m *= i + 2021-i
print(f'{n} == {m} ?')
print(n == m) # True
12-ю степень, судя по всему, сделать не получится. Вероятно, и любую другую тоже (помимо перечисленных выше, естественно).
Есть такой небезызвестный товарищ, Агнер Фог, который пишет маны по оптимизации (и не только). Очень полезно к изучению: https://www.agner.org/optimize/#manuals
Есть ещё один интересный способ. Не лучше и не хуже других. Так же, как и "вот и песенке конец". Для кого-то лучше сработает одно, для кого-то - другое.
Суть в том, чтобы укорачивать повторяемый фрагмент, начиная, например, сразу с 1 секунды и до тех пор, пока это не превратится в монотонный звук (монотонный - не в смысле одного чистого тона, а в смысле очень короткого фрагмента, условно говоря, длиной в 1-10 миллисекунд). Потом резко оборвать его. Вся процедура может занимать секунды 3. Если мелодия снова всплывает (обычно не сразу), повторить. И так несколько раз. Повторять можно сразу с этого монотонного звука.
Мне вот тоже интересно, каков реальный профит будет от этого в чём?
Подкорректирую последовательность операций.
Wait сначала проверяет предикат (если он есть), а потом уже снимает блокировку и начинает принимать уведомления, усыпляя поток. Причём, делает это фактически атомарно (т.е. между снятием блокировки и началом приёма уведомлений другой поток вклиниться не может – это тоже важно). После пробуждения устанавливает блокировку обратно (здесь тоже обычно есть оптимизация, из-за которой рекомендуют notify ставить перед unlock'ом) и снова идёт на проверку предиката.
Если предикат есть и возвращает true, никаких unlock'ов не будет.
Мысли разумные. Нет плохих инструментов (языков, фреймворков), есть неуместные/неоптимальные в данной конкретной ситуации.
Что касается обработки ошибок с очисткой, с этим отлично справляется scope_exit (класс, которого несложно реализовать и самому). И читаемость прекрасная. Правда, для этого нужен C++.
С Си, конечно, сложнее. Вспомнилась функция pthread_cleanup_push, но тут появляются лишние сущности в виде функций.
Индустрия очень активно развивается. Нужно, во-первых, идти в ногу со временем (ИИ, боты). Во-вторых, сокращать издержки (ибо конкуренция), а последствия от компромиссного инструмента юзер уж как-нибудь переживёт (а может, ещё и ТЗ написано технически не очень грамотно или бюджет мал — если говорить об аутсорсе). В-третьих, во всей этой суматохе оценить последствия не всегда просто. Или сложно сменить инструмент, если уже написано 100 тонн кода. Etc.
Вы забыли сказать, что современные проги не только тормознутые, но и безбожно жрут память (снова привет, Electron) :)
А скорость отзывчивости интерфейса (особенно на мобилах) — это вообще боль.
Вы правильно заметили, что во главе угла находятся деньги. Чат боты помогают разгрузить операторов, а значит и нанять меньше людей. Наверняка есть довольно много тех, кто задаёт откровенно нубские вопросы, и чат-боты таким помогают (это я про саппорт-ботов). Не все же гики, как мы. Но пора уже добавлять в настройки функцию "отключить бота". Ламаки эту настройку не найдут, а нам жить станет легче, и даже лояльность к бреду повысится — к бабке не ходи. Всё равно ж ВСЕ диалоги начинаются со слов "Здравствуйте. Оператор" (лично у меня, по крайней мере, а у вас?) :)
Использование Electropython'овт тоже сокращает издержки на разработку (человеко-часы). Чего стоит скорость исполнения и потребление памяти против скорости (удешевления) разработки?
Вот смысл периодически меняющегося интерфейса мне не совсем понятен. Видимо, стараются не отставать от трендов. Но зачастую "получается как всегда". Человек привыкает, что функция А находиться там, Б сям, а В - в том углу. После очередного "улучшения" интерфейса всё меняется местами, и приходится искать все фичи заново. А когда привыкаешь, грядёт новый апгрейд.
Пр поводу 100500 кнопок и настроек, ИМХО, всегда было хорошим решением — включение режима эксперта, кнопки "Расширенные настройки", настройки меню и пр. В целом Office 20xx вполне позволяет настроить интерфейс под себя. Сделать монстра, как на скрине, может каждый при желании. Но конечно, не каждая прога такое позволяет. Но опять же, больше фич (некоторые из которых — пожелания пользователей) — больше конкурентоспособность.
Собственно, мы подошли к корню проблемы — конкуренция. Если бы не было такой жёсткой конкуренции, погоня за деньгами была бы, наверное, не такой оголтелой. Ведь больше денег — больше возможности роста и уничтожения/пожирание конкурентов, возможности выделиться.
Я так думаю ©
Первая степень, куб, 337-я и 1011-я степень (3 и 337 – факторизация числа 1011 – кол-ва пар).
Для первой степени (1 – это же тоже натуральное число) пары можно формировать как угодно :)
Для куба: (0+5)*(1+4)*(2+3) * (6+11)*(7+10)*(8+9) * ... * (2016+2021)*(2017+2020)*(2018+2019) = 5^3 * 17^3 * 29^3 * ... * 4025^3 * 4037^3 = (5*17*23*...*4025*4037)^3 = Prod[i=0..336; (i*12+5)]^3 ≈ 9.968728517e1068 ^ 3.
Аналогично для 337-й степени: (0+673)*(1+672)*...*(335+338)*(336+337) * (674+1347)*...*(1010+1011) * (1348+2021)*...*(1684+1685) = (673*2021*3369)^337 = Prod[i=0..2; (i*1348+673)]^337 = 4582288077^337.
Для 1011-й степени: (0+2021)*(1+2020)*...*(1009+1012)*(1010+1011) = 2021^1011 = Prod[i=0..1010; i+(2021-i)].
Немного кода
12-ю степень, судя по всему, сделать не получится. Вероятно, и любую другую тоже (помимо перечисленных выше, естественно).
Спасибо, обновил.
Ух ты, привет, дружище! Действительно, столько лет прошло!
Пара килобайт и близко не будет. Исходник "begin end." компилируется в 14Кб на Delphi7 и в 8Кб на Delphi6.
Спасибо, добавил ;)
Добавлю, пожалуй, спасибо ;)
Хотя по ссылке в конце статьи эта IDE (как и множество других) есть.
Ну это ж чел сделал просто по приколу. Так же как KolibriOS сделали по приколу.
В fasmg, к примеру, вы можете создать такой синтаксис, который позволит кодировать инструкцию нужным образом (31 C0 или 33 C0).
В x86 тоже не мало всяких gf2p8affineinvqb, ldmxcsr, mpsadbw, pclmulhqlqdq, v4fnmaddps, vfmsubadd132pd, vp4dpwssds, xgetbv... :)
upd: Ах, вон о чём речь. Вообще, некоторые процы ARM и Java-байткод понимают.
Проблема только в 64-битных Windows. И эту проверку можно отключить.
Есть такой небезызвестный товарищ, Агнер Фог, который пишет маны по оптимизации (и не только). Очень полезно к изучению: https://www.agner.org/optimize/#manuals
Делал в прошлом году измерялку скорости кода (в тактах).
Если интересно: https://gist.github.com/jin-x/88358e9bb1d58d01b7a318d0873208e3
Если есть понимание как улучшить, буду рад ;)
AI уже пишет AI... Может, стоило начать с чего-то попроще?
Скоро AI будет писать AI для написания AI. И далее уходим в бесконечную рекурсию.
Какого он(а/о/ы) пола, вероисповедания, сексуальной ориентации?