Since last year, ChatGPT3.5 released after the use of a few times, and now write code basically inseparable from it and its derivatives. On the one hand, it is very convenient to check the information, and quickly summarize the key points; on the other hand, if you want to write what kind of code can be generated by asking, the function is not bad, a little change can be used to greatly reduce the time to use the search engine is a new era of advanced version of the Ctrl + C/V.
However, the big language model is ultimately trained by the training set, it gives the code or to test their own use to be assured, for example, this time it was pitched.
Note: For various reasons, this paper only tests some large domestic language models and does not test ChatGPT.
original request
A list query function, the entry parameter contains a set of start and end dates, you need to check the start and end dates spanning less than or equal to 200 days.
The state of the art in front-end passing parameters
Converts the user-selected start and end dates (yyyy-MM-dd) into a string in the format "yyyy-MM-dd HH:mm:ss" with a start time of "yyyy-MM-dd 00:00:00" and an end time of "yyyy-MM-dd 23:59:59".
For example, if you select from 2024-09-01 to 2024-09-30 on the page, the actual entry parameters are "2024-09-01 00:00:00" and "2024-09-30 23:59:59". And for this set of parameters, the time span is 30 days, that is to say, including the first and last day.
Demand simplification
For testing purposes, I'll change the time span requirement to 2 days, for example, the time span from "2024-09-01 00:00:00" to "2024-09-02 23:59:59" is exactly 2 days. The requirement can be simplified as follows:
String sendDateBegin="2024-09-01 00:00:00"
String sendDateEnd="2024-09-02 23:59:59"
Java code to determine whether two days are less than or equal to 2 days
Kimi gave the results:
The code is extracted:
public static void main(String[] args) {
String sendDateBegin = "2024-09-01 00:00:00";
String sendDateEnd = "2024-09-04 23:59:59";
DateTimeFormatter formatter = ("yyyy-mm-dd HH:mm:ss");
LocalDateTime beginDate = (sendDateBegin, formatter); LocalDateTime endDate = ("yyyy-MM-dd HH:mm:ss");
LocalDateTime endDate = (sendDateEnd, formatter);
// Calculate the time difference
Duration duration = (beginDate, endDate);
// Get the days difference
long daysBetween = ();
// Determine if the number of days is less than or equal to 2
if (daysBetween <= 2) {
("The number of days between two dates is less than or equal to 2.") ;
} else {
("The number of days between two dates is more than 2.") ;
}
}
}
Problems found
Using the data set 2024-09-01 00:00:00~2024-09-02 23:59:59, the return results are as follows, and everything looks normal:
A different set of inputs 2024-09-01 00:00:00~2024-09-03 23:59:59 actually tells me less than or equal to 2 days as well, where is the problem?
analyze
Debugging the code a bit reveals that () is actually handled:
Takes the difference in seconds between two times and divides it by the number of seconds a day contains (86400), both arguments are of type LONG.
Then in this example, data that is more than 2 days old but less than 3 days old, due to long's division, discards the fractional part and compares it to 2: 2.999 ≈ 2, and 2 ≤ 2 is true. that's why the seemingly correct code actually introduces a bug.
And, even after alerting kimi that this code is buggy and informing the corresponding input, the answer given is still wrong.
The same question Tongyi Chien asked gives another solution, but the answer is still wrong:
And then look at Wenxin's words, half-assed:
settle (a dispute)
Since there is an error in comparing by day because of the loss of precision, converting the date to a millisecond comparison will not lose precision, using the following judgment.(beginDate, endDate).toMillis() <= (2).toMillis();
This example vividly demonstrates thatYou can't write code that is completely dependent on the big language model, and the tests that should be done should still be done.Of course, if you leave the writing of test cases to the big language model as well, it might be possible to detect bugs... ironic, isn't it?