Re: 100%

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

Hi,

On Sat, 23 Jun 2007, Junio C Hamano wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> > By the same reasoning, you could say "never round down to 0%, because I 
> > want to know when there is no similarity".
> >
> > You cannot be exact when you have to cut off fractions, so why try for 
> > _exactly_ one number?
> 
> R0 or C0 would not happen in real life, so 0% is a moot issue.

It is, but not when you look at the formula.

> However, wasn't that you who did follow that "certain numbers
> are special" logic in diffstat?
> 
> You advocated "diff --stat" should draw at least one +/- for a
> patch that adds/removes lines.  And I (and others) agreed
> because zero is special in the context of that application.

Actually, it was not me, but I implemented the version that we have now. 
I was reasonably scared that a non-linear diffstat would end up in git, 
therefore I wrote a linear one.

The important thing to not here is that the diffstat as-is makes _better_ 
use of the limited scale that is available.

And as you pointed out, the low end of the scale is not really 
interesting. The interesting parts are those around 100%. By rounding down 
you make less use of the available scale.

> I think reserving R100 to mean "identical byte sequences" has value, 
> when people look at --name-status output, in the context of "similarity 
> index".

Ah, whatever. You do what you want.

Yes, this interpretation has value. No, it is not the only one that has 
value. I am much more used to rounding, since at the end of the day it 
makes better use of the scale, it is commonly used, and therefore _I_ 
expect it (and no, I will not read the documentation when I expect to know 
what it means).

But hey, I don't care any more. AFAIAC you can change it from rounding to 
rounding down, and next year to rounding-up. We could even have an 
algorithm which rounds down only in odd years, and I still would not care.

Ciao,
Dscho