Skip to content

Commit

Permalink
Rearranged type promotion docs
Browse files Browse the repository at this point in the history
  • Loading branch information
jim19930609 committed May 6, 2022
1 parent 9c1a388 commit 3f01e25
Showing 1 changed file with 25 additions and 22 deletions.
47 changes: 25 additions & 22 deletions docs/lang/articles/basic/type.md
Original file line number Diff line number Diff line change
Expand Up @@ -100,30 +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 mostly 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:

Note that in C++: `i8 + i8 = i32`, which makes no sense to Taichi use cases. Therefore we implemented our own rules for this kind of operations:
```
i8 + i8 = i8
i8 + i16 = i16
i8 + u8 = u8
i8 + u16 = u16
i16 + i8 = i16
i16 + i16 = i16
i16 + u8 = i16
i16 + u16 = u16
u8 + i8 = u8
u8 + i16 = i16
u8 + u8 = u8
u8 + u16 = u16
u16 + i8 = u16
u16 + i16 = u16
u16 + u8 = u16
u16 + u16 = u16
```
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

0 comments on commit 3f01e25

Please sign in to comment.