Анекдот - меметическая единица. У него может быть авторская фабула, но та форма в которой он успешно пересказывается (и вообще то что пересказывается анекдот А вместо анекдота Б) - очень сильно функция от среды распространения. Но если вы приписываете авторство анекдотов КГБ, то с ошибкой датировки 1992 годом мы, кажется, пришли к согласию. (А обсуждать реальность и значимость "подсознательных" процессов, по-моему, чревато сваливанием в собственные подтверждающие искажения даже в среде профессиональных психологов или социологов, не то что в секции комментариев Хабра.)
с 1992 года (...) сочиняют анекдоты в которых рассказывается, что дети у нас замечательные, а всё что мы делаем руками - ужасно.
Анекдот "ну вот дети у вас хорошие", вообще-то, ещё советских времён. Не говоря уж том, что безличное "убеждают" не очень хорошо передаёт народное авторство этих шуточек.
"Эльбрус" выпускался на TSMC и имел очень хреновое отношение техпроцесса к скорости работы. Упомянутый 16С требовал 16нм, "соответствуя" 32-нм Intel. Технически, в какой-то момент лет 10 назад были сделаны маски на 90nm "Микрона" для урезанной по самые уши версии Эльбрус-2 и были торжественно выпущены какие-то образцы, но мне неизвестно об успешной сборке с ними хотя бы работающей системы вообще, не то что об оценках её производительности (и "Микрон" с тех пор так и застрял на 90нм, судя по всему у них не получается нормально запустить 65). Спекуляциям про перенос процесса на SMIC пошёл уже минимум четвёртый год, чипов оттуда никто, как понимаю, пока не видел.
Вдобавок, у "Эльбруса" нет интегрированной графики, для любой графической оболочки нужна сторонняя видеокарта (это к вопросу о "аналогичных x86 решениях"). МЦСТ явно не считает своей задачей создание таковой, тестовые стенды используют AMD.
И?.. Нет, вы можете специализациями задать частные случаи, но вы не можете записать общую логику, которая бы не выдавала иногда "невычислимо".
Ещё в приведённом формализме нельзя построить некоторые штуки которые хочется построить. К примеру, имея Set& x, нельзя построить одноэлементное множество {x}. Имея Set& x, Set& y, нельзя проверить что x есть подмножество y.
(обращаем внимание, что объединение even и odd даёт natural)
Есть проблема: несложно задать множество с функцией принадлежности "число нечётное простое". Несложно задать множество с функцией принадлежности "число представимо как сумма двух нечётных простых". Но вот что произойдёт при объединении этого множества с множеством {2}? Мы получим EvenNatural или нет?
вызывающий код не знает (и не может знать из-за инкапсуляции), что делать с исключением
Как всегда с исключением - передаёт тому кто знает. Исключение: переданное значение температуры не имеет физического смысла. Господа вызвавшие, сами разбирайтесь кто у вас там лох. Если никто из вызвавших не подумал что такое может быть (несмотря на то что в описании метода написано \throws logical_error при бессмысленных значениях), ваши проблемы. Инкапсуляция-то тут при чём? Инкапсуляция скрывает, храню я значение как градусы Цельсия, как статистическое распределение электрон-вольтов, как ссылку на аппаратный регистр, или ещё каким-нибудь интересным образом. Но исключения - часть интерфейса.
Характеристическая функция должна быть определена для всех входных множеств
"Определена" = "значение должно вычисляться предложенными операциями за конечное время"? "Должно быть доказуемо, что выполнение предложенных операций завершается за конечное время"? Что-то третье?
Множество всех подмножеств множества S:
...в общем случае не является множеством во введённых определениях: вычисление isSubset ни в какой реализации не завершается гарантированно за конечное время. К примеру, множество натуральных чётных, конечно, есть подмножество множества натуральных, но как вы реализуете isSubset, который для этого случая вернёт true?
Всë проще - работодателя вообще не должно волновать, что ты там делаешь. Главное - к нужному сроку дать нужный результат. Если работник успевает быстрее - остальное время использует по своему усмотрению.
А если не успевает? Такое ведь тоже бывает, и в этом случае (в большинстве мест) результирующие убытки не вешаются на работника.
Если мои оценки времени хорошо откалиброваны (ха-ха...), то я решаю примерно равное число задач быстрее и медленнее изначально заявленного времени. Разумно чтобы суммарно результат был бы для меня таким же, как если бы все задачи я решал ровно за заявленное время. Если я получаю приз за более быстрое выполнение, он должен уравновешиваться штрафом за более медленное.
Причина 3: архитектурно UI и выполнение запроса разнесены так, что наладить между ними дополнительную коммуникацию сообщениями с оценкой признано слишком большим геморроем.
Там где есть предсказуемо долгая задача из однородных, доступных интерфейсу шагов, прогресс-бары по-моему вполне выживают.
Сейчас у всех стоят пластиковые, и сделать деревянные, даже в историческом здании, почему-то непозволительная роскошь!
Это эффект масштаба: если деревянных окон делается мало, то каждое окно стоит дороже при равном качестве (не знаю конкретных механизмов, но могу предположить: меньшая предсказуемость сбыта, отсутствие массовых поставок "древесины для рам", что-нибудь в таком духе).
никто их С++/С синьеров досконально не изучал стандарт языка - там только текста на десяток тысяч страниц
Вот к вопросу о "привирать". Как человек у которого Draft N4659 (это ±C++17) в закладках, сообщаю что страниц там 1485 (без оглавления и алфавитного указателя).
Конфликт не обязан звучать истошным криком, количество децибел действительно сильно зависит от аудитории. Но мысль что при редактуре текста на него надо обращать внимание и заострять - довольно общая (из другого угла ту же мысль подчёркивают Олди, она звучит у Эгри в "Искусстве драматургии").
Known-plaintext attack: приведите сообщение (хотя бы 128 байт) и зашифрованное сообщение и посмотрим, получится ли у нас восстановить ключ.
(Если этот режим атаки кажется неправдоподобным, приведите первые 128 байт сообщения и зашифрованное сообщение целиком, и посмотрим, получится ли восстановить вторую половину.)
Если уж говорить о модах для Civilization IV, то есть колоссальный Realism Invictus. Изменённое дерево технологий, различия религий, мягкие ограничения на число отрядов на одном тайле (если их число превышает "уровень логистики", все отряды получают минусы, чем их больше - тем более серьёзные), эпидемии и восстания рабов...
сейчас у такой игры будет лишь статус инди проекта
Вы говорите так, будто это что-то плохое. "Инди" - это всего лишь "независимый разработчик".
Проблема с бюджетом да, есть, и большую свинью в этом подложила в своё время озвучка (затраты на неё мало зависят от размера команды разработки), но с голосовыми нейронками эта проблема сейчас должна увять.
Но Hollow Knight делался командой в пять человек. Outer Wilds - меньше десяти.
Они про разное. Brainbench - про знание некоторых правил языка в вакууме, Leetcode - про знание структур данных языка, умение быстро и правильно понимать записанные определённым образом условия и умение сообразить приличный алгоритм. Полный провал Leetcode от реального разработчика выглядит странно, полный провал Brainbench... менее странно, там довольно много про "что сделает вот этот код, глубоко неуместный в реальном проекте".
В асимметричной криптографии чуть лучше. К примеру, можно показать что если у нас есть оракул, ломающий Диффи-Хеллмана, то его можно использовать для разложения на множители произвольного числа. (Т.е., конечно, у нас нет хорошего нижнего предела для задачи факторизации, но такая гарантия всё-таки не совсем ничего.)
Это как раз спорное ограничение. Оно иногда играет на руку (как когда АНБ порекомендовало определённые матрицы AESDES, а несколько лет спустя выяснилось что они устойчивы к новому методу атаки), но может играть и против (как неслучайность матриц "Стрибога" наводит людей на подозрения что они выбраны такими не из-за устойчивости, а, напротив, из-за внедрённого бэкдора).
Фундаментально, криптография - это наука об управлении доверием. Одно дело использовать библиотеку, в отношении которой вы доверяете что авторы приложили больше усилий чем можете приложить вы, и заметно другое - полагаться на таинственные рецепты, корректность которых вы в принципе не можете проверить.
Ice-Pick Lodge (игры у них... специфичные, но "шлаком" их никак не назовёшь);
Owlcat Games (Pathfinder: Kingmaker, по-моему, одна из лучших ролевых игр в смысле "свободы выбора" вообще);
"Вангеры", "Демиурги", да хоть бы и "Эадор"...
Анекдот - меметическая единица. У него может быть авторская фабула, но та форма в которой он успешно пересказывается (и вообще то что пересказывается анекдот А вместо анекдота Б) - очень сильно функция от среды распространения.
Но если вы приписываете авторство анекдотов КГБ, то с ошибкой датировки 1992 годом мы, кажется, пришли к согласию.
(А обсуждать реальность и значимость "подсознательных" процессов, по-моему, чревато сваливанием в собственные подтверждающие искажения даже в среде профессиональных психологов или социологов, не то что в секции комментариев Хабра.)
Анекдот "ну вот дети у вас хорошие", вообще-то, ещё советских времён. Не говоря уж том, что безличное "убеждают" не очень хорошо передаёт народное авторство этих шуточек.
tl;dr - нет, и хорошо что нет.
"Эльбрус" выпускался на TSMC и имел очень хреновое отношение техпроцесса к скорости работы. Упомянутый 16С требовал 16нм, "соответствуя" 32-нм Intel. Технически, в какой-то момент лет 10 назад были сделаны маски на 90nm "Микрона" для урезанной по самые уши версии Эльбрус-2 и были торжественно выпущены какие-то образцы, но мне неизвестно об успешной сборке с ними хотя бы работающей системы вообще, не то что об оценках её производительности (и "Микрон" с тех пор так и застрял на 90нм, судя по всему у них не получается нормально запустить 65). Спекуляциям про перенос процесса на SMIC пошёл уже минимум четвёртый год, чипов оттуда никто, как понимаю, пока не видел.
Вдобавок, у "Эльбруса" нет интегрированной графики, для любой графической оболочки нужна сторонняя видеокарта (это к вопросу о "аналогичных x86 решениях"). МЦСТ явно не считает своей задачей создание таковой, тестовые стенды используют AMD.
И?.. Нет, вы можете специализациями задать частные случаи, но вы не можете записать общую логику, которая бы не выдавала иногда "невычислимо".
Ещё в приведённом формализме нельзя построить некоторые штуки которые хочется построить. К примеру, имея
Set& x, нельзя построить одноэлементное множество {x}. ИмеяSet& x, Set& y, нельзя проверить что x есть подмножество y.(обращаем внимание, что объединение even и odd даёт natural)
Есть проблема: несложно задать множество с функцией принадлежности "число нечётное простое". Несложно задать множество с функцией принадлежности "число представимо как сумма двух нечётных простых". Но вот что произойдёт при объединении этого множества с множеством {2}? Мы получим EvenNatural или нет?
Технически, потому что (там обычно кардиналы, но можно и просто с множествами):
2 = {0, {0}}; 3 = {0, {0}, {0, {0}}}
+ = {((0,0), 0), ((0,1), 1), ..., ((2,3), 5), ...}
2+3 = 5 - поскольку в + есть только одна пара вида ((2, 3), Х), и Х - 5.
(Пара тоже может быть записана как множество, например (2,3) ~ {{2, 3}, 3}.)
Как всегда с исключением - передаёт тому кто знает. Исключение: переданное значение температуры не имеет физического смысла. Господа вызвавшие, сами разбирайтесь кто у вас там лох. Если никто из вызвавших не подумал что такое может быть (несмотря на то что в описании метода написано
\throws logical_error при бессмысленных значениях), ваши проблемы. Инкапсуляция-то тут при чём? Инкапсуляция скрывает, храню я значение как градусы Цельсия, как статистическое распределение электрон-вольтов, как ссылку на аппаратный регистр, или ещё каким-нибудь интересным образом. Но исключения - часть интерфейса."Определена" = "значение должно вычисляться предложенными операциями за конечное время"? "Должно быть доказуемо, что выполнение предложенных операций завершается за конечное время"? Что-то третье?
...в общем случае не является множеством во введённых определениях: вычисление isSubset ни в какой реализации не завершается гарантированно за конечное время. К примеру, множество натуральных чётных, конечно, есть подмножество множества натуральных, но как вы реализуете isSubset, который для этого случая вернёт true?
А если не успевает? Такое ведь тоже бывает, и в этом случае (в большинстве мест) результирующие убытки не вешаются на работника.
Если мои оценки времени хорошо откалиброваны (ха-ха...), то я решаю примерно равное число задач быстрее и медленнее изначально заявленного времени. Разумно чтобы суммарно результат был бы для меня таким же, как если бы все задачи я решал ровно за заявленное время. Если я получаю приз за более быстрое выполнение, он должен уравновешиваться штрафом за более медленное.
Причина 1: на этапе дизайна здесь вообще не думали что будет существенное ожидание, поставили анимацию на всякий неожиданный случай.
Причина 2: процесс состоит из десяти разных шагов, относительная скорость которых непредсказуема (например, запрос к десяти сайтам...). "Надпись "выполнено 99%" успокаивает только первые полчаса"©.
Причина 3: архитектурно UI и выполнение запроса разнесены так, что наладить между ними дополнительную коммуникацию сообщениями с оценкой признано слишком большим геморроем.
Там где есть предсказуемо долгая задача из однородных, доступных интерфейсу шагов, прогресс-бары по-моему вполне выживают.
Это эффект масштаба: если деревянных окон делается мало, то каждое окно стоит дороже при равном качестве (не знаю конкретных механизмов, но могу предположить: меньшая предсказуемость сбыта, отсутствие массовых поставок "древесины для рам", что-нибудь в таком духе).
Вот к вопросу о "привирать". Как человек у которого Draft N4659 (это ±C++17) в закладках, сообщаю что страниц там 1485 (без оглавления и алфавитного указателя).
Конфликт не обязан звучать истошным криком, количество децибел действительно сильно зависит от аудитории. Но мысль что при редактуре текста на него надо обращать внимание и заострять - довольно общая (из другого угла ту же мысль подчёркивают Олди, она звучит у Эгри в "Искусстве драматургии").
Known-plaintext attack: приведите сообщение (хотя бы 128 байт) и зашифрованное сообщение и посмотрим, получится ли у нас восстановить ключ.
(Если этот режим атаки кажется неправдоподобным, приведите первые 128 байт сообщения и зашифрованное сообщение целиком, и посмотрим, получится ли восстановить вторую половину.)
Если уж говорить о модах для Civilization IV, то есть колоссальный Realism Invictus. Изменённое дерево технологий, различия религий, мягкие ограничения на число отрядов на одном тайле (если их число превышает "уровень логистики", все отряды получают минусы, чем их больше - тем более серьёзные), эпидемии и восстания рабов...
Ещё несколько интересных механик однострочниками.
Achron (2011) - RTS, в которой можно отправлять свои войска назад во времени.
OneShot (2016) - квест, который опирается на то что он программа с файлами в вашей файловой системе.
A Blind Legend (2016) - action, в котором на экране не видно ничего.
Эадор (2009) - стратегия, в которой действие "загрузить сохранение" имеет внутриигровые последствия (довольно неприятные).
Вы говорите так, будто это что-то плохое. "Инди" - это всего лишь "независимый разработчик".
Проблема с бюджетом да, есть, и большую свинью в этом подложила в своё время озвучка (затраты на неё мало зависят от размера команды разработки), но с голосовыми нейронками эта проблема сейчас должна увять.
Но Hollow Knight делался командой в пять человек. Outer Wilds - меньше десяти.
Они про разное. Brainbench - про знание некоторых правил языка в вакууме, Leetcode - про знание структур данных языка, умение быстро и правильно понимать записанные определённым образом условия и умение сообразить приличный алгоритм. Полный провал Leetcode от реального разработчика выглядит странно, полный провал Brainbench... менее странно, там довольно много про "что сделает вот этот код, глубоко неуместный в реальном проекте".
В асимметричной криптографии чуть лучше. К примеру, можно показать что если у нас есть оракул, ломающий Диффи-Хеллмана, то его можно использовать для разложения на множители произвольного числа. (Т.е., конечно, у нас нет хорошего нижнего предела для задачи факторизации, но такая гарантия всё-таки не совсем ничего.)
Это как раз спорное ограничение. Оно иногда играет на руку (как когда АНБ порекомендовало определённые матрицы
AESDES, а несколько лет спустя выяснилось что они устойчивы к новому методу атаки), но может играть и против (как неслучайность матриц "Стрибога" наводит людей на подозрения что они выбраны такими не из-за устойчивости, а, напротив, из-за внедрённого бэкдора).Фундаментально, криптография - это наука об управлении доверием. Одно дело использовать библиотеку, в отношении которой вы доверяете что авторы приложили больше усилий чем можете приложить вы, и заметно другое - полагаться на таинственные рецепты, корректность которых вы в принципе не можете проверить.