Shall we limit the use of Python int/float in Taichi-scope?

[strongoier]

Preface

We would like to standardize the usage of Python objects in Taichi-scope. This discussion serves as a starting point, which focuses on Python int/float (corresponding to Taichi primitive types). I will call them Python values in this discussion.

Problem

Currently, there are the following sources of Python values in Taichi-scope:

• Global variables
• Arguments passed via ti.template()
• Literals
• Evaluation results

The first three sources are fairly straightforward. But what are evaluation results referring to?

In Taichi-scope, the current evaluation rules are as follows:

• Python value + Python value = Python value
• Python value + Taichi expression = Taichi expression
• Taichi expression + Taichi expression = Taichi expression

According to the first rule, there can still be Python values generated from expressions in Taichi-scope, which is a major source of mysterious inconsistent behavior reported by users (one extreme case: #3548). That is, if users would like to correctly understand the semantics of Taichi, they have to take the burden of understanding these complex rules.

Potential solution

To get rid of the inconsistency and simplify the semantics of Taichi, I propose that we disable the first evaluation rule. That is, as long as a Python value is stored in a variable in Taichi-scope, or involved in some calculation, it will become a Taichi expression. This can also simplify the compiler implementation - there will be no need for two versions (Python values & Taichi expressions) of each operator.

If this proposed change takes place, there will only be three sources of Python values in Taichi-scope:

• Global variables
• Arguments passed via ti.template()
• Literals

All calculations happen with Taichi expressions, which is much more clear to users.

Q: What if users want to use Python values for dispatching purposes?

They should stick to ti.static, which is a special environment designed for Python evaluation. That is, they can still use if ti.static(a.n == 2) to handle matrices of different size.

Q: How can users specify the data type of a literal?

Take the approach 1 of #4230. Note that #4224 was previous added to solve the problem in #4210, however I would say that solution is temporary. We should give a literal itself a type, instead of connecting it with variable definitions. If a literal is not explicitly given a type, it will take the default type when becoming a Taichi expression.

[k-ye]

This looks great! Are we blocked on cleaning up/formalizing our type system for this? For example, string literals in Python has no corresponding type in Taichi currently.

[strongoier]

I don't think it's blocked. Things like string literals will be handled and noted down along with implementation.

[strongoier]

As our main goal is to make users easily and clearly understand the behavior of Taichi, I prefer the following loop instead of simply documenting things out for our specification:

• Find a perspective (semantics-wise) which always confuses users
• Make a proposal for improvement
• Implement the proposal to handle potential risks
• Write down specification of the corresponding part

[ailzhang]

re giving literal a type, we need to be careful (smart) about the type here a little bit as python supports a "bignum" integer type which can work with arbitrarily large numbers. So it might overflow our default integral dtype easily. ;)

[strongoier]

Ah yes. A range check (which seems already there?) must be applied.