Если вы хотели показать что-де существуют ситуации, когда правильный ответ по-прежнему совершенно недвусмысленный, но вот ваши эвристики проверки этого ответа могут дать сбой, то даю обратную связь: эту идею из текста лично я не считываю. Вместо этого я читаю нечто вроде "есть правила "для ЕГЭ", а вот если разбираться как на самом деле и делать разные проверки, то уже не так и бесспорно что 0 - чётное".
Неотнесение нуля к нечётным, не делает его чётным.
Если честно, я плохо понимаю - то ли вы действительно не видите подлежащих строгих форм используемых утверждений, то ли намеренно стараетесь не понять сказанного, то ли что-то третье.
Если первое, то (∀n∈N (∃ k∈N n=2k → ¬A(n))) → ¬A(0). (N - множество конечных кардиналов, включающее Card(∅) = 0.)
Я даже хотел взять какой-нибудь учебник по алгебре вместо Вики, но на его страницу затруднительно дать ссылку. My bad. Вики (как и любая энциклопедия) полезна чтобы подсмотреть одно определение в области которую вы в целом знаете, но не чтобы выучить что-то с нуля.
Есть целые числа, Z. (Можно ограничится только натуральными, N.)
Мы договорились для a,b ∈ Z, b≠0 под фразой "a делится на b" понимать "∃ k ∈ Z : a = k*b". Мы договорились под фразой "a - чётное" понимать "a делится на 2". Мы договорились под фразой "a - нечётное" понимать "неверно что a делится на 2"
Из этого определения следуют свойства, вроде того что x*y делится на b если и только если x делится на b либо y делится на b. Или что a делится на 5 если его десятичная запись заканчивается на 5. Или что сумма двух равных друг другу чисел всегда чётная.
Если у вас на руках число n, и вы хотите понять, чётное ли оно, вам необходимо и достаточно показать соответствие определению. В данном случае n=0 это тривиально: "∃ k=0 ∈ Z : n = k*2". Всё.
Вы можете вместо прямого определения использовать какие-то ранее доказанные свойства (к примеру, заметить что 0 = 0+0), но следует соблюдать минимальную аккуратность - скажем, десятичная запись числа 30 не заканчивается на 5, но 30, тем не менее, делится на 5: "∃ k=6 ∈ Z : 30 = k*5". То что конкретное свойство не помогло вам ответить на вопрос о соответствии определению - не признак какой-то глубокой истины, это просто означает что вы выбрали неудачное для вашей задачи свойство.
какой смысл ничего делить на 2 или любое другое число
Например для отслеживания инвариантов. Если я могу доказать что в некоторой ситуации утверждение A(n) верно только если n нечётное, то я автоматом знаю что A(0) неверно.
Здесь, конечно, существенно что "чётность" - эмпирически полезное понятие, которое умеет возникать в самых разных задачах. Никто не мешает мне изобрести свойство "ц-чётность", такое что 2, 4, 6, ... - ц-чётные, а 0 - нет, но засада в том, что на практике я намного чаще смогу получить результат вроде "A(n) верно только если n нечётное", чем "A(n) верно только если n не-ц-чётное".
Значит "та расшифровка слова, которую использующая этот язык группа людей считывает по умолчанию". Да, это звучит размыто. Но практически, в отношении "чётного"/"нечётного" консенсус вполне определён, если кто-то честно не знает и хочет узнать, его узнать не так сложно (можно начать с Вики).
'0' - это символ. '1' - тоже символ. Мы можем договориться, что эти символы что-то выражают. Скажем, мы можем заметить за собой некоторую интуицию - что наборы из "трёх коров", "трёх карандашей" и "трёх камней" имеют что-то общее. Это что-то мы можем попытаться записать символом '3'.
После этого мы можем заметить, что (при некоторых условиях) возникают изоморфизмы между символами и внешними событиями. Например, если у меня было восемь кубиков, которые раскатились по полу, то я могу держать в голове "осталось 8", собирать кубики и изменять удерживаемое в голове: "осталось 7", "осталось 3", "остался 1". В этих правилах манипуляции символами практически полезно иметь символ '0' (в нашем сценарии, мысль "осталось 0" - это эмпирическое предсказание "теперь можно выдохнуть и заняться другими делами, не опасаясь наступить на кубик").
Символом '0' я при этом манипулирую по тем же правилам, что и символами '1', '3', '8'. Поэтому в той мере в которой какие-то наборы символов вообще полезно называть словами, полезно называть весь этот набор символов, включая '0', каким-то общим словом. Это может быть слово "числа", это может быть "неотрицательные целые", это может быть "мумзики" (хотя в последнем случае окружающие вас вряд ли поймут правильно).
Если пытаться построить стройную общую систему в том, как мы манипулируем этими символами, можно прийти к концепциям "множества" и "мощности". В этом случае есть набор мощностей множеств (кардинальных чисел), который включает "0" как мощность пустого множества.
А вот мне интересно, с современными выч.мощностями и всякими ИИ можно сделать какой-нибудь метод обфускации шифротекста?
Это называется "стеганография" и сколько-то таких приёмов уже придумано. Один из самых тупых - зашифрованное сообщение пишем в наименее значимые биты всех пикселей PNG с котиком, эффективность больше 12%. Мизер ловится частотным анализом.
Аналогично, для текста можно предварительно согласовать порождающую грамматику (в духе Reply -> "а он чё?" DialogueElement | "ну нифига себе" DialogueElement) и реконструировать применённые правила, превращая их в биты.
Есть и более тонкие моменты, связанные с тем что ключ короче инфы им с позволения сказать зашифрованной(а именно на этом хакнули Энигму, пользуясь компом слабее Ардуины)
Очевидная проверка (вполне возможно вы её уже учли): это с включением опции Settings -> Privacy -> Advanced -> Censorship Circumvention?
конечно Телега еще работает, но это вопрос времени.
Про текст есть всякие федеративные мессенджеры (я глубоко не лез в их мир, но базовое впечатление - что их буквально десятки). Matrix, Briar, SimpleX...
Я думаю, что в основном люди спрашивают "что не анализируется ТСПУ", которое к СОРМ имеет мало отношения.
То есть, это два разных вопроса: что не может быть нарушено в автоматическом режиме и что не может быть прочитано post factum. Первое проще, из общий соображений ТСПУ не умеет в любой достаточно экзотический здесь и сейчас протокол.
Для текста вроде мессенджеров вагон и тележка, нетривиально как раз аудио/видео.
Signal определённо работает (по крайней мере у четырёх разных стационарных операторов, ожидаю что и у мобильных). Jami вроде работает, нужно больше тестов.
Подразумеваемая полная форма этой фразы "все разумные люди же понимают... [а если вы не, то вы сами расписались что вы не разумный человек и вас можно игнорировать]".
Я непосредственно смотрел для 2-НДФЛ, но сильно ожидаю что с трудовой то же самое: вы можете получить PDF с приложенным отдельно файлом подписи .p7s. После чего его надо проверить. Adobe Acrobat этого, судя по всему, "из коробки" не умеет (может, можно научить). openssl умеет (openssl smime -verify -in doc_name_PDF.p7s -inform DER -content doc_name.pdf), только для этого а) HR должен уметь этим пользоваться и б) нужно добавить поддержку ГОСТ, ибо из дистрибутива по умолчанию её сколько-то лет назад выкинули.
Моё замечание к словоупотреблению: "противодействие" скорее подразумевает что вот было равновесие, было воздействие в сторону от этого равновесия, и как результат возникла сила, тянущая обратно (cf. "принцип Ле Шателье").
То что мы имеем - это парный процесс, обе компоненты которого уводят из окрестности существовавшего решения, сваливаясь к какому-то другому равновесию.
Я не оспариваю что он закономерный, но, возвращаясь к изначальному пойнту, то что действия людей согласованы с объективной структурой предъявленных им стимулов - не мешает мне субъективно считать их неправыми, и я не вижу в этих двух суждениях противоречия.
There’s a narrative I find kind of troubling, but that unfortunately seems to be growing more common in science. The core idea is that the mere existence of perverse incentives is a valid and sufficient reason to knowingly behave in an antisocial way, just as long as one first acknowledges the existence of those perverse incentives.
Я бы не использовал слова "противодействие" для таких мероприятий - оба усилия направлены на ухудшение ситуации по моей шкале. Eye for an eye leaves the world blind и всё такое.
Значит, оно должно возвращать не double, а что-то в духе Meters или Unit<Meters, double>.
В принципе справедливо, и я предпочёл бы находиться в мире, где это так, но а) плохо применимо когда уже есть уйма кода с double, включая C-интерфейсы нескольких разных библиотек; б) я взял простой и компактный случай как иллюстрацию, можно взять менее компактный где система типов всё равно не поможет выразить смысл (ну, или описание типа будет чрезмерно громоздким).
Length переименовываем в ComputeLength, и затратность уже понятна по имени.
Не согласен. Вы решили одну проблему, но создали другую: теперь у объекта нет просто метода Length(), который в 90% случаев можно и нужно использовать как простой аксессор. Оговорка сделана оговоркой для оставшихся 10%.
А вообще что такое «затратный вызов»?
Компактное утверждение "этот вызов может занять больше времени чем кажется (если вы не понимаете, сколько и почему, спросите у автора кода или изучите и поймите реализацию, полный и точный ответ слишком длинный для этого комментария)".
И, кстати, в LengthUnits такого комментария нет. Я так понимаю, оно не затратное? Или забыли написать?
Ну вот. Можно, конечно, написать больше комментариев чтобы прояснить и это (в данном случае оно более быстрое - затем и нужно, - но возлагает на клиента обязанность думать, как правильно обойтись с результатом).
Ничего не понял. Где этот случай торчит в API?
У данного типа - нигде (и нет, его индикатор в данном классе не является уместным), отсюда и предупреждение. Я расшифровываю "не понял" как "комментариев всё ещё недостаточно" (в данном случае недостающая часть отчасти покрывается комментарием к самому типу, а отчасти ожидается в голове программиста, как часть знания предметной области).
В плюсах лучше возвращать std::variant<Meters, ProjUnits>, например, и комментарий снова не нужен
Не очевидно что лучше. Потому что объектов прорва, а опция variant у них будет одна и та же. Её можно понять заранее во внешнем коде. (И это нелокальное условие, которое я не знаю как выразить типами.)
Вообще, кажется, заметная часть моего убеждения что комментарии нужны - что в проекте существуют нелокальные условия, которые влияют на локальные решения, поэтому их приходится выражать (напоминать) текстом. На это можно возразить, что одна из задач архитектора - превратить нелокальные условия в локальные. Но я сомневаюсь что даже в идеальном случае в сколько-нибудь сложной задаче это можно сделать на 100%.
Комментарии могут размечать логические блоки в пределах функции (а вынести их в отдельные именованные функции может быть плохой идеей из-за большого количества совместно используемых переменных). Более того, один из способов дизайна методов - вначале записать комментариями предполагаемую логику работы, а затем реализующий её код (приём взят из "Совершенного кода" Макконнелла).
Комментарии к публичным интерфейсам полезны, потому что передают семантику использования и неочевидные ограничения, которые затруднительно заложить в имена:
class GeoLine {
public:
//! \brief возвращает длину линии в _метрах_, потенциально затратный вызов
//! \warning в случае местной системы координат длина будет в единицах проекции
double Length(void) const;
//! \brief возвращает длину линии в _единицах проекции_
double LengthUnits(void) const;
}
Или содержат примеры использования:
// \example LOG_TIME(Info) foo(); //выведет в лог время выполнения foo()
#define LOG_TIME(Lv) if(log::impl::timer<Lv> t; t)
Комментарии могут содержать напоминания - знание, которое надо не забыть учесть при изменении кода (даже если прямо сейчас это знание не порождает какого-то решения, про которое надо объяснять "почему"):
int foo(double* xBegin, double* xEnd, const double* yBegin){
// yBegin имеет право совпадать с xBegin
//...
}
Наконец, исключение "чтобы объяснить почему сделано именно так, а не иначе" - очень резиновое. Ведь такие объяснения возможны в любой сколько-то нетривиальной функции:
/// Какой из этих трёх комментариев здесь уместнее? Или никакой?
// определяем, с какой стороны луча находится точка
// подставляем точку в уравнение прямой
// наша прямая aX+bY+c=0, подстановка (p.x,p.y) даёт знаковое расстояние
double dist = a*p.x + b*p.y + c;
if(dist > 0) { //справа по направлению обхода
//...
} else {
//...
}
Мне кажется, или это универсальная претензия к принятию решений в условиях существенной неопределённости? Если туристическая группа пошла маршрутом, который из их исходных знаний ожидался более безопасным, попала под лавину и погибла - ни им ни их родственникам тоже "не легче".
Прагматически, решения всё равно надо принимать, и я считаю, что их качество в среднем всё ещё важно. Эмоционально, я хочу знать. Не "чтобы было легче", а потому что мне любопытно.
Эмоционально этот подход мне близок, но есть другая перспектива: я хочу иметь в голове модель, которая для действия X предсказывает, насколько вероятны те или иные исходы. Т.е. для Q = P("меня посадят" | do("я зашёл в Facebook")) - P("меня посадят" | ~do("я зашёл в Facebook")) может хотеться знать не просто категорическое Q>ε, а количественную оценку Q.
Вы решили проиллюстрировать это математикой - я отвечаю на уровне математики.
На уровне практических задач, что характерно, будет то же самое. Валидно ли писать
*reinterpret_cast<std::atomic<int>*>(&val) = 42;? Если идти от правил языка, то ответ "конечно же нет, точка". А если считать что "практическая перепроверка" может быть использована вместо строгих рассуждений, то с одной стороны так нельзя, но с другой у Пети всё правильно работает, проверка не доказала невалидности, так что идея Васи "давайте срочно перепишем этот код" имеет "меньшую степень обоснованности"©.Если вы хотели показать что-де существуют ситуации, когда правильный ответ по-прежнему совершенно недвусмысленный, но вот ваши эвристики проверки этого ответа могут дать сбой, то даю обратную связь: эту идею из текста лично я не считываю. Вместо этого я читаю нечто вроде "есть правила "для ЕГЭ", а вот если разбираться как на самом деле и делать разные проверки, то уже не так и бесспорно что 0 - чётное".
Если честно, я плохо понимаю - то ли вы действительно не видите подлежащих строгих форм используемых утверждений, то ли намеренно стараетесь не понять сказанного, то ли что-то третье.
Если первое, то (∀n∈N (∃ k∈N n=2k → ¬A(n))) → ¬A(0). (N - множество конечных кардиналов, включающее Card(∅) = 0.)
Я даже хотел взять какой-нибудь учебник по алгебре вместо Вики, но на его страницу затруднительно дать ссылку. My bad. Вики (как и любая энциклопедия) полезна чтобы подсмотреть одно определение в области которую вы в целом знаете, но не чтобы выучить что-то с нуля.
Есть целые числа, Z. (Можно ограничится только натуральными, N.)
Мы договорились для a,b ∈ Z, b≠0 под фразой "a делится на b" понимать "∃ k ∈ Z : a = k*b". Мы договорились под фразой "a - чётное" понимать "a делится на 2". Мы договорились под фразой "a - нечётное" понимать "неверно что a делится на 2"
Из этого определения следуют свойства, вроде того что x*y делится на b если и только если x делится на b либо y делится на b. Или что a делится на 5 если его десятичная запись заканчивается на 5. Или что сумма двух равных друг другу чисел всегда чётная.
Если у вас на руках число n, и вы хотите понять, чётное ли оно, вам необходимо и достаточно показать соответствие определению. В данном случае n=0 это тривиально: "∃ k=0 ∈ Z : n = k*2". Всё.
Вы можете вместо прямого определения использовать какие-то ранее доказанные свойства (к примеру, заметить что 0 = 0+0), но следует соблюдать минимальную аккуратность - скажем, десятичная запись числа 30 не заканчивается на 5, но 30, тем не менее, делится на 5: "∃ k=6 ∈ Z : 30 = k*5". То что конкретное свойство не помогло вам ответить на вопрос о соответствии определению - не признак какой-то глубокой истины, это просто означает что вы выбрали неудачное для вашей задачи свойство.
Например для отслеживания инвариантов. Если я могу доказать что в некоторой ситуации утверждение A(n) верно только если n нечётное, то я автоматом знаю что A(0) неверно.
Здесь, конечно, существенно что "чётность" - эмпирически полезное понятие, которое умеет возникать в самых разных задачах. Никто не мешает мне изобрести свойство "ц-чётность", такое что 2, 4, 6, ... - ц-чётные, а 0 - нет, но засада в том, что на практике я намного чаще смогу получить результат вроде "A(n) верно только если n нечётное", чем "A(n) верно только если n не-ц-чётное".
Значит "та расшифровка слова, которую использующая этот язык группа людей считывает по умолчанию". Да, это звучит размыто. Но практически, в отношении "чётного"/"нечётного" консенсус вполне определён, если кто-то честно не знает и хочет узнать, его узнать не так сложно (можно начать с Вики).
'0' - это символ. '1' - тоже символ. Мы можем договориться, что эти символы что-то выражают. Скажем, мы можем заметить за собой некоторую интуицию - что наборы из "трёх коров", "трёх карандашей" и "трёх камней" имеют что-то общее. Это что-то мы можем попытаться записать символом '3'.
После этого мы можем заметить, что (при некоторых условиях) возникают изоморфизмы между символами и внешними событиями. Например, если у меня было восемь кубиков, которые раскатились по полу, то я могу держать в голове "осталось 8", собирать кубики и изменять удерживаемое в голове: "осталось 7", "осталось 3", "остался 1". В этих правилах манипуляции символами практически полезно иметь символ '0' (в нашем сценарии, мысль "осталось 0" - это эмпирическое предсказание "теперь можно выдохнуть и заняться другими делами, не опасаясь наступить на кубик").
Символом '0' я при этом манипулирую по тем же правилам, что и символами '1', '3', '8'. Поэтому в той мере в которой какие-то наборы символов вообще полезно называть словами, полезно называть весь этот набор символов, включая '0', каким-то общим словом. Это может быть слово "числа", это может быть "неотрицательные целые", это может быть "мумзики" (хотя в последнем случае окружающие вас вряд ли поймут правильно).
Если пытаться построить стройную общую систему в том, как мы манипулируем этими символами, можно прийти к концепциям "множества" и "мощности". В этом случае есть набор мощностей множеств (кардинальных чисел), который включает "0" как мощность пустого множества.
Это называется "стеганография" и сколько-то таких приёмов уже придумано. Один из самых тупых - зашифрованное сообщение пишем в наименее значимые биты всех пикселей PNG с котиком, эффективность больше 12%. Мизер ловится частотным анализом.
Аналогично, для текста можно предварительно согласовать порождающую грамматику (в духе Reply -> "а он чё?" DialogueElement | "ну нифига себе" DialogueElement) и реконструировать применённые правила, превращая их в биты.
Предлагаете всё шифровать одноразовым блокнотом?
Очевидная проверка (вполне возможно вы её уже учли): это с включением опции Settings -> Privacy -> Advanced -> Censorship Circumvention?
Про текст есть всякие федеративные мессенджеры (я глубоко не лез в их мир, но базовое впечатление - что их буквально десятки). Matrix, Briar, SimpleX...
Я думаю, что в основном люди спрашивают "что не анализируется ТСПУ", которое к СОРМ имеет мало отношения.
То есть, это два разных вопроса: что не может быть нарушено в автоматическом режиме и что не может быть прочитано post factum. Первое проще, из общий соображений ТСПУ не умеет в любой достаточно экзотический здесь и сейчас протокол.
Для текста вроде мессенджеров вагон и тележка, нетривиально как раз аудио/видео.
Signal определённо работает (по крайней мере у четырёх разных стационарных операторов, ожидаю что и у мобильных). Jami вроде работает, нужно больше тестов.
Я как раз тестирую Jami, он умеет в установку одного профиля на несколько устройств. (Пока не знаю насколько хорошо, просто знаю что это есть.)
Подразумеваемая полная форма этой фразы "все разумные люди же понимают... [а если вы не, то вы сами расписались что вы не разумный человек и вас можно игнорировать]".
Я непосредственно смотрел для 2-НДФЛ, но сильно ожидаю что с трудовой то же самое: вы можете получить PDF с приложенным отдельно файлом подписи .p7s. После чего его надо проверить. Adobe Acrobat этого, судя по всему, "из коробки" не умеет (может, можно научить). openssl умеет (
openssl smime -verify -in doc_name_PDF.p7s -inform DER -content doc_name.pdf), только для этого а) HR должен уметь этим пользоваться и б) нужно добавить поддержку ГОСТ, ибо из дистрибутива по умолчанию её сколько-то лет назад выкинули.Моё замечание к словоупотреблению: "противодействие" скорее подразумевает что вот было равновесие, было воздействие в сторону от этого равновесия, и как результат возникла сила, тянущая обратно (cf. "принцип Ле Шателье").
То что мы имеем - это парный процесс, обе компоненты которого уводят из окрестности существовавшего решения, сваливаясь к какому-то другому равновесию.
Я не оспариваю что он закономерный, но, возвращаясь к изначальному пойнту, то что действия людей согласованы с объективной структурой предъявленных им стимулов - не мешает мне субъективно считать их неправыми, и я не вижу в этих двух суждениях противоречия.
Вот статья, на мой взгляд хорошо суммирующая эту интуицию:
Я бы не использовал слова "противодействие" для таких мероприятий - оба усилия направлены на ухудшение ситуации по моей шкале. Eye for an eye leaves the world blind и всё такое.
В принципе справедливо, и я предпочёл бы находиться в мире, где это так, но а) плохо применимо когда уже есть уйма кода с double, включая C-интерфейсы нескольких разных библиотек; б) я взял простой и компактный случай как иллюстрацию, можно взять менее компактный где система типов всё равно не поможет выразить смысл (ну, или описание типа будет чрезмерно громоздким).
Не согласен. Вы решили одну проблему, но создали другую: теперь у объекта нет просто метода
Length(), который в 90% случаев можно и нужно использовать как простой аксессор. Оговорка сделана оговоркой для оставшихся 10%.Компактное утверждение "этот вызов может занять больше времени чем кажется (если вы не понимаете, сколько и почему, спросите у автора кода или изучите и поймите реализацию, полный и точный ответ слишком длинный для этого комментария)".
Ну вот. Можно, конечно, написать больше комментариев чтобы прояснить и это (в данном случае оно более быстрое - затем и нужно, - но возлагает на клиента обязанность думать, как правильно обойтись с результатом).
У данного типа - нигде (и нет, его индикатор в данном классе не является уместным), отсюда и предупреждение. Я расшифровываю "не понял" как "комментариев всё ещё недостаточно" (в данном случае недостающая часть отчасти покрывается комментарием к самому типу, а отчасти ожидается в голове программиста, как часть знания предметной области).
Не очевидно что лучше. Потому что объектов прорва, а опция variant у них будет одна и та же. Её можно понять заранее во внешнем коде. (И это нелокальное условие, которое я не знаю как выразить типами.)
Вообще, кажется, заметная часть моего убеждения что комментарии нужны - что в проекте существуют нелокальные условия, которые влияют на локальные решения, поэтому их приходится выражать (напоминать) текстом. На это можно возразить, что одна из задач архитектора - превратить нелокальные условия в локальные. Но я сомневаюсь что даже в идеальном случае в сколько-нибудь сложной задаче это можно сделать на 100%.
Комментарии могут размечать логические блоки в пределах функции (а вынести их в отдельные именованные функции может быть плохой идеей из-за большого количества совместно используемых переменных). Более того, один из способов дизайна методов - вначале записать комментариями предполагаемую логику работы, а затем реализующий её код (приём взят из "Совершенного кода" Макконнелла).
Комментарии к публичным интерфейсам полезны, потому что передают семантику использования и неочевидные ограничения, которые затруднительно заложить в имена:
Или содержат примеры использования:
Комментарии могут содержать напоминания - знание, которое надо не забыть учесть при изменении кода (даже если прямо сейчас это знание не порождает какого-то решения, про которое надо объяснять "почему"):
Наконец, исключение "чтобы объяснить почему сделано именно так, а не иначе" - очень резиновое. Ведь такие объяснения возможны в любой сколько-то нетривиальной функции:
Мне кажется, или это универсальная претензия к принятию решений в условиях существенной неопределённости? Если туристическая группа пошла маршрутом, который из их исходных знаний ожидался более безопасным, попала под лавину и погибла - ни им ни их родственникам тоже "не легче".
Прагматически, решения всё равно надо принимать, и я считаю, что их качество в среднем всё ещё важно. Эмоционально, я хочу знать. Не "чтобы было легче", а потому что мне любопытно.
Эмоционально этот подход мне близок, но есть другая перспектива: я хочу иметь в голове модель, которая для действия X предсказывает, насколько вероятны те или иные исходы. Т.е. для Q = P("меня посадят" | do("я зашёл в Facebook")) - P("меня посадят" | ~do("я зашёл в Facebook")) может хотеться знать не просто категорическое Q>ε, а количественную оценку Q.