0 to 1 output (binary_crossentropy) about nnom HOT 3 OPEN

If you are using the current Master branch, there is a bug in getting prob. The latest 0.4.x-dev branch should have correct this.
The below code is corrected version.

If you want to stay with the current master branch:
After running the model, you may check the raw output to see the value which is in nnom_output_data[0].

Since you are using the sigmoid as the final layer, the value will be q0.7 format which means that decimal bit is 7.
So we are expecting the range from 0~127 to represent 0-1.

from nnom.

Thanks you but i check the bug and is only for multiple output and i have try with dev-0.4.x same result
But i have found some value with float model ouput = >0.5 <1 and optimized model = 1

Then i thinks is a other probleme (nnom_output_data[0] return 0 or 127 never other value)

Maybe is only my model loos many accurate with int8 optimization..

#1 Input - - ( 1, 92, 6,) ( 552, 552, 0) 1 - - - - - - -
#2 Conv2D - ReLU - ( 1, 82, 487,) 2.63M ( 552, 39934, 0) 1 1 - - - - - -
#3 MaxPool - - ( 1, 41, 487,) ( 39934, 19967, 0) 1 1 1 - - - - -
#4 Conv2D - ReLU - ( 1, 35, 20,) 2.38M ( 19967, 700, 0) 1 - 1 - - - - -
#5 MaxPool - - ( 1, 17, 20,) ( 700, 340, 0) 1 1 1 - - - - -
#6 Flatten - - ( 340, ) ( 340, 340, 0) - - 1 - - - - -
#7 Dense - Sigmoid - ( 1, ) 340 ( 340, 1, 680) 1 1 1 - - - - -
#8 Output - - ( 1, ) ( 1, 1, 0) - 1 - - - - - -

I think the Flatten to Dense can be lose many accurate a error of 1 in 340 value can be do a big error
I do test with other model

from nnom.

The 0/127 results might caused by the sigmoid was forced to saturate the output because the num of the integral bit of the dense's output data is > 3, e.g. if int = 4, then the dec bit is 7-4=3. In the cmsis-nn's (also the local backend) tanh and sigmoid, they don't support this number so we have to saturate the output to 1 and 0 (for sigmoid).

You can use model_io_info() to list the Q format and see if the output of the dense int bit is > 3.

If it dose, there is not much we can do now to get better resolution, unless 16bit or float but they are not yet implemented.
340 to one might cause the value too large. you can try to add another dense with smaller num between.
Or try not to use activation. just use the raw dense output.

from nnom.