Taichi: Different behavior of for loops in python and taichi scopes

[vkurenkov]

Iterating over the tensor's values in python scope results in an infinite loop. Is it expected? Could not find the reasoning behind this in the documentation.

import taichi as ti

ti.init()

x = ti.var(shape=(3), dt=ti.f32)
x[0] = 0
x[1] = 1
x[2] = 2

@ti.kernel
def finite_loop():
    for val in x:
        print(val)

def infinite_loop():
    for val in x:
        print(val)

finite_loop()
infinite_loop()

Access to tensor's values by indexing also can be indefinite: print(x[10000000]) works fine. As I understand, the indexing starts cycling, from the user point of view it's kinda strange, I rather expect the IndexOutOfRange exception as to be aware if there is a bug in the code.

[vkurenkov]

This cycling behavior is actually bug-prone, see https://github.com/yuanming-hu/difftaichi/issues/24

[yuanming-hu]

Thanks for raising this!

Iterating over the tensor's values in python scope results in an infinite loop.

Actually struct-fors are only supported in Taichi-scope. Sorry, the documentation was unclear about that.

Access to tensor's values by indexing also can be indefinite: print(x[10000000]) works fine.

How about ti.init(debug=True)? In debug mode that will give you a runtime error. We don't do bound checking in non-debug mode for performance considerations.

[vkurenkov]

Actually struct-fors are only supported in Taichi-scope. Sorry, the documentation was unclear about that.

Perhaps we should raise an exception or warn about an undefined behavior in this case? Having this in the documentation is a parallel issue, imo.

How about ti.init(debug=True)? In debug mode that will give you a runtime error. We don't do bound checking in non-debug mode for performance consideration

Thanks, it helped! By the way, there are only two mentions of the debug in the docs. The info about debug mode/flag is in the developers' section. I think it would be useful to announce it earlier in the user's section: prototyping is very prone to bugs, the first thing desirable is usually a correctness and only then the performance.

[yuanming-hu]

Perhaps we should raise an exception or warn about an undefined behavior in this case? Having this in the documentation is a parallel issue, imo.

Thanks, it helped! By the way, there are only two mentions of the debug in the docs. The info about debug mode/flag is in the developers' section. I think it would be useful to announce it earlier in the user's section: prototyping is very prone to bugs, the first thing desirable is usually a correctness and only then the performance.

I strongly agree! We have limited time and development efforts, therefore a lot of imperfections do exist in this project. Do you mind opening up PRs with these improvements? https://taichi.readthedocs.io/en/latest/contributor_guide.html

I'm happy to provide more info regarding the easiest way to raise the exception if you would join us.

[archibate]

My thoughts on infinite_loop:
Not sure why it becomes infinite, but I guess simply add Expr.__iter__ raising NotImplementedError should works?