[Discussion] Expected behavior of logical expressions in Taichi

[strongoier]

Currently, there isn't a clear description of expected behavior of logical expressions (and / or) in Taichi. The implementation,

taichi/python/taichi/lang/ops.py

Lines 792 to 793 in 71dd174

	logical_or = bit_or
	logical_and = bit_and

, shows that logical_and / logical_or is simply treated as bitwise_and / bitwise_or. This leads to the non-short-circuit behavior (#3572) and the non-intuitive computation result:

@ti.kernel
def func(a: ti.i32, b: ti.i32) -> ti.i32:
    return a and b

print(func(2, 3))  # 2

In Python, the behavior of logical expressions is like:

print(2 and 3)  # 3
print(2.0 or 0)  # 2.0

which is short-circuiting and uses the determining expression as the result.

Should we make logical expressions in Taichi behave the same as in Python, keep the original behavior in Taichi, or define yet-another behavior? Opinions are welcome.

[lin-hitonami]

I think the behavior should be identical to Python's because most Python users would expect taichi's grammar is similar to Python's.

[ailzhang]

I second @lin-hitonami 's idea, python frontend's behavior should be close to python convention as much as possible. ;)

[strongoier]

According to the discussions in this line, we will make the behavior of logical expressions in Taichi the same as Python.

[lin-hitonami]

There is a problem if we make the behavior the same as Python. For this program:

@ti.kernel
def foo(a: ti.i32, b: ti.f32):
    c = a and b

What is the type of c? Will this confuse the type checker?

[strongoier]

Yes this is indeed a problem. We cannot have exactly the same behavior as Python because Taichi is statically typed. In Taichi, all operands of logical expressions should be enforced to have a same type.

Then the core problem is more related to the order of our compilation process - we should do type check first, and then do transformations which may lose type enforcement information.