If we list all the natural numbers below 10 that are multiples of 3 or 5, we get 3, 5, 6 and 9. The sum of these multiples is 23.
Find the sum of all the multiples of 3 or 5 below 1000.
Chloe’s LabView submission was the most efficient. It was the fastest executing of all submissions. What makes it so fast? Compared to the other student submission, the “For” loop doesn’t have to test for an end condition or explicitly calculate an index every time. What makes this entry the fastest overall is the lack of the conditional indexed terminal on the for loop. Specifically, the conditional terminal behaves in two separate ways (contexts), depending on the value of a boolean input. This entry puts a new integer into the array every time through the for loop, meaning it does not have to switch contexts.
On documentation, this entry is a mix of good and really bad. There are a lot of blocks of comments which would normally be good. Unfortunately, few of them make sense (2 out of 9). This entry does not win on documentation.
The guts of Chloe’s submission are essentially the same as the other student submission. By not using a “While” loop, she was able to shave off two operators, making her submission the winner this week for code compactness.
Justin’s LabVIEW submission was the least efficient. It was the slowest executing of all submissions, around 5.9x slower than the other student submission. What makes it so slow? Just about everything between the shift register terminals at the top. Shift registers have a lot of overhead, and needing to compare the value stored there against a zero floor, every time through the loop. This slows down the execution of the code.
On documentation, this entry is a mix of OK and really bad. The comment box outside the loop is nonsense, and the inner comment while containing some relevant information, misses the point of code documentation. The word “I” should never be found in a code comment. Comments are to document the code as written. The code is the subject, not the programmer. This entry does not win on documentation, either. No documentation winner for LabVIEW code.
Our first mentor submission comes from Joe. With five operations and two loops, it was by far the most compact entry this week. His entry uses clean integrated documentation in the loop descriptions, and self-documented naming in labels. These are good practices.
While compact, this code took some hits in execution speed. It was 3.94x slower than Chloe’s entry.
The only student entry this week (dubious default winner of efficiency, documentation, and compactness) was Justin. This code works, but is too inefficient to really give weight to it’s winning status. Specifically,, if your code can detect that it has erroneously added a number twice, then it shouldn’t double add the number in the first place, and shouldn’t need to subtract the number to correct the problem that shouldn’t have happened.
This code runs about 1.5x slower than the mentor submission.
This entry speaks quite well for itself.
It should be noted that Python is an interpreted language, where LabVIEW is a compiled language. This code ran 34x slower than the fastest LabVIEW code to do the same thing! There are ways to greatly increase the speed of Python programs through compilation, Such methods are not guaranteed and take a lot of additional work. Those potential speedups were not tested here.