[Bug] Fix infinite loop when exponent of integer pow is negative

[AD1024]

Related issue = fix #4661

[netlify]

✅ Deploy Preview for docsite-preview ready!

Name	Link
🔨 Latest commit	621236a
🔍 Latest deploy log	https://app.netlify.com/sites/docsite-preview/deploys/62cf9e7acfd38800097d97d9
😎 Deploy Preview	https://deploy-preview-5275--docsite-preview.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site settings.

[AD1024]

After several attempts to deal with the issue of losing accuracy, I decide to change from converting all pow to return floats to throwing exceptions when pow receives negative exponents when lhs is an integer (a la torch).
For some backends such as Vulkan (correct me if I'm wrong), we could not tell from pow with floats from those with ints if we make all pows to return floats. However, those backends depend on this information to decide whether to insert precision correction (e.g. Adding biases). Thus throwing exception is probably the 'right' way to fix this issue.

[strongoier]

Emm.. Why cannot we distinguish pow with floats from those with ints? IMHO we only need to change the return type without changing the input type. For example, we produce round(pow(f32(x), f32(y))) when x and y are i32s.

[AD1024]

Emm.. Why cannot we distinguish pow with floats from those with ints? IMHO we only need to change the return type without changing the input type. For example, we produce round(pow(f32(x), f32(y))) when x and y are i32s.

Yes, this is what we are trying to do. For Vulkan backend, if we cast everything to float, we couldn't tell whether we need to add the bias for rounding during codegen because it looks exactly like an ordinary floating point pow to the codegen.

Another thing we could try: instead of leveraging implicit type conversion, we pass the result to a round operator when both lhs and rhs are integer types (but round doesn't work for negative exponents).

[strongoier]

The API doc needs to be updated :-) FYI

taichi/python/taichi/lang/ops.py

Lines 731 to 760 in 0dfd166

	@binary
	def pow(x, a): # pylint: disable=W0622
	"""First array elements raised to powers from second array :math:`x^a`, element-wise.
	Negative values raised to a non-integral value will return `nan`.
	A zero value raised to a negative value will return `inf`.
	Args:
	x (Union[:mod:`~taichi.types.primitive_types`, :class:`~taichi.Matrix`]): \
	The bases.
	a (Union[:mod:`~taichi.types.primitive_types`, :class:`~taichi.Matrix`]): \
	The exponents.
	Returns:
	The bases in `x1` raised to the exponents in `x2`. This is a scalar if both \
	`x1` and `x2` are scalars.
	Example::
	>>> @ti.kernel
	>>> def test():
	>>> x = ti.Matrix([-2.0, 0.0, 2.0])
	>>> y = -2.2
	>>> z = ti.pow(x, y)
	>>> print(z)
	>>>
	>>> test()
	[-nan, inf, 0.217638]
	"""
	return _binary_operation(_ti_core.expr_pow, _bt_ops_mod.pow, x, a)

[strongoier]

LGTM!