Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[doc] Updated documentations for implicit type casting rules #4885

Merged
merged 2 commits into from
May 10, 2022
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
29 changes: 26 additions & 3 deletions docs/lang/articles/basic/type.md
Original file line number Diff line number Diff line change
Expand Up @@ -100,10 +100,33 @@ As a rule of thumb, implicit type casting is a major source of bugs. And Taichi

#### Implicit type casting in binary operations

Taichi follows the [implicit conversion rules](https://en.cppreference.com/w/c/language/conversion) for the C programming language and implicitly casts operands in a [binary operation](https://en.wikipedia.org/wiki/Binary_operation) into a *common type* if the operation involves different data types. Following are two most straightforward rules for determining the common type in a binary operation:
Taichi implements its own implicit type casting rules for binary operations, which are slightly different from [those for the C programming language](https://en.cppreference.com/w/c/language/conversion).

- `i32 + f32 = f32` (`int` + `float` = `float`)
- `i32 + i64 = i64` (low precision bits + high precision bits = high precision bits)
In general we have three rules with descending priority:

1. integral OP floating_point -> floating_point
- `i32 + f32 -> f32`
- `i16 + f16 -> f16`

2. low_precision_bits OP high_precision_bits -> high_precision_bits
- `i16 + i32 -> i32`
- `u8 + u16 -> u16`

3. signed OP unsigned -> unsigned
- `u32 + i32 -> u32`
- `u8 + i8 -> u8`

For conflicting rules, only the highest priority one will be applied.
- `u8 + i16 -> i16` (rule #2 conflicts with rule #3: apply rule #2)
- `f16 + i32 -> f16` (rule #1 conflicts with rule #2: apply rule #1)

A few exceptions:
1. bit-shift operations: always follow lhs's dtype
- `u8 << i32 -> u8`
- `i16 << i8 -> i16`

2. logical operations: always return i32
3. comparison operations: always return i32

#### Implicit type casting in assignments

Expand Down