Пока что, учитывая, что Woodwork завершает планы по большим обновлениям. Если Woodwork станет расширением pandas, нам может не понадобиться это делать.

@angela97lin и я зарегистрировались и обсудили несколько вариантов реализации:

1. Попросите оценку графа компонента передать pandas каждому компоненту. Чтобы указать типы ww для компонентов, либо добавьте новые поля в fit и т. д., либо придерживайтесь шаблона текстового функционализатора с использованием параметров инициализации для указания соответствующих столбцов. Недостаток: некрасиво с точки зрения API, поэтому мы в первую очередь создали изделия из дерева.
2. Во время оценки графа компонентов передайте деревянные детали каждому компоненту. Пусть каждый компонент возвращает pandas. Недостаток: потенциальным ограничением является то, что компоненты не могут изменять тип дерева входных или вновь созданных объектов, кроме как путем изменения dtype панд. Однако у нас нет компонентов, которые полагаются на это.
3. Во время оценки графа компонентов передайте деревянные детали каждому компоненту. Пусть каждый компонент вернет деревянные детали. Проблема: большинство компонентов должны конвертироваться в панды внутри, чтобы выполнять такие преобразования, как добавление функций, удаление функций или изменение функций. После этих преобразований мы должны убедиться, что исходные типы изделий из дерева попадут в новую возвращенную таблицу данных изделий из дерева, иначе переопределенные пользователем настройки будут потеряны, как это происходит сегодня.

Статус: @angela97lin в настоящее время использует вариант 3 в № 1668.

План: мы продолжим эту стратегию, следя за сокращением времени выполнения из-за нескольких экземпляров ww datatable. И мы рассмотрим, есть ли какие-либо пожелания, которые мы должны сделать для работы с деревом, чтобы упростить эту задачу. Мы также будем следить за любыми привлекательными вариантами, которые мы, возможно, пропустили до сих пор.

@chukarsten @gsheni

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

Взломать это и подумать еще немного:

Конечная цель состоит в том, что нам нужен какой-то способ отслеживать исходные логические типы, которые нужны пользователю. Это может быть информация, хранящаяся в графе компонентов, или передаваемая каждому компоненту, который отвечает за установку этих типов обратно после преобразования некоторых данных. В настоящее время преследую 3 и добавляю информацию в граф компонентов, так как это проще всего протестировать (вместо обновления каждого компонента)... но на уровне компонентов это не имеет смысла.

Скажем, пользователь указывает Woodwork DataTable и явно преобразует категориальный столбец в естественный язык. Пользователь передает это компоненту. Нам нужно преобразовать в pandas, чтобы перейти к внешним библиотекам, и мы хотели бы вернуть объект Woodwork. Если мы просто вызовем конструктор Woodwork, он примет только предполагаемый тип (категориальный), что странно? Таким образом, мы должны отслеживать исходный указанный тип естественного языка и преобразовывать его перед передачей обратно пользователю.

Интересно отметить стандартный масштабатор: он может принимать столбцы int и преобразовывать их в числа с плавающей запятой. Если затем мы попытаемся вернуть столбцу исходный тип (int), нас будут ругать за попытку конвертировать числа с плавающей запятой в целые, когда это небезопасно. 😬

Обновление: быстро поговорили с @dsherry и @chukarsten. В настоящее время я реализую № 3, но имею дескриптор графа компонентов, отслеживающий исходные типы пользователей и обновляющий эту информацию по мере ее передачи от компонента к компоненту. Это работает нормально и приводит нас к месту, где работают AutoML/конвейеры, но после слияния # 1668 мы должны заняться обработкой этого на уровне компонентов и удалением этого кода из графа компонентов.

Мои следующие задачи: исправить индексные тесты при обновлении ветки из основной, очистить комментарии и проблемы с файлами, которые можно решить, не связанные с этим PR (просто общий код очистки). Как только код станет более чистым, найдите избыточность и профиль, чтобы увидеть, откуда берется эта огромная разница во времени / что мы можем с этим поделать.