Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Optimize bit rate permutation search #495

Open
nfrechette opened this issue Jan 13, 2024 · 1 comment
Open

Optimize bit rate permutation search #495

nfrechette opened this issue Jan 13, 2024 · 1 comment

Comments

@nfrechette
Copy link
Owner

nfrechette commented Jan 13, 2024

We currently start with the smallest permutation in size, try every permutation at that size, then progressively increase the size. This guarantees that we find the permutation with the smallest size.

However, if the error decreases monotonically as size increases (more bits are added leading to better precision), perhaps we could use binary search instead of a linear search, dramatically speeding up the optimization pass. To that end, each group of permutations with the same size could be searched as a bucket and the buckets can use binary search.

If the error is sometimes smaller with less bits, the above will not hold true and binary search may yield a sub-optimal result. Depending on how close of an approximation it yields, perhaps it would be good enough. The full linear search could be used with the highest compression level (or high and above).

@nfrechette nfrechette added this to the v2.2 milestone Jan 13, 2024
@nfrechette nfrechette changed the title Use binary search for bit rate permutation search Optimize bit rate permutation search Apr 15, 2024
@nfrechette
Copy link
Owner Author

As it turns out, due to floating point rounding, once the error tapers off near its lowest value, adding more bits can sometimes cause the error to rise slightly. This can occur due to floating point rounding/noise. As such, our data is near but not quite sorted.

Perhaps we can leverage this in some other way. The error tapers typically when little accuracy is added which is when the noise creeps. For most joints, we would stop iterating and skip those permutations long before we reach them. This would be an issue only when the error tapers above our threshold.

We could perhaps search for a decent guess of the error by starting in the middle. We can then binary search to find our best permutation guess. It might not be the best one due to the issue above but once we have this permutation size and its error, we can search exhaustively more quickly by discarding most permutations at the first sample: most permutations that are larger will use fewer bits and yield a higher error. We could cache which permutations we tested and their error to avoid performing repeated work during the exhaustive search.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant