Hi Folks,
the computer system I work on (as a programmer) deals, among other things, with material quantity conversions.
So, in a stock control context, a certain mass of a material may be stored as a value in kilograms. However, an operator may request the same value expressed in pounds, which is not stored directly.
To automatically make the conversion, the system stores a numerator and a denominator for each unit, and these are used where required to give the output in alternative units.
Easier if I give an example:
Material 'red paint' has a current stock of 5.00kg. The conversion factors are stored as follows:
Unit Numerator Denominator
KG 1 1
LB 71701 32523
If I request the stock to display in kilograms, the system will calculate the result as (5.00 * 1 / 1) = 5.00 kg
If I request it in pounds, the system will calculate the result as (5.00 * 71701 / 32523) = 11.023 lb.
Those of you familiar with Imperial/SI units will probably have spotted that 71701/32523 is 2.20462, the 'standard' conversion factor from kilos to pounds.
So what's the problem? It's this:
The computer system can only store the numerator/denominator values as integers, each with a maximum of 5 digits. Don't ask, I didn't design it, and it isn't something that can be changed.
Therefore, all the stored conversion factors have to be the quotient of a divisor and dividend that are both held as integers.
For new data, this is harder than it sounds. If someone gave you the value 2.20462 and asked you to express it as the quotient of two unknown integers (max 5 digits each), you might have to scratch your head. Especially if the target value could be the result of more than one division calculation.
I could write a program to figure this out for any quotient (and I'm sure you could too), but it would be inefficient and rely on number crunching. What I'm after is a more elegant and efficient way of arriving at the desired result.
Example 2: I need a conversion factor from kg/m2 (kilograms per square metre) to ft2/lb (square feet per pound). The required conversion factor, expressed as a decimal, is 0.2048146. BTW, these units are real, and are applied in the context of mass coverage (think of paint).
Because of the 5 digit restriction, the value resulting from the calculation may not be exact; but we do need it to be as accurate as possible. If I programmed it, in my inefficient, number-crunching way, the logic would have to be recursive, so as to get nearer to my 'perfect result' until the possibilities were exhausted.
But there may be a better way, which is why I've posted this.
To sum up (per example 2 above), a/b = 0.2048146, where a and b are positive integers, max 5 digits each. How close is it possible to get with a single division calculation? Can we get closer using 2 calculations with 4 unknowns e.g.: a/b * c/d = 0.2048146 ?
Thank you for reading and (I hope) understanding.
Best regards,
A non-mathematician.
the computer system I work on (as a programmer) deals, among other things, with material quantity conversions.
So, in a stock control context, a certain mass of a material may be stored as a value in kilograms. However, an operator may request the same value expressed in pounds, which is not stored directly.
To automatically make the conversion, the system stores a numerator and a denominator for each unit, and these are used where required to give the output in alternative units.
Easier if I give an example:
Material 'red paint' has a current stock of 5.00kg. The conversion factors are stored as follows:
Unit Numerator Denominator
KG 1 1
LB 71701 32523
If I request the stock to display in kilograms, the system will calculate the result as (5.00 * 1 / 1) = 5.00 kg
If I request it in pounds, the system will calculate the result as (5.00 * 71701 / 32523) = 11.023 lb.
Those of you familiar with Imperial/SI units will probably have spotted that 71701/32523 is 2.20462, the 'standard' conversion factor from kilos to pounds.
So what's the problem? It's this:
The computer system can only store the numerator/denominator values as integers, each with a maximum of 5 digits. Don't ask, I didn't design it, and it isn't something that can be changed.
Therefore, all the stored conversion factors have to be the quotient of a divisor and dividend that are both held as integers.
For new data, this is harder than it sounds. If someone gave you the value 2.20462 and asked you to express it as the quotient of two unknown integers (max 5 digits each), you might have to scratch your head. Especially if the target value could be the result of more than one division calculation.
I could write a program to figure this out for any quotient (and I'm sure you could too), but it would be inefficient and rely on number crunching. What I'm after is a more elegant and efficient way of arriving at the desired result.
Example 2: I need a conversion factor from kg/m2 (kilograms per square metre) to ft2/lb (square feet per pound). The required conversion factor, expressed as a decimal, is 0.2048146. BTW, these units are real, and are applied in the context of mass coverage (think of paint).
Because of the 5 digit restriction, the value resulting from the calculation may not be exact; but we do need it to be as accurate as possible. If I programmed it, in my inefficient, number-crunching way, the logic would have to be recursive, so as to get nearer to my 'perfect result' until the possibilities were exhausted.
But there may be a better way, which is why I've posted this.
To sum up (per example 2 above), a/b = 0.2048146, where a and b are positive integers, max 5 digits each. How close is it possible to get with a single division calculation? Can we get closer using 2 calculations with 4 unknowns e.g.: a/b * c/d = 0.2048146 ?
Thank you for reading and (I hope) understanding.
Best regards,
A non-mathematician.
