Changing several core elements of array manipulations allows writing clean and reliable code AND resolves many conflicts.

Einops is a minimalist notation for tensor manipulations that replaces following operations:

• view / reshape
• reductions: max, min, mean, etc.
• expand_dims, squeeze and unsqueeze
• transpose/permute/rollaxis
• repeat
• tile
• stack (and, in limited scenarios, concatenate/cat)
• array_split/split/chunks
• flatten

For example, transposition

x.transpose(0, 2, 3, 1)

In einops is written as

rearrange(x, 'b c h w -> b h w c')  # long names are also allowed

There are only three operations, please read tutorial.

Motivation

• einops is already implemented and works over a number of frameworks

  • it works identically in all supported frameworks
  • existing codebase is pure python and has zero dependencies, so it can be easily moved inside frameworks and readjusted if needed

• solves the problem of interface conflicts that data-apis tries to solve (only for some operations, but covered subset of operations is probably the main source of discrepancies)

  • while moving code from existing frameworks to 'unified API' mistakes are hard to avoid: torch.repeat does job of numpy.tile, but not numpy.repeat; flatten is defined differently by frameworks; set of axes as tuples or individual arguments, and other discrepancies
  • similarity of previous and new api would almost surely drive to "migration by substitution"
  • no conflicts with already existing operations is part of einops design

• verbose API has multiple advantages (demonstrated here) and helps other people to follow code which is non-trivial for tensor packages

• view / reshape are dangerous operations: they can completely break tensor structure, while mistakes done with them are almost non-catchable (when dealing with just a bunch of numbers in an intermediate activation, it is impossible to know those are ordered in a wrong way).

  • einops replaces these operations, adds checks and makes it impossible to break tensor structure

While this looks like a big leap, it is a surprisingly good moment to make it: move to more reliable and transferable code without depreciating parts of existing API. In this scenario first transition would be made by libs' developers, which will simplify following wider adoption.

In case of positive decision, introduction of new features and operations in einops will be first coordinated with/by consortium to ensure identical and efficient support by all frameworks.