[RFC] Syntax sugar: v = [1, 2, 3] instead of v = ti.Vector([1, 2, 3]) ?

[yuanming-hu]

It seems that the writing v = ti.Vector([1, 2, 3]) is too verbose for creating a vector in Taichi kernels. It might make sense to create a vector simply use a syntax like v = [1, 2, 3] or v = {1, 2, 3}. Similar syntax sugars apply to matrices.

Note that we already support a similar syntax when writing to a field:

taichi/python/taichi/examples/simulation/mpm99.py

Line 31 in 0a7a7c4

grid_v[i, j] = [0, 0]

Making this work for vector/matrix creation may simplify programs. WDYT?

[strongoier]

The first syntax (v = [1, 2, 3]) sounds good to me. Enforcing this can also prevent users from trying to use Python lists (which is undefined behavior for now) in Taichi kernels.

By the way, we can make s = {'a': 1, 'b': 2} as a syntax sugar for s = ti.Struct({'a': 1, 'b': 2}) as well :-)

[k-ye]

Agreed on the verbosity issue. I think v = [1, 2, 3] is a nice move (note that {1, 2, 3} in Python actually creates a set, so it's probably not the best representation...).

We can further think about how to deal with arithmetic, especially if we'd like to support a pure-Python mode. Today when I was porting Taichi kernels back to Python, I had to replace all ti.Vectors with np.array. Clearly Python list doesn't support vector maths, but with a proper type system, we should be able to handle this well... (cc @strongoier @lin-hitonami )

Finally, I think we can look into Python Array API, and make Taichi's tensors (or fields?) as much API-compatible as possible

[yuanming-hu]

We can further think about how to deal with arithmetic, especially if we'd like to support a pure-Python mode. Today when I was porting Taichi kernels back to Python, I had to replace all ti.Vectors with np.array. Clearly Python list doesn't support vector maths, but with a proper type system, we should be able to handle this well... (cc @strongoier @lin-hitonami )

That reminds me of this old issue: #1426

Sometimes it is helpful to directly call @ti.func in Python-scope, and doing vector math (e.g., ``v1.cross(v2)`) can also be helpful. Perhaps we can consider these feature requests together :-)

[bobcao3]

We should be careful of the types and not rely as heavily on type inference as it might be prone to user mistakes. A user forget to add .0 or .0f to a value may accidentally make everything down the chain an integer, and this might also be counter intuitive. (I observe a lot of college students use ints in their equations and relying on type upgrades, or in language like Python where divide / gives you a floating point output)

[k-ye]

Sorry I forgot to add our conclusion here: This syntax sugar could prevent the support for local array. And users might actually assume [...] is a Python list, causing more confusions here.

If our type system is more robust, I think we can have this slightly more cumbersome way to define a vector:

v3f = ti.Vector(dtype=ti.f32, n=3)

@ti.kernel
def foo():
  v: v3f = [1.0, 2.0, 3.0]
  v2 = v3f([1, 2, 3])

See #4230

[k-ye]

v: v3f = [1, 2, 3] doesn't work for python -- You can't override operator= even if there is a type annotation.