Re: 100%

From: René Scharfe <rene.scharfe@lsrfire.ath.cx>
Date: Jun 24, 2007, 22:23 UTC
Message-ID: <467EEEDB.9030301@lsrfire.ath.cx>
In-Reply-To: <Pine.LNX.4.64.0706231318180.4059@racer.site>

Johannes Schindelin schrieb:

Show 13 quoted lines

> 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é