Storing weights as int8 is only useful if they can be turned back into something a floating-point computation can actually use. 01-quantize-float32-to-int8's scale/zero_point are exactly the two numbers needed to invert that mapping — but the inversion is necessarily lossy: rounding to the nearest integer during quantization permanently discards whatever fraction of a "step" the true value didn't land exactly on.
Implement dequantize(q, scale, zero_point), which inverts quantize's forward mapping, and quantization_error(x, q, scale, zero_point), which measures how much information that round trip actually lost.
dequantize(q, scale, zero_point) returns a float array the same shape as q.quantization_error returns a single float: the maximum absolute difference between the original values and their reconstruction.q to a floating-point dtype must happen before subtracting zero_point — subtracting first, while still an int8 array, can silently wrap around on overflow.Open one at a time. Each gives away a little more than the last.
quantize's forward mapping was x / scale + zero_point. Inverting an "divide then add" is "subtract then multiply": (q - zero_point) * scale.
q.astype(np.float32) before doing any arithmetic on it avoids int8's wraparound overflow — np.int8(-128) - 100 wraps to a wrong, small positive number if computed in int8, but the correct large negative number once cast to float first.
No results yet
Run your code to check it against the examples, or submit to run every test.