Hi, On Sat, 23 Jun 2007, Junio C Hamano wrote: > Johannes Schindelin <Johannes.Schindelin@xxxxxx> 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 - 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
