Sigmoid export + several fixes
Add support for Sigmoid export, both in floating point and integer (using a lookup table in this case).
Right now, the integer version use the full range of the output data type and assumes the same data dynamic at the input. E.g. if the output is of type uint8_t
, the output range will map sigmoid output in [0.0, 1.0] to [0, 255], and assume the same input dynamic, meaning an input of 255 will correspond to 1.0. In this example, sigmoid(255) => sigmoid(1.0) = 0.73 => 186
.
If the output is signed, only the half output range is used, but the input dynamic stays the same. For int8_t
, sigmoid output in [0.0, 1.0] is mapped to [0, 127]. In this case, sigmoid(255) => sigmoid(1.0) = 0.73 => 92
. No rounding is performed at the output.
The integer version is implemented using a lookup table, of size N = half the output range (for uint8_t
or int8_t
the table will be N=128 elements), since the Sigmoid is a symetric function. The lookup table stores the first input value corresponding to each output index from 0 to 127. The index is then retrieved using binary search to find the lower bound of any given input value in the table. The complexity is log2(N) + O(1). The lookup table is generated at compile time. No floating-point operation is involved.
Of course, this behavior can be changed to match the use cases! @fabricea
In additions, this MR fixes the following issues found with #41 (closed):
- Bug with Pad CP model when output size is lower than input size;
- Bug with Reshape format registration, which cannot be any;