-
Notifications
You must be signed in to change notification settings - Fork 144
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
sublime.score_selector #241
Comments
Probably similar to how syntect's works just using a u64 for storage whereas I think syntect uses an f64. It's not important, I don't see any reason to replicate Sublime's values, the values are pretty meaningless only the order is important which should be the same as Sublime. Closing this issue. |
Y, you've got a point there, definitely what's important here is the order... that said, one good rule of thumb when it comes to algorithm design is always trying to favour integer instead floating point arithmetic, which in many cases it'll be possible. |
I used floating point for a reason, because it's more correct. Pretty sure it can handle more levels of nesting with reasonable accuracy than Sublime's method. It's also really fast and not the bottleneck, I do profile. |
I see, in any case the main purpose of this thread was just to know if you knew how Sublime's worked, that's all. It seems you don't but you claim your method is more correct... why is that? On which cases you know for sure Sublime's will fail while yours won't? That said, if your algo covers all cases and it's not a bottleneck then is fine, as for me as I always strive to find the best solutions for particular problems and figuring out how other's work is a good first step so I can compare between them. Unfortunately, I haven't been able to use the debugger to break in |
Pretty sure both my scheme and Sublime's use a scheme where the most significant digits represent the most significant scopes for the purpose of the matching, and then more digits mean deeper matching. You'll note that around 27 deep Sublime's algorithm overflows and starts returning incorrect values that are smaller than less-matchy scores. By using floating point, I get an exponent mantissa representation that separately tracks the matching depth and only the most significant scopes. This is exactly what you want for most closely approximating fully correct behaviour. The most important thing is the depth, the exponent, and the most significant scopes at the top of the stack. In practice only really weird cases will cause either algorithm to be incorrect, but mine degrades more gracefully. |
Syntect uses a floating point algorithm for scoring while Sublime uses an integer one.
Probably sublime uses u64 datatypes for scoring, ie: 2^64 = 18446744073709551616
I've tried to analize the general behaviour of Sublime's by doing some simple tests:
Case1
Solution1:
Case 2
Solution2
Case3
Solution3
So, for this particular sequences and if we consider the previous results we can extrapolate a more general solution that works for these type of simple scopes such as:
Of course, this doesn't explain how Sublime's score_selector works but it clearly shows that the algorithm itself must be contain really simple maths and string processing functions.
Any idea how it works behind the scenes?
The text was updated successfully, but these errors were encountered: