round_to_fixed about deepshift HOT 4 CLOSED

I apologizie for my late response. It is my pleasure that you find the work interesting!
Please give me till the weekend to respond to you.

from deepshift.

I am copying and pasting below the function that implements round_to_fixed.

The point is that the upper and lower limits of the result of the function are not [-1, +1]. In fact they are approximately [-2^15, 2^15].

Fixed point representation is similar to the decimal value system we were studying at elementary school: we have whole number bits and fraction bits. Since we are using 32-bit representation, I have a llocated here by default 16 (out of the 32-bits) for the whole number and the remaining 16-bits for the fraction.

I think this article may help to explain Fixed Point format: https://www.electronicdesign.com/technologies/embedded-revolution/article/21805517/whats-the-difference-between-fixedpoint-floatingpoint-and-numerical-formats

Please don't hesitate to tell me if this is not clear.

def round_to_fixed(input, fraction=16, integer=16): 
    assert integer >= 1, integer 
    if integer == 1: 
        return torch.sign(input) - 1 
    delta = math.pow(2.0, -(fraction))
    bound = math.pow(2.0, integer-1) 
    min_val = - bound 
    max_val = bound - 1 
    rounded = torch.floor(input / delta) * delta

    clipped_value = torch.clamp(rounded, min_val, max_val)
    return clipped_value 

from deepshift.

Thanks for your kind explanation. So the input parameters to this function, i.e., fraction and integer, denote the number of bits allocated for fraction and integer part respectively, and therefore leads to a 32bit fixed-point representation. Now I understand how this function worked.

Thanks again for your reply.

from deepshift.

@msxiaojin : you are correct. I see that the names of the arguments, fraction and integer, are misleading.
I will change them to fraction_bits and integer_bits to avoid confusion.

from deepshift.