Существующее определение Null в Data Science сильно ограничено. Приложив немножко усилий? мы значительно улучшим обработку данных, ранее попадаемых в Null.
Старая проблема — "Null" проблема. Она была сформулированна в статье Кодда в отношении семантики баз данных.
Программисты должны прикладывать много усилий, чтобы обрабатывать Null значения. Наверное, поэтому они не любят Null и даже продвигали идею, что без Null можно обойтись. Популярно высказывание о том, что включение Null в SQL было ошибкой.
Последнее определение — самое часто используемое в БД.
В Data Science распространено определение Null, как пропущенное (missed) значение.
Здесь Jake VanderPlas обсуждает использование и трактовки Null, NaN, NA, None значений в python, Pandas, numpy.
Ниже я покажу, что существующий подход лишь частично отражает реальность и во многих случаях может быть расширен именно для использования в Data Science.
Вот здесь представлен хороший обзор текущего состояния дел с missed data (спасибо AlkanSte !)
Рассмотрим типичные случаи, когда в примере (sample), представлющем набор значений, отсутствуют некоторые значения.
Пример: датчик, снимающий значение, не выдал его. Датчик может быть поврежден. Или канал считывания данных может работать нестабильно с пропажей части данных.
Можно детализировать и другие случаи, но мы остановимся только на перечисленных.
Разные Null могут привести к различным последствиям. В вышеприведенных примерах, если Null означает "нет данных", то запустится процедура проверки датчика и канала предачи даннах. Если Null означает "Малая Вероятность", то мы придем к необходимости изменения расчетной формулы, чтобы она могла обрабатывать очень маленькие исходные значения. "Значение повреждено" может привести нас к решению поменять методики получения данных (например методику опроса).
Если мы используем данные для тренировки ML модели, то разделив Null на несколько более конкретных значений, мы извлечем больше информации из входных данных и в результате получим более точную модель.
Рассмотрим типовую в МЛ задачу классифиции документов. Наша цель — разложить документы по нескольким классам. Но некоторые документы не могут быть классифицированны. Причина этому:
В всех этих случаях мы обычно определям класс документа как Null. Но эти случаи будут лучше обрабатываться, если мы включим в нашу систему классификации все ^ значения, которые часто встречаются и которые имеют смысл: "Данных не хватает", "Конкурирующие значения", "Нет данных", "Другие", "Значение повреждено". Обычно все вышеперечисленные значения отмечаются как Null и удаляются из тренировочных наборов данных. Но мы используем нашу модель в реальной жизни, а в ней нам будут попадаться все эти вышеперечисленные значения. И нам будет полузно научиться распознавать и поврежденные, и многозначные, и другие подобные значения.
Во многих случаях такой фича-инжиниринг может существенно повысить качество классификации.
Есть и минус в замене Null на несколько более детальных классов. Null — это абстракция на уровне типов данных, на уровне языка, что дает нам много встроенных функций и методов в обработке данных.
Мы, по сути, добавляем новые классы в нашу систему классификации, что не намного усложняет обработку.
И, как минимум, нам надо явно понимать, что понимается под Null значениями в наших данных. А лучшее понимание данных всегда приведет к лучшим результатам, не правда ли?
К сожалению, не доступен сервер mySQL