You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now, upon a lookup failure, failure.rs outputs the correct advice columns and values, but chooses a random value in the lookup table (usually the first row it seems) to output as a comparison. While the set non-inclusion line gets the numbers of the fixed columns correct, the individual tables output for each value do not. It would be great if:
Instead of the first row of the lookup, it output instead the most likely row. For instance, you can select the row to display to be the one where the the first column matches its value in the corresponding lookup row. Even better, you could match to the column which has the most uniqueness (i.e. if i look up (6, 1, 1, 0) in a bit decomposition lookup table, it can calculate that 6 appears 1/n of the time, but 1, 1, 0 appear 1/2 of the time, thus it chooses the column with 1/n of the time matching as the one to index the lookup on). This heuristic is imperfect but at least more useful for debugging. Another alternative is to allow the developer to put a "hint" in their lookup, specifying the row in the lookup table that they think it should be at, which is the one that is output when debugging on failure.
In the table, instead of defaulting to F_ as the same number each time, make it actually the correct fixed column numbers that match the set-noninclusion line's column numbers.
The text was updated successfully, but these errors were encountered:
Right now, upon a lookup failure, failure.rs outputs the correct advice columns and values, but chooses a random value in the lookup table (usually the first row it seems) to output as a comparison. While the set non-inclusion line gets the numbers of the fixed columns correct, the individual tables output for each value do not. It would be great if:
Instead of the first row of the lookup, it output instead the most likely row. For instance, you can select the row to display to be the one where the the first column matches its value in the corresponding lookup row. Even better, you could match to the column which has the most uniqueness (i.e. if i look up (6, 1, 1, 0) in a bit decomposition lookup table, it can calculate that 6 appears 1/n of the time, but 1, 1, 0 appear 1/2 of the time, thus it chooses the column with 1/n of the time matching as the one to index the lookup on). This heuristic is imperfect but at least more useful for debugging. Another alternative is to allow the developer to put a "hint" in their lookup, specifying the row in the lookup table that they think it should be at, which is the one that is output when debugging on failure.
In the table, instead of defaulting to F_ as the same number each time, make it actually the correct fixed column numbers that match the set-noninclusion line's column numbers.
The text was updated successfully, but these errors were encountered: