Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
fix rounding error with ScreenEval's scatter plot
Previously, I was rounding offset values to 3 decimal places before storing them in the SL table for later retrieval on ScreenEvaluation. This was problematic! For example, if a particular offset was -0.04250000, it should be categorized as a W2 judgment (ITG excellent), but by rounding it to three decimals it would become -0.043, which would be a W3 (ITG great). Thus, this commit changes JudgmentOffsetTracking.lua to store the full, un-rounded offset values in the order they occur in the sequential_offsets table within the SL table. This *should* resolve the scatter plot issue in which judgments on the edge of a TimingWindow could be rounded into the next-worse-TimingWindow. - - - - - Still, for ScreenEvaluation's histogram, the data is easier to process when there is a finite quantity of decimal places per offset value (three, currently). This is because I need to know how many of each offset a player earned which is represented by how tall the histogram is. How many +0.001 offsets? How many -0.001 offsets? How many +0.002 offsets? How many -0.002 offsets? Etc. Statistical buckets, if you will. For the histogram then, instead of rounding, I'm currently opting to truncate everything beyond three decimal places by multiplying by 1000 math.floor diving by 1000 But! Some TimingWindow boundaries need at least four digits of precision (W1 for Competitive is 0.0215 for example). So this system of truncating past three digits so we can organize offsets into buckets for the histogram is flawed. I intend to think about and investigate options here soon. The easy solution is to increase the histogram's "resolution" to 4 decimal places, which would mean 10x as many buckets, and 10x as many bars being drawn in the ActorMultiVertex. Performance could be an issue.
- Loading branch information