Why is the DOI of a logging statement is 0?

[khatchad]

Our tool suggested, as part of a pull request, that this log level be converted from FINE to FINEST. After using both N=1,000 and N=24,000, the DOI of the logging statement is 0:

sequence	subject	log expression	start pos	log level	type FQN	enclosing method	DOI value	action	new level
1557327791554	client	log.fine("Polling " + url)	2942	FINE	org.openqa.selenium.net.UrlChecker	waitUntilAvailable(long,java.util.concurrent.TimeUnit,java.net.URL[])	0	CONVERT_TO_FINEST	FINEST
1557331211590	client	log.fine("Polling " + url)	2942	FINE	org.openqa.selenium.net.UrlChecker	waitUntilAvailable(long,java.util.concurrent.TimeUnit,java.net.URL[])	0	CONVERT_TO_FINEST	FINEST

More information about the run:

sequence	repo URL	SHA-1 of head	N for commits	number of commits processed	actual number of commits	average Java lines added	average Java lines removed
1557327791554	https://github.com/SeleniumHQ/selenium.git	8389311401473048c215f0885dc5dc5488a311eb	1000	1000	23812	30.311	15.343
1557331211590	https://github.com/SeleniumHQ/selenium.git	8389311401473048c215f0885dc5dc5488a311eb	24000	23812	23812	30.311	15.343

Please investigate why the DOI of this log statement is 0. There are several changes to the enclosing method (listed below), so I am sure that it hasn't been 0 always. Does it start at 0, increase, and then because of decay, decrease? Or, are we losing track of it through some refactoring?

Here are some changes that involve the enclosing method. They are listed from most recent to least recent:

1. SeleniumHQ/selenium@715f012
2. SeleniumHQ/selenium@f782d2b
3. SeleniumHQ/selenium@6fc11aa
4. SeleniumHQ/selenium@3db6451

[khatchad]

What do the axes mean here?

[yiming-tang-cs]

What do the axes mean here?

Updated.

[khatchad]

This has been opened way too long and should be fixed ASAP.

[yiming-tang-cs]

For now, if a method is not analyzed before, it should not be considered by the tool. The only 0 in the candidate CSV represents that the enclosing method is analyzed before but its analysis is in a very early commit.

The current results (N = 24000):
results_original_decay.zip

[yiming-tang-cs]

The method was analyzed but its DOI value became 0 due to decay, like the cases you mentioned above. The charts below track the DOI value changes for the method waitUntilAvailable().

Decay = 0.0085:

Decay = 0.00053125

For these methods, lowering decay could fix this issue. It is fixed by #232

[yiming-tang-cs]

These are DOI values of candidates for selenium:

N = 24000, decay factor is 256. Most of their DOI values are positive now. Only a few of them are 0. The method you mentioned above has a positive DOI value now.

[yiming-tang-cs]

This is the chart of DOI values for candidates with the original decay factor. As we can see, most of their DOI values are 0, including the method you mentioned above.

[yiming-tang-cs]

Currently,

1. when N = 1000, the log invocation mentioned above is not a candidate and is not transformed.
2. when N = 24000, the log invocation mentioned above is transformed to INFO.

[khatchad]

Please respond to the original PR. Explain the change that we've made and that we will follow up with a new, improved PR, but will not include the results that were already rejected by the previous PR. Make sense?

[khatchad]

@saledouble What is the status of this issue?