Precision error in output

[dl5415]

After parallelising inside the frame_to_object_stream function, we witness some precision error (6th decimal place) when comparing the events output to that of the benchmark. Should this be taken into consideration?

[jjd06]

This is something you can (should?) discuss in your report. Small errors here might not matter at all as far as the final output is concerned, or they might break everything. There might be a tradeoff between speedup and accuracy. Is there a knob potentially available for the client to tune this tradeoff according to their needs?

[AlexMontgomerie]

Is there any automated checking of correctness for any implementations? If so, are we given an error margin, and can we be told this margin before the deadline? Else, are scripts designed by us enough to validate the correctness of our implementation?

[jjd06]

I may run your code, and one of the things I may do as a result is compare the output to that of the reference. If it's completely wrong, that's clearly an issue, but if it's slightly different (due to e.g. instruction reordering, whether done explicitly or allowed to happen through the introduction of parallelism) then that should be discussed. So: it doesn't matter if the outputs differ, so long as you can explain why and, even better, if you can explain what that means in terms of application-level output.

[dl5415]

Thanks for the clarification. For outputs, are you referring to the .events files or the final mjpeg files. Because the output events may differ after speed-up, but the detected objects in the mjpeg files are consistent.

[jjd06]

The *.events files are the application-level outputs.