>>>>>Wouldn't
>>>>>

lnNominator = 2^(int(LEN(RTRIM(STR(lnFrac,15,15),"0")*log(10)/log(2)))+1)

>>>>>be more correct? Because for three decimal digits you need two to the power of ten to have your error below 0.001... and 3*log(10)/log(2) is 9.9658, and the +1 there gives you 10.
>>>>
>>>>My code is only valid for fractions that have nominators in powers of 2. 1/2; 1/4;/1/8;...
>>>>So 0.1 is not a valid paramater.
>>>>Bill only likes to transform those, and for that you only need the number of digits.
>>>>IOW decimal fraction of 1/(2^n); n in {0;1;2;3;..} will fit into n decimal places
>>>>
>>>>Edit:
>>>>There should be no precision problem. numbers base 10 and base 2 both can store such fractions wihout any loss in precision (IOW they will not become periodic), since both work with 2 in there base.
>>>
>>>Ah, but life isn't fair... You assume you have such values, but what if the values come from measurements? With my addition you get to round any set of decimals to a fraction with a 2**n denominator to the same precision you had with the decimals, with perhaps +/- 1 error on the last digit.
>>
>>I think he does prefab paper.
>>If the values are not in this, it is cheaper to have a translation table, since those values do not need to be exactly translated, they are more nominal. Customer likes to see its expected named paper, even if it is a bit wrong.
>
>
>Yes, you have to MAKE life be fair.
>That industry only deals with1/2, 1/4, 1/8 etc, as a convention.
>Another client makes rectangular covers for swimming pools.
>In that industry there is no measurement that is less than one inch- also by convention- so I carry all dimensions as feet and inches and print them as, for example, 11'6"X10'8".
>I could have carried them as inches, and that would have made some calculations simpler, but I opted for feet and inches to simply things like data binding, reports, etc.

SI based units are worth it. :)