И?.. Нет, вы можете специализациями задать частные случаи, но вы не можете записать общую логику, которая бы не выдавала иногда "невычислимо".
Ещё в приведённом формализме нельзя построить некоторые штуки которые хочется построить. К примеру, имея 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, а несколько лет спустя выяснилось что они устойчивы к новому методу атаки), но может играть и против (как неслучайность матриц "Стрибога" наводит людей на подозрения что они выбраны такими не из-за устойчивости, а, напротив, из-за внедрённого бэкдора).
Фундаментально, криптография - это наука об управлении доверием. Одно дело использовать библиотеку, в отношении которой вы доверяете что авторы приложили больше усилий чем можете приложить вы, и заметно другое - полагаться на таинственные рецепты, корректность которых вы в принципе не можете проверить.
Потому что обрабатывать пользовательский ввод приходится самим, коль скоро нужна уникальная логика. Да, здесь тоже есть место для проблем, и применяется то же правило: либо вы делаете всерьёз, либо полагаетесь на принцип Неуловимого Джо (возможно плюс минимальная защита от script kiddies, хотя с пришествием языковых моделей этот "минимум" тоже может оказаться чертовски высоко).
А необходимости писать свой безопасный протокол почти никогда нет, то есть узкий совет звучит как "не делайте этой ошибки на совсем уж ровном месте".
Если бы все сами работали с криптографией, то все имели бы представление о том, как верифицировать собственный протокол или какие типичные ошибки существуют.
К сожалению нет. Есть фундаментальное различие между ошибками функциональности и ошибками безопасности: первые могут быть обнаружены при обычном использовании, и обычно достаточно легко предъявить тест который демонстрирует проблему вне разумных сомнений. Вторые никак не сказываются на нормальной работе ПО (за совсем клиническими исключениями), и даже демонстрирующий уязвимость proof-of-concept вполне можно не понять или убедить себя что проблема несущественна.
Более педантичное правило звучало бы так: реализуйте безопасность всерьёз и с серьёзными затратами или не реализуйте её вовсе, потому что полумеры практически дают результат хуже чем если бы не реализовывали ничего - оно так же небезопасно, но теперь у вас есть ложные иллюзии.
Так это верно только до тех пор, пока в ВУЗе занимаются передачей знаний, а не налаживанием социальных контактов. А то вы получаете возможность "в безопасной среде тестировать интересные гипотезы", а что получает эксперт? Зарплату преподавателя и честь быть объектом тестирования?
Ещё Оруэлл писал, что для скверной прозы с политическим посылом характерна неточность, безличность и расплывчатость формулировок.
Negative long-term effects on the brain, especially in younger users.
The brain will reach full development at 25.
Эти два предложения помещены на одну панель, читателю предлагается предположить что они связаны. 25 лет наводят меня на мысль о миелинизации нервных волокон - это единственный известный мне физиологический процесс с подходящим порядком величины. Влияют ли как-либо социальные сети на этот процесс? Я не вижу никаких исследований, но был бы очень удивлён если бы это было так. Тогда при чём здесь вообще сроки развития мозга?
И?.. Нет, вы можете специализациями задать частные случаи, но вы не можете записать общую логику, которая бы не выдавала иногда "невычислимо".
Ещё в приведённом формализме нельзя построить некоторые штуки которые хочется построить. К примеру, имея
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, а несколько лет спустя выяснилось что они устойчивы к новому методу атаки), но может играть и против (как неслучайность матриц "Стрибога" наводит людей на подозрения что они выбраны такими не из-за устойчивости, а, напротив, из-за внедрённого бэкдора).Фундаментально, криптография - это наука об управлении доверием. Одно дело использовать библиотеку, в отношении которой вы доверяете что авторы приложили больше усилий чем можете приложить вы, и заметно другое - полагаться на таинственные рецепты, корректность которых вы в принципе не можете проверить.
Потому что обрабатывать пользовательский ввод приходится самим, коль скоро нужна уникальная логика. Да, здесь тоже есть место для проблем, и применяется то же правило: либо вы делаете всерьёз, либо полагаетесь на принцип Неуловимого Джо (возможно плюс минимальная защита от script kiddies, хотя с пришествием языковых моделей этот "минимум" тоже может оказаться чертовски высоко).
А необходимости писать свой безопасный протокол почти никогда нет, то есть узкий совет звучит как "не делайте этой ошибки на совсем уж ровном месте".
К сожалению нет. Есть фундаментальное различие между ошибками функциональности и ошибками безопасности: первые могут быть обнаружены при обычном использовании, и обычно достаточно легко предъявить тест который демонстрирует проблему вне разумных сомнений. Вторые никак не сказываются на нормальной работе ПО (за совсем клиническими исключениями), и даже демонстрирующий уязвимость proof-of-concept вполне можно не понять или убедить себя что проблема несущественна.
Более педантичное правило звучало бы так: реализуйте безопасность всерьёз и с серьёзными затратами или не реализуйте её вовсе, потому что полумеры практически дают результат хуже чем если бы не реализовывали ничего - оно так же небезопасно, но теперь у вас есть ложные иллюзии.
Так это верно только до тех пор, пока в ВУЗе занимаются передачей знаний, а не налаживанием социальных контактов. А то вы получаете возможность "в безопасной среде тестировать интересные гипотезы", а что получает эксперт? Зарплату преподавателя и честь быть объектом тестирования?
Ещё Оруэлл писал, что для скверной прозы с политическим посылом характерна неточность, безличность и расплывчатость формулировок.
Эти два предложения помещены на одну панель, читателю предлагается предположить что они связаны. 25 лет наводят меня на мысль о миелинизации нервных волокон - это единственный известный мне физиологический процесс с подходящим порядком величины. Влияют ли как-либо социальные сети на этот процесс? Я не вижу никаких исследований, но был бы очень удивлён если бы это было так. Тогда при чём здесь вообще сроки развития мозга?