Jérôme M. Berger Wrote: > Jérôme M. Berger wrote: > > OK, I found a solution that is optimal in over 99% of the cases > > (99.195% to be precise), while still being fast (because it avoids > > looping over the bits): > > > I've run my function and Andrei's on all possible min, max pairs in > 0..299 without checking, just for the timing. On my computer (Athlon > X2 64 @2GHz), my function took 50s and Andrei's took 266s. The > difference should be even bigger for larger numbers.
Can I ask, what is the point of having a non-exact solution (unless you are just doing this for fun)? We are talking about range propagation, a function of the compiler, not a function of the compiled program. Therefore, slower but more exact functions should be preferred, since they only affect the compile time. Note that you will only need to do this range propagation on lines that "or" two values together, and something that reduces the runtime of the compiler by 216 seconds, but only when compiling enough code to have over 8 billion 'or' operations in it (300^4), I don't think is really that important. Give me the exact solution that prevents me from having to cast when the compiler can prove it, even if the runtime of the compiler is slightly slower. Just my $.02 -Steve
