On Thu, Sep 25, 2014 at 5:56 AM, Dave Angel <da...@davea.name> wrote: > Your definition is not nearly as concrete as you think. Is the > first number considered to be exact, and we'll only check the > second? Will the factor always be an int, and thus > exact?
Apologies: the definition is concrete, just under-specified in the post. No, both numbers are inexact; most notably, one third of the factor might be involved - both of these should be correct: ["1.333", "40"] ["1.33", "40"] But if it's easier to assume that one or t'other must be exact, that's fine too - I can just run the check twice, once each way. > When the desired second number is exactly halfway between two > values, is rounding down as acceptable as up? > (Eg, exact answer 142.75, acceptable 142.7 and 142.8) Yes, either would be accepted. > Once you're sure of the goal, it's a question of whether the > decimal package can handle it. I would be inclined to do it in > two stages. Drop all the periods and convert each to int (long). > Multiply and Add 5**n, where n is related to the length of the > target. Convert to string, padded with lots of zeroes. > > > See if the exact string begins with the target. If not, they're > not close enough. > > If the first part passes, you just have to check the position of > the decimal point. > > Or you could check the implementation of round. If you pick the > right value for round, you could do an exact comparison. > > > Alternatively, if you're just looking to catch typos, it could > be simpler. Or if you put constraints on the numbers > involved. It is just to catch typos. I don't mind if it misses some cases, not a big deal. Thanks for the suggestion. I'll see how that looks in code. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
