Johannes Schindelin schrieb: > Hi, > > On Sat, 23 Jun 2007, René Scharfe wrote: > >> As I already hinted at, the common result of comparing two files, as >> done by e.g. cmp(1), is one bit that indicates equality. This >> information is lost when using up/down rounding, but it is retained when >> rounding down. It's _not_ common to be unable to determine equality >> from the result of a file compare. > > And as _I_ already hinted, this does not matter. The whole purpose to have > a number here instead of a bit is to have a larger range. In practice, I > bet that the 100% are really uninteresting. At least here, they are. You would lose your bet since both David and me expressed interest in that pure 100% thing. Rounding down instead of up/down doesn't affect the size of neither the input nor the output range. It affects the boundary of the input range, (-0.499 .. 100.499 versus 0.000 .. 100.999), but I can't find a problem with that. > For example, if you move a Java class from one package into another, you > have to change the package name in the file. Guess what, I am perfectly > okay if the rename detector says "100% similarity" here. Because if it is > closer to 100% than to 99%, dammit, I want to see 100%, not 99%. That uses a side effect of rounding and won't work for small files. And of course (if the file is large enough) there could be other changes "hidden" in a similarity index value of 100% that was rounded up. > Nuff said about this subject. Yes, let's advance this topic to the coding stage. René - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
