[Note: parts of this message were removed to make it a legal post.]
There you see why posting in a hurry is a bad idea. Thanks for catching
that.
For what they are worth (which is very little as I distrust benchmarks which
haven't been run sufficiently many times to generate reliable standard
deviations, not to mention my Windows Vista installation doing even more
apparently random and purposeless disk i/o than usual) these benchmarks
suggest that (ignoring the minor bug!) multiple_off? was usually slightly
slower than multiple_of? on my system about two hours ago!
ruby 1.9.1p243 (2009-07-16 revision 24175) [i386-mingw32]
each benchmark is a 1_000_0000.times run;
user system total real
num= 72 denom= 13
multiple_of? 0.921000 0.000000 0.921000 ( 1.012000)
multiple_off? 0.967000 0.000000 0.967000 ( 1.177000)
multiple_of? 0.827000 0.015000 0.842000 ( 0.992000)
multiple_off? 0.983000 0.000000 0.983000 ( 1.110000)
num= 72 denom= 12
multiple_of? 0.874000 0.000000 0.874000 ( 1.072000)
multiple_off? 0.967000 0.000000 0.967000 ( 1.182000)
multiple_of? 0.936000 0.000000 0.936000 ( 1.090000)
multiple_off? 1.030000 0.000000 1.030000 ( 1.156000)
num= 0 denom= 0
multiple_of? 0.874000 0.000000 0.874000 ( 1.108000)
multiple_off? 0.780000 0.000000 0.780000 ( 1.004000)
multiple_of? 0.827000 0.000000 0.827000 ( 1.122000)
multiple_off? 0.889000 0.000000 0.889000 ( 1.043000)
num= 72 denom= 0
multiple_of? 0.905000 0.000000 0.905000 ( 1.114000)
multiple_of? 0.936000 0.000000 0.936000 ( 1.088000)
multiple_off?
#<ZeroDivisionError: divided by 0>