PHISSUG

I'm still into this. The problem is very engrossing that usually I failed to notice that I had been working up to the wee hours of the morning already! Now, that's someting I can't afford to do often.

The nice thing about this problem is its not data centric at all so any computer geek out there has a chance on this. I've been rummaging online resources and books about this and I am amazed by the amount of info I've waded (and learned ) just to find out solution for this problem. I have one apprehension though. Based on what I've read so far, the amount of test data that sir gg is proposing might take inifinitely long time to solve. Besides, I rather prefer a small data set with the predetermined correct combinations so that the correctness of the algorithm can be readily determined. It's not safe to just rely on the submitted script to determine the possible combinations. Just a suggestion sir.

twistur:

I'm still into this. The problem is very engrossing that usually I failed to notice that I had been working up to the wee hours of the morning already! Now, that's someting I can't afford to do often.

The nice thing about this problem is its not data centric at all so any computer geek out there has a chance on this. I've been rummaging online resources and books about this and I am amazed by the amount of info I've waded (and learned ) just to find out solution for this problem. I have one apprehension though. Based on what I've read so far, the amount of test data that sir gg is proposing might take inifinitely long time to solve. Besides, I rather prefer a small data set with the predetermined correct combinations so that the correctness of the algorithm can be readily determined. It's not safe to just rely on the submitted script to determine the possible combinations. Just a suggestion sir.

(wink). i never thought you will actually attempt to test it at 10000 rows. what i am expecting is that contestants will try their algo on 10s, 100s of rows and come up with their own testing methods (i mean their own predetermined correct combinations) which i think as so easy to do. solve the problem first and we will deal with your apprehensions later :) your apprehensions should not prevent you from coming up with the fastest and correct query.

here is my suggestion, submit your solution first so others can take a look at this and scrutinize it and question if it's not the right solution.

Ditto with twister. I've been rummaging too with online resources and e-books to come up with a solution. Im not actually after the prize (but well......hhhmmmmm). Im being surprised by all that Im learning. Its been long since I learned something new. And learning something new is always very much addicting.

ggsubscribe:

(wink). i never thought you will actually attempt to test it at 10000 rows.

Of course I wouldn't do that sir! I was actually referring to the final deliberation that would determine the winner (if there will be, heheheh). Some of the accepted algorithms are exponential with the magnitude O(2ⁿn)  and  O( 2^n/2n) where n is the number of data (in our case, rows) to be processed.  Windows calculator would probably unable to display the entire value if I try to compute  for all the possible combinations let alone bring down an instance Tsk tsk tsk, if only CLR-based objects are accepted, I would test 10000 rows! Kidding! This surely is a tough one. I'm having problems looking for a good spot in the office where no one can see me reading some arcane geeky math stuffs.

Sir Darwin, I'm so glad to find another one getting hooked on this. Good luck to us all.

Guys ... you have until tomorrow (Aug 22) to submit your solutions. Hope somebody got something for this :D

uh oh... i seemed to have forgot about this... and my script still is acting wierd on big rows... anyway i'll try to catch with the deadline... is this till the end of day tomorrow???

icarus08:

uh oh... i seemed to have forgot about this... and my script still is acting wierd on big rows... anyway i'll try to catch with the deadline... is this till the end of day tomorrow???

Deadline will be Aug 22 2006, 11:59 (Philippine Time). So thats like 1:18 minutes to go hehe.

ggsubscribe:

icarus08:

uh oh... i seemed to have forgot about this... and my script still is acting wierd on big rows... anyway i'll try to catch with the deadline... is this till the end of day tomorrow???

Deadline will be Aug 22 2006, 11:59 (Philippine Time). So thats like 1:18 minutes to go hehe.

wow! hope i could make it in time... anyway i just backread and there was this thing about the limitation on iterations of SQL Server? is this true for both 2000 and 2005 and what about it?

icarus08:

ggsubscribe:

icarus08:

uh oh... i seemed to have forgot about this... and my script still is acting wierd on big rows... anyway i'll try to catch with the deadline... is this till the end of day tomorrow???

Deadline will be Aug 22 2006, 11:59 (Philippine Time). So thats like 1:18 minutes to go hehe.

anyway i just backread and there was this thing about the limitation on iterations of SQL Server? is this true for both 2000 and 2005 and what about it?

I am not so sure what twistur was referring to. I guess he might be refering to MSSQL's limit of 32 for executing recursive functions. However, i think one can do some iterative processing without using recursion and instead use some pre-determined loop.

At first glance the problem seems pretty simple but as you get to understand the problem, it is kind of complex.

ggsubscribe:

icarus08:

ggsubscribe:

icarus08:

uh oh... i seemed to have forgot about this... and my script still is acting wierd on big rows... anyway i'll try to catch with the deadline... is this till the end of day tomorrow???

Deadline will be Aug 22 2006, 11:59 (Philippine Time). So thats like 1:18 minutes to go hehe.

anyway i just backread and there was this thing about the limitation on iterations of SQL Server? is this true for both 2000 and 2005 and what about it?

I am not so sure what twistur was referring to. I guess he might be refering to MSSQL's limit of 32 for executing recursive functions. However, i think one can do some iterative processing without using recursion and instead use some pre-determined loop.

At first glance the problem seems pretty simple but as you get to understand the problem, it is kind of complex.

Yes sir GG, I'm referring to the recursion limit of SQL which is 32. I was able to revised it; removing the recursion but again, I found some flaws. I ended up to the drawing board again for some new algo's. I've found some proven algo's but they involved recursion. The script should be able to handle bigger number of rows so recursion is definitely out of the picture. It's very unfortunate that my research on this is somewhat hampered by some urgent tasks assigned to me right now. I hope this one gets extended. Challenging yet very time consuming.

twistur:

Yes sir GG, I'm referring to the recursion limit of SQL which is 32. I was able to revised it; removing the recursion but again, I found some flaws. I ended up to the drawing board again for some new algo's. I've found some proven algo's but they involved recursion. The script should be able to handle bigger number of rows so recursion is definitely out of the picture. It's very unfortunate that my research on this is somewhat hampered by some urgent tasks assigned to me right now. I hope this one gets extended. Challenging yet very time consuming.

I second the motion... yes it is very time consuming... im trying to do a bit of tweaking to but it seems to be a bit harder than i thought... I'm having problems with the less than issue... where in the combination could be more than 3 numbers (PKIDs)  oh well.. i would really like to know the solution for this problem...   

ggsubscribe:

I am not so sure what twistur was referring to. I guess he might be refering to MSSQL's limit of 32 for executing recursive functions. However, i think one can do some iterative processing without using recursion and instead use some pre-determined loop.

At first glance the problem seems pretty simple but as you get to understand the problem, it is kind of complex.

i also thought of doing some processing before determining the possible solutions.  but worst case scenarios always come to mind, rendering the pre-processing futile (for my solution at least).

twistur:

ggsubscribe:

icarus08:

ggsubscribe:

icarus08:

uh oh... i seemed to have forgot about this... and my script still is acting wierd on big rows... anyway i'll try to catch with the deadline... is this till the end of day tomorrow???

Deadline will be Aug 22 2006, 11:59 (Philippine Time). So thats like 1:18 minutes to go hehe.

anyway i just backread and there was this thing about the limitation on iterations of SQL Server? is this true for both 2000 and 2005 and what about it?

I am not so sure what twistur was referring to. I guess he might be refering to MSSQL's limit of 32 for executing recursive functions. However, i think one can do some iterative processing without using recursion and instead use some pre-determined loop.

At first glance the problem seems pretty simple but as you get to understand the problem, it is kind of complex.

Yes sir GG, I'm referring to the recursion limit of SQL which is 32. I was able to revised it; removing the recursion but again, I found some flaws. I ended up to the drawing board again for some new algo's. I've found some proven algo's but they involved recursion. The script should be able to handle bigger number of rows so recursion is definitely out of the picture. It's very unfortunate that my research on this is somewhat hampered by some urgent tasks assigned to me right now. I hope this one gets extended. Challenging yet very time consuming.

What flaws have you found? that of SQL Server?

so guys ... i think no one got for the 2nd time the problem :)

anyways ... let us just leave the problem here for those interested to solve this. the prize? hmmm .. how about the distinction to be the only who solved this? hehe.

thanks to everybody who participated in this thread.

The flaw was in my algorithm. I found out it only considered elements (or rows) after the point of reference; thus not exhausting all possible combinations.