All streams
Search
Write a publication
Pull to refresh
38
0
Дмитрий Братусь @dbratus

User

Send message
С тех пор, хотя бы, как по какой-то причине его не включили в .NET Framework 1.1. Многие .NET разработчики и не подозревают о существовании HashSet. Прием с использованием hash-таблицы так же малоизвестен. В основном, люди не заморачиваются и используют ArrayList и List для задач, где уместнее был бы HashSet.
Вышеприведенный пример — это не просто ошибка, это эксплуатируемая брешь номер 1! На месте переменной вполне может быть код, и тогда злоумышленник сможет легко подсунуть exploit в данных.
Это хороший пример того, что как некоторые российские математики умеют все запутать, чтобы выглядеть серьезней (я имею в виду авторов книги). Зачем, к примеру, переименовывать min и max в S и T?

На самом деле min и max — это нечеткое AND и OR соответственно, и судя по тому, что авторы опирались на теорию нечетких отношений, это скорее всего действительно так. Тогда смысл замыкания здесь в том, что вначале ищется для каждого элемента и подмножества — находится ли этот элемент в отношении R с подмножеством, то есть со всеми его элементами, и здесь используется MIN потому что это выражение "(x R a1) OR (x R a2) OR… (x R aN)"; затем, вычисляется — находится ли элемент в отношении R хотя бы с одним подмножеством, и здесь используется max потому что это OR.

И та теорема, скорее всего, — перевод логики нечетких отношений в более привычную для автора алгебру матриц. Хотя, чтобы точно быть уверенным, нужен полный текст книги.
Чем-то похожим я сейчас занимаюсь, только вместо точек у меня фразы, и вычисление «расстояния» между ними — это самая заковыристая штука.
Однажды было посчитано, что себестоимость разработки полноценных юнит-тестов для системы такого масштаба будет превышать любой потенциальный ущерб от любых ошибок. Поэтому юнит-тесты покрывают только базовые вещи. Упор делается на интеграционные и бета-тесты. В конце концов, если учесть, что за 11 лет это был единственный случай, то ущерб ни такой уж и большой. Чаще система лежит из-за сетевых и аппаратных проблем, из-за ошибок в конфигурационных файлах и прочих вещей не относящихся к коду.
Нет. В западных компаниях человеческие ошибки считаются стихийным бедствием. Если все формальные процедуры соблюдены, значит никто не виноват.
Тут есть одна проблема. Когда в таблице около сотни миллионов записей, любое добавление поля в нее занимает часы. Поскольку проливка DDL скриптов требует отключения базы, происходит это ночью и похоже на запуск ракеты в космос. В этом участвует много людей, и требуется соблюдение некоторых формальных процедур. К тому же, если проливка хотя бы одного скрипта длится более 5-ти часов, все развертывание переносят на выходные, а то, как нетрудно догадаться, был понедельник (понедельник после развертывания — день веселый). В общем, решили переразвернуть приложение, а потом в приключения с базой никто ввязываться не захотел (проблема-то как бы решена).
До начала продаж следующего дня, то есть в течение суток.
Вообще говоря, между вероятностными и нечеткими моделями нет ничего общего (с этого начинал первую лекцию наш преподаватель нечеткой логики), но тему вы подняли интересную.

Тот же самый наш преподаватель объяснял разницу между вероятностью и нечеткостью так:

Представьте себе десять стаканов с жидкостью. Человек берет один из них и выпивает. Если пять из десяти стаканов содержат чистый яд, а остальные воду, то с вероятностью 50% человек умрет. Это вероятностная модель. Мы говорим, что любой произвольно взятый стакан содержит яд с вероятностью 50%. Если же мы говорим, что утверждение «любой произвольно взятый стакан содержит яд» истинно на 50%, это значит, что каждый стакан содержит 50% яда, и какой бы стакан ни выбрал человек, он [человек] окажется мертв на 50%, что бы это ни значило. Почему? Потому что мы рассуждаем в рамках силлогизма:

Если человек выпьет яд, он умрет.
Человек выпил яд.
Значит человек мертв.

Если рассчитать это по правилам нечеткой логики, получится, что человек мертв на 50%.

Вероятность — это лишь один из возможных способов дефазификаци, один из возможных способов интерпретации нечеткости. В данном примере можно трактовать то, что человек мертв на 50% так: из произвольно взятой выборки людей, 50% это не переживут. Но можно трактовать и по-другому: человек, кем бы он ни был, гарантировано выживет, но его здоровью будет нанесен непоправимый вред.

Вообще, дефазификация — это то, за что некоторые ортодоксальные ученые считают адептов нечеткой логики шарлатанами. На самом деле, нечеткая логика просто не определяет каких либо способов интерпретации — это просто метод исчисления высказываний.
Примеров можно привести массу, и каждый потянет на отдельную статью. Один такой я как раз держу прозапас, но скоро, думаю, опубликую.

Основная идея следующая:
  1. Не обращая внимания на нечеткость, сформулировать решение в виде системы утверждений.
  2. Для каждого предиката каждого утверждения найти такую функцию, которая в крайних случаях давала бы 1 и 0; в остальных, равномерно распределенные значения в пределах (0, 1).
  3. Применить нечеткую логику.


Этот метод можно применять в практике обычного программирования — для реализации, к примеру, бизнес-логики. Цель статьи — показать, что нечеткая логика — это просто. Как говорят американцы: «It's not a rocket scince».
Кстати, о нейронных сетях. На выходе нейронная сеть дает массив чисел. Как его интерпретировать? Фактически, его нужно сравнить с другими массивами чисел — эталонами, на которых сеть обучалась. Естественно, результат с эталонами никогда не совпадает точно, и здесь на помощь приходит нечеткая логика. Если элементы массивов нормализованы (принадлежат интервалу [0, 1]), тогда для сравнения результата с эталоном можно использовать формулу:

fuzzy_and(1 - abs(result[i] - etalon[i]))


Получаем массив степеней равенства длины равной количеству эталонов, а дальше дефазификация.

Один мой одногрупник разрабатывал нечто подобное на диплом.

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Date of birth
Registered
Activity