Taichi: [Lang] [refactor] "Field" as a better name for "var" and "tensor"

[yuanming-hu]

Concisely describe the proposed feature
While I was teaching Taichi, I realized that the word "tensor" is used frequently, yet in the current Taichi API it's exposed as "var". A fun fact is that "tensor" never appears in any Taichi API.

One year ago I picked the name var for variable. At that time the concept "tensor" had not been well formulated. I think now is the time to replace var with tensor.

I think we should deprecate var, and use tensor for Taichi. var should be obsolete in Taichi >= 1.0.0. The new APIs would be

ti.tensor(...)
ti.Vector.tensor(...)
ti.Matrix.tensor(...)
...

Inputs are welcome.

The name "Tensor" could also be

• Field
• Array
• Grid
• ...

[rexwangcc]

+42 to this. tensor is already used over var even in some existing PR discussions, this standardization could really help make some conversations clear, especially tensor is the 1st class citizen in Taichi.

My only concern is that .tensor() will likely to remind users of concepts like torch.tensor and thus make them expect similar signatures. (especailly Taichi provides things like to_torch() methods).

On the other hand, Tensorflow still uses tf.constant to create Tensors, so I can see either way works, but we need to probably estimate the workload of this API change v.s. the UX improvement it brings.

[archibate]

Some GAMES 201 students in WeChat suggests us to use the word field instead of tensor.
The main reason is that tensor reminds us vector or matrix, it would be great if we could replace tensor to avoid ambiguous.
And the word vector field sounds more professional and informative than tensor of vectors :)

[yuanming-hu]

Great idea! I think we need more discussions on this. Field sounds nice for 2D/3D tensors, but for 1D arrays this can be a little weird.

Options:

• Tensor
• Field
• Array
• Grid
• Blob
• ...

[Rullec]

Hi all,
Sorry for this bother. :-)
Is there possibly something that I can help? It seems this issue is friendly for a new developer.

[yuanming-hu]

Yeah, I think the implementation is easy, but we need to carefully decide which name to use :-)

[Rullec]

Great!
So please let me investigate this issue and read its related codes in advance now.
If you reach an agreement all together, please let me know then I can help with it. :D

[yuanming-hu]

We are converging on the name "field". This means we will use

• ti.field(dtype, ...) to allocate a scalar field (tensors)
• ti.Vector.field/ti.Matrix.field to allocate vector/matrix fields (tensors)

ti.Vector/Matrix without .field should be left for local variables only. We should gradually enforce this via deprecation marks.

I believe the name "field" works well because it has two sets of meanings:

• (1D) In databases, "field" simply refers to a component of a record. For example, mass and volume properties of a particle. This justifies the usage of "field" for 1D arrays.
• (2D, 3D, 4D, ...) In physics, "field" refers to "a physical quantity is assigned to every point in space". E.g., "vector fields", "velocity fields", and "magnetic fields". When we allocate high-dimensional arrays of scalars/vectors/matrices, they are exactly physical "fields" sampled at discrete points.

@KLozes what do you think? As a native speaker (and CFD expert), you probably have better ideas on how natural/unnatural it sounds than me. Feel free to share your opinions :-) Thank you so much!

[KLozes]

+1! I think field is a perfect name!

[yuanming-hu]

Thank you for the prompt reply! Let's stick to "field" then :-)

[Rullec]

Great! So what is our implement plan and what can I help? :D

[yuanming-hu]

Great! So what is our implement plan and what can I help? :D

Could you open up an issue titled [Lang] [refactor] Implement "field" with a few bullets

• [ ] Support ti.field, ti.Vector.field, ti.Matrix.field
• [ ] Deprecate ti.var
• [ ] Update doc
• [ ] ...

I believe @archibate is very interested in implementing this. Please work together :-) I'll probably help with documentation in the following weeks.

I'm closing this discussion issue. Let's resume our chat in a new implementation issue.