From: Johannes Schindelin <hidden> Date: 2016-06-15 22:43:17
Hi,
On Fri, 22 Jun 2007, David Kastrup wrote:
Johannes Schindelin [off-list ref] writes:
quoted
On Fri, 22 Jun 2007, David Kastrup wrote:
quoted
As a note aside: would it be possible to always round downwards when
computing similarities or converting between them?
I'd rather not. This would be counterintuitive. People expect rounded
values.
Which people?
Me, for one. Thank you very much.
The people I know will expect "100% identical" or even "100.0%
identical" to mean identical, period. They will be quite surprised to
hear that "99.95%" is supposed to be included.
Granted, 100.0% means as close as you can get to "completely" with 4
digits. But if you have an integer, you better use the complete range,
rather than arbitrarily make one number more important than others.
For if you see an integer, you usually assume a rounded value. If you
don't, you're hopeless.
Also, for any kind of decision made upon percentages, it is much more
relevant to be able to draw a line at 50% rather than at 49.5%.
I do see too many people in my day job who take the numbers they see for
absolute truths, so I cannot take that statement seriously, sorry.
Could you name a _single_ use case where rounding down could cause an
actual problem or even inconvenience for people?
Could you name a _single_ use case where it does not?
I mean, honestly, really. Really, really, really. A number is only a weak
_indicator_, and an integer even more so, for what is _really_ going on.
quoted
quoted
I very much would like to see the 100% figure reserved for identity.
This is particularly relevant when interpreting the output of
git-diff --name-status with regard to R100, C100 and similar flags.
You should never depend on the output of --name-status if you're
interested in identifying identical files, but on the object names.
Which is rather inconvenient.
Frankly, I am getting bored.
This argument crops up ever so often. "If you did that, _I_ could be more
lazy, and the _hell_ with other people who expect otherwise!".
No, really.
I _know_ that one can't rely on the output of --name-status right now.
And I _know_ that you can't rely on integer numbers. Or _any_ number which
is not _completely_ precise.
Really, I am getting bored with this discussion.
Ciao,
Dscho
From: René Scharfe <hidden> Date: 2016-06-15 22:43:17
Johannes Schindelin schrieb:
On Fri, 22 Jun 2007, David Kastrup wrote:
quoted
The people I know will expect "100% identical" or even "100.0%
identical" to mean identical, period. They will be quite surprised to
hear that "99.95%" is supposed to be included.
Granted, 100.0% means as close as you can get to "completely" with 4
digits. But if you have an integer, you better use the complete range,
rather than arbitrarily make one number more important than others.
For if you see an integer, you usually assume a rounded value. If you
don't, you're hopeless.
Why hopeless? It's a useful convention to define "100%" as "complete
(not rounded)". See it this way: 50% of the time, a given percent value
will be shown as one point less than it's "true" value, but you gain the
ability to indicate full completeness. And that's an interesting piece
of information. The price is small given that the needed accuracy is
more in the range of 10 percent points (I assume).
It's more a question of how to make sure everybody knows what the
numbers mean -- but that's why we have a directory named
"Documentation". :-D And even a person that hasn't read the docs is
unlikely to really get harmed by inexact percentages, right?
René
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:43:17
Hi,
On Sat, 23 Jun 2007, René Scharfe wrote:
Johannes Schindelin schrieb:
quoted
On Fri, 22 Jun 2007, David Kastrup wrote:
quoted
The people I know will expect "100% identical" or even "100.0%
identical" to mean identical, period. They will be quite surprised to
hear that "99.95%" is supposed to be included.
Granted, 100.0% means as close as you can get to "completely" with 4
digits. But if you have an integer, you better use the complete range,
rather than arbitrarily make one number more important than others.
For if you see an integer, you usually assume a rounded value. If you
don't, you're hopeless.
Why hopeless? It's a useful convention to define "100%" as "complete
(not rounded)".
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?
Ciao,
Dscho
From: René Scharfe <hidden> Date: 2016-06-15 22:43:17
Johannes Schindelin schrieb:
Hi,
On Sat, 23 Jun 2007, René Scharfe wrote:
quoted
Johannes Schindelin schrieb:
quoted
On Fri, 22 Jun 2007, David Kastrup wrote:
quoted
The people I know will expect "100% identical" or even "100.0%
identical" to mean identical, period. They will be quite surprised to
hear that "99.95%" is supposed to be included.
Granted, 100.0% means as close as you can get to "completely" with 4
digits. But if you have an integer, you better use the complete range,
rather than arbitrarily make one number more important than others.
For if you see an integer, you usually assume a rounded value. If you
don't, you're hopeless.
Why hopeless? It's a useful convention to define "100%" as "complete
(not rounded)".
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?
Because completeness is special. If just one bit was available, I'd use
it to indicate equality. That's what the authors of cmp(1) did, too. :)
And 0% is not special, at least not in a useful way that I can think of.
I.e. there is no practical difference between "no two lines match" and
"one percent of the lines match". If you're really interested in
similarities with an index below 10% then you'd better work with
absolute numbers instead of rounded percentages.
If someone came around with an interest in those cases with exactly 0%
similarity, then we might need to decide between rounding up or down.
But even in that hypothetical situation I think "equality" is still more
interesting a data point than "really everything differs".
René
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:43:17
Hi,
On Sat, 23 Jun 2007, René Scharfe wrote:
Johannes Schindelin schrieb:
quoted
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?
Because completeness is special.
I am not convinced. My vote is still for the _common_ practice of just
rounding. IOW keep it as is.
Ciao,
Dscho
From: René Scharfe <hidden> Date: 2016-06-15 22:43:17
Johannes Schindelin schrieb:
Hi,
On Sat, 23 Jun 2007, René Scharfe wrote:
quoted
Johannes Schindelin schrieb:
quoted
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?
Because completeness is special.
I am not convinced. My vote is still for the _common_ practice of just
rounding. IOW keep it as is.
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.
René
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:43:17
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.
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%.
Nuff said about this subject.
Ciao,
Dscho
From: René Scharfe <hidden> Date: 2016-06-15 22:43:18
Johannes Schindelin schrieb:
Hi,
On Sat, 23 Jun 2007, René Scharfe wrote:
quoted
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é