Euclidean Division to avoid need for floating point arithmetic

Question

In simple terms (that Google has been unable to provide the answer), is there an approach to dividing a whole integer by a quotient & remainder?

As a specific example,

89620 / ( 448105 / 10000 )
= 89620 / 44 remainder 8105
= ? Further computation

The ideal result will be a single quotient and remainder.

My problem in detail: I'm writing embedded software for a weighing machine. We read a 24-bit number from an analogue to digital converter connected to a load cell, and use our own stored calibration parameters to derive a weight value, according to the following equation:

Weight = ((Analog - CalZero) * CalWeight ) / (CalFull - CalZero )

Weight: The resulting weight, in units according to CalWeight.
Analog: The raw analog value.
CalZero: The analog value when there is no load.
CalFull: The analog value with the calibration weight applied to the loadcell.
CalWeight: The calibration weight, in its own units.

The embedded platform we're using only supports integer types up to 32-bits which is not adequate to store the large numbers computed in this equation, so we're currently resorting to using floating point represenations, even though the result is cast to a 32-bit integer anyway, and this is somewhat inefficient.

I'm exploring ways of removing the need to use floating point numbers, and am considering Euclidean division as an option and thus trying to broaden my knowledge of it's application. The other option seems to be writing our own 64-bit integer operations in assembler, which is ugly; or just accept the performance penalty of using floating point that we are currently incurring.

Answer 1

I suppose the calibration is done offline, or with the help of some more capable hardware.

If so, a natural solution would be to precompute $\frac{\mathit{CalWeight}}{\mathit{CalFull}-\mathit{CalZero}}$ during the calibration and store it as a fixed-point number, so you can just multiply by $\mathit{Analog}-\mathit{CalZero}$ and then shift the result to the right.

Doing the multiplication as 32 bits will make most of the precision in the 24-bit input go to waste, so you don't want to do that unless relative roundoff errors of about 1% are tolerable. But even if you need more precision, it's a lot easier to craft a long multiplication from smaller ones than to do a division.

I'd store the calibration factor as a 12.24 bit fixed-point number and do popsicle stick multiplication in base $2^{12}$. Then native 32-bit arithmetic will be long enough to compute each of the six single-digit multiplications, and to keep track of carries within each column without overflowing.

If the target platform has hardware floating point (even just single precision), that will still be more efficient, though.