PyTorch против Tensorflow стремятся

Google недавно включил в ночной сборку tenorflow свой режим Eager , обязательный API для доступа к возможностям вычисления tenorflow.

Как тензор потока готовы сравнивать с PyTorch?

Некоторые аспекты, которые могут повлиять на сравнение:

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

Примечание 1: Ярослав Булатов написал отзыв о приятных особенностях .

Примечание 2: В предыдущем вопросе я запросил сравнение между PyTorch и Tensorflow Fold. В то время мне казалось, что Fold может столкнуться с PyTorch благодаря поддержке Google. Я был очень, очень неправ: в конце концов, Google сам отказался от Fold в пользу Eager. Я понимаю, что это было связано с внутренними ограничениями в нормальном API-интерфейсе тензорного потока, из-за которого Fold не был очень дружелюбным, что ограничивало его принятие.

Одним из ключевых преимуществ, которыми я часто пользуюсь, является то, что он совместим с pdb, так что

pdb.set_trace # To the rescue

Разрешает использование структур данных Python

и позвольте нам использовать питонический поток управления вместо использования основных tf-эквивалентов.

Также это позволяет избежать проблем метапрограммирования, таких как «отложенная загрузка» и добавление множества операций в мой график. Также автоградное сходство