At least when I tested my solution on my machine with my own performance test I got a slight improvement with this option.

The number of combinations to test grows very rapidly as the number of trades grow. A brute-force solution will have to test 2^n solutions where n is the number of trades. 20 trades gives over one million combinations to test. It seems reasonable to

Here is a modified version that avoids the SQL server bug. There is no performance difference against the original version. -- TC51 -- -- Stefan_G_v3 -- -- Algorithm: -- Use a recursive cte to implement a nested loop that processes 56 bits from

Very interesting. As far as I understand this is caused by a bug in SQL server. Your data causes my code to try to evaluate 486770333240524799999999999999999 % 10000000000000000 This should of course return the last 16 digits, so the expected result

Well, I might not have been very clear in my post, but I have two different versions. v1 and v2. They have different characteristics when it comes to sparse or dense data. my v1 solution is extremely fast for dense data, but much slower for sparse data. my

Another script for performance testing: -- tc53 test data -- different types of solutions have different characteristics for sparse or dense data. -- This script can generate both sparse and dense data, set @sparse=0 to get dense dat

Yes, I get the same results. (1 row(s) affected) Table 'Worktable'. Scan count 2, logical reads 47526, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0. Table 'TC55'. Scan count 1, logical reads 2