(Bucketing) Selected point not showing up on all error plots with multiple variables

[jaelafield]

Currently, selecting a point on the error plot for one variable doesn't always cause a point to select on error plots for other variables in the expression:

• Need to diagnose further, but current guess is caused by bucketing values (required in compressing received data points to pixels to render).
• Could try maintaining set of bucket values, searching for the 'y' for a selected 'x' and selecting the point for the bucket containing the 'y'

(@elmisback let me know if I misunderstood your explanation + solution idea)

[elmisback]

That's roughly correct! For now you can think of the buckets as being applied like so:

Say we have 10 X values, [1, 2, 3, 4, 5, 6, 7, 8, 9, 10], but we can only show 2 values. Bucketing evenly, we have two sets: [[1, 2, 3, 4, 5], [6, 7, 8, 9, 10]]. We just take the head of each bucket for display: [1, 6]. But we'd like to maintain the whole list of buckets so we can look values inside the buckets up. This can be done by saving the lists somewhere or by regenerating the buckets when we need to look them up, since the process is deterministic.

[jaelafield]

In 1:1 8/27, made an implementation plan with Edward:

• Add an additional check before displaying a point as selected: if the point is the "representative" for the bucket the selected point is in
• First sort the values for the variable
• Find the index of the selected point
• Compare that index to that of each point to see if they'd be in the same bucket

I've implemented a first attempt at this plan, now just debugging and trying to get it right!

[jaelafield]

The current bug is that const pIdx = dataPoints[expIdx].indexOf(pValue); always results in -1 for pValues of the second variable in an expression (e.g. 'y' of 'x+y').

This occurs even though the value is clearly contained in the dataPoints collection. (As it must be, since dataPoints is extracted from the same list used to plot the actual points.) Example:

It seems like it must be an equality issue, so I tried our idea of comparing in float form, rather than ordinal. Strangely though, this isn't a problem for the first variable, only the second (or 3rd, etc), regardless of float vs ordinal.

[jaelafield]

Resolved in 50dc5e5!

See final bug fix description here.

[jaelafield]

Done (one last fix was added), can be merged into main with go-ahead!