Есть while, значит можно и do-while сделать. С for и switch сложно, в 30 байт вряд ли влезет. Массивы тоже вряд ли. Вот return ещё можно попробовать, вероятно.
Я ради прикола попытался сократить немного код, получилось ужать его на 6 байт. Профит небольшой, конечно, но в целом там есть ещё порядка 30 байт на какие-нибудь фичи типа операторов / ! ~ break continue do-while ... чего там ещё нет? :)
Есть ещё один интересный способ. Не лучше и не хуже других. Так же, как и "вот и песенке конец". Для кого-то лучше сработает одно, для кого-то - другое.
Суть в том, чтобы укорачивать повторяемый фрагмент, начиная, например, сразу с 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-ю степень, судя по всему, сделать не получится. Вероятно, и любую другую тоже (помимо перечисленных выше, естественно).
При этом плавность оставляет желать лучшего.
Но это ещё цветочки. Иногда видосы 256-байтовых интро занимают сотни мегабайт, имея при этом артефакты компрессии.
В некотором степени интро является очень хорошо сжатым самораспаковывающимся видеофайлом :)
Разве он не органичен в данном случае?
farbrausch — это легенда :)
Если "шитый байткод", тогда это было бы "threaded bytecode", а это "байтовый шитый код", ну или см. ниже ещё вариант.
Да, вполне. Или даже ещё проще: "Байтовый шитый код", но оригинальное название рядом нужно оставить обязательно.
Есть while, значит можно и do-while сделать. С for и switch сложно, в 30 байт вряд ли влезет. Массивы тоже вряд ли. Вот return ещё можно попробовать, вероятно.
Я ради прикола попытался сократить немного код, получилось ужать его на 6 байт. Профит небольшой, конечно, но в целом там есть ещё порядка 30 байт на какие-нибудь фичи типа операторов / ! ~ break continue do-while ... чего там ещё нет? :)
Есть ещё один интересный способ. Не лучше и не хуже других. Так же, как и "вот и песенке конец". Для кого-то лучше сработает одно, для кого-то - другое.
Суть в том, чтобы укорачивать повторяемый фрагмент, начиная, например, сразу с 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 сделали по приколу.