Tensor type definition

[k-ye]

I'm sure this has been discussed previously, but I'd like to throw this out again and track it in a single place.

Currently we are defining a tensor (e.g. ti.Vector) field using the following syntax:

a = ti.Vector.field(3, ti.f32, shape=(3, 4))

There are several issues I can see with this approach:

1. For each type we are going to support, we need to add a new .field method.
2. The information of the vector is not immediately following ti.Vector. i.e., 3 and ti.f32 defines a vec3 of type float32. Ideally, we can write something like ti.Vector(dtype=ti.f32, n=3). This is actually already the case when defining a composite struct type, see https://docs.taichi.graphics/lang/articles/basic/type#compound-types

my_vec2i = ti.types.vector(2, ti.i32)
my_vec3f = ti.types.vector(3, float)
my_ray3f = ti.types.struct(ro=my_vec3f, rd=my_vec3f)  # `my_vec2i` and `my_vec3f` are used as a lower-level type

---

An alternative solution is to just adopt what we are doing in step 2, and push it further during the field definition. For example:

my_vec2i = ti.types.vector(2, ti.i32)
my_vec3f = ti.types.vector(3, float)
my_ray3f = ti.types.struct(ro=my_vec3f, rd=my_vec3f)

vf = ti.field(dtype=my_vec2i)
sf = ti.field(dtype=my_ray3f)
# ...

This provides a consistent approach to define Taichi fields.

The downside is that we sort of lose the opportunity to control the APIs different kinds of fields can support. Concretely, we can return different field impls for ti.field and ti.Vector.field, namely ScalarField and VectorField, respectively. It only makes sense for VectorField to provide a method for indexing into each individual component of the vector. If these are all unified into a single Field type, then Field need to provide the superset of all the APIs different field type should support.

[k-ye]

Same for the ndarray

[AmesingFlank]

I much prefer the 2nd option, i.e., we don't add .field(..) to each type, and we allow ti.field() to allow vector/matrix/struct types.

IMO it doesn't make that much sense to have .field(..) and a .ndarray(...) method on an object which represents a type. It is a common paradigm for the type to be an argument to the container, e.g., std::vector<int> in C++. It's much less intuitive for the type itself to contain a method that constructs a container.