Problem #152 "Latin Square Slicing" always times out on me. I already tried to optimize runtime to make it pass in time.
On my machine my solution needs less than 700ms for all test cases on a fresh REPL on the first run (much less for consecutive runs).
How big is the timeout there? Is the timeout per test case or on the whole set of test cases? I would love some feedback on how much time my solution needed per test case to see where it times out on the server.
On Sunday, July 8, 2012 7:02:40 PM UTC+8, clgv wrote:
> Problem #152 "Latin Square Slicing" always times out on me. > I already tried to optimize runtime to make it pass in time.
> On my machine my solution needs less than 700ms for all test cases on a > fresh REPL on the first run (much less for consecutive runs).
> How big is the timeout there? Is the timeout per test case or on the whole > set of test cases? > I would love some feedback on how much time my solution needed per test > case to see where it times out on the server.
On Monday, October 1, 2012 11:41:56 AM UTC+8, ctzsm wrote:
> I am stuck with the same question.
> my solution to problem 152 runs very fast now, and it takes only 30+ms on > ideone.com and in my REPL
> Even in the slowly lighttabel, it takes just 110+ms.
> If you solved this problem, could you please give me some hint?
> On Sunday, July 8, 2012 7:02:40 PM UTC+8, clgv wrote:
>> Problem #152 "Latin Square Slicing" always times out on me. >> I already tried to optimize runtime to make it pass in time.
>> On my machine my solution needs less than 700ms for all test cases on a >> fresh REPL on the first run (much less for consecutive runs).
>> How big is the timeout there? Is the timeout per test case or on the >> whole set of test cases? >> I would love some feedback on how much time my solution needed per test >> case to see where it times out on the server.
> OK...I had passed the problem one hour ago. my solution need 27ms to the > last test case on ideone.com now.
> but what surprised me is that other people's solutions need more than > 100ms (some need 600ms) to the last test case on ideone.com.
> That means I should passed this problem yesterday, because my first > edition of this problem's solution need less than 600ms to the last test > case.
> On Monday, October 1, 2012 11:41:56 AM UTC+8, ctzsm wrote:
>> I am stuck with the same question.
>> my solution to problem 152 runs very fast now, and it takes only 30+ms on >> ideone.com and in my REPL
>> Even in the slowly lighttabel, it takes just 110+ms.
>> If you solved this problem, could you please give me some hint?
>> On Sunday, July 8, 2012 7:02:40 PM UTC+8, clgv wrote:
>>> Problem #152 "Latin Square Slicing" always times out on me. >>> I already tried to optimize runtime to make it pass in time.
>>> On my machine my solution needs less than 700ms for all test cases on a >>> fresh REPL on the first run (much less for consecutive runs).
>>> How big is the timeout there? Is the timeout per test case or on the >>> whole set of test cases? >>> I would love some feedback on how much time my solution needed per test >>> case to see where it times out on the server.
My updated solution took 2.18s on ideone (http://ideone.com/lNdPZ6) which relates to 600ms on my T61p, obviously not good enough to pass on 4clojure. @ctzsm: would you mind to share your solution strategy?
Am Montag, 1. Oktober 2012 10:31:33 UTC+2 schrieb ctzsm:
> OK...I had passed the problem one hour ago. my solution need 27ms to the > last test case on ideone.com now.
> but what surprised me is that other people's solutions need more than > 100ms (some need 600ms) to the last test case on ideone.com.
> That means I should passed this problem yesterday, because my first > edition of this problem's solution need less than 600ms to the last test > case.
The accepted solution of _pcl takes 1.88s (http://ideone.com/L96buo) versus mine taking now 2.05s (http://ideone.com/cLGx2u), which is still rejected, although the solutions were clearly on par with ~360ms on my laptop during several tests.
Any comments on the time out threshold?
Am Sonntag, 11. November 2012 18:05:50 UTC+1 schrieb fbmnds:
> My updated solution took 2.18s on ideone (http://ideone.com/lNdPZ6) which > relates to 600ms on my T61p, obviously not good enough to pass on 4clojure. > @ctzsm: would you mind to share your solution strategy?
There is a function 'time' in the core of clojure, so I always use it to test my codes' time costs. I think it's more accurate than ideone's estimation method, therefore the 2.05s on ideone may just cost hundreds of msecs.
If you really want to know my method, it's just based on an obvious observation. The original idea to the problem is to check all the matrices the square contains. But in fact, to the big data, most of the matrices doesn't contribute to the answer, they are redundant. So in order to decrease the time, you can just check some of the matrices. Then there is a question. How to know which set of matrices we need? If you have some experience in random algorithm, that's it.
On Monday, November 12, 2012 5:24:22 AM UTC+8, fbmnds wrote:
> The accepted solution of _pcl takes 1.88s (http://ideone.com/L96buo) > versus mine taking now 2.05s (http://ideone.com/cLGx2u), which is still > rejected, although the solutions were clearly on par with ~360ms on my > laptop during several tests.
> Any comments on the time out threshold?
> Am Sonntag, 11. November 2012 18:05:50 UTC+1 schrieb fbmnds:
>> My updated solution took 2.18s on ideone (http://ideone.com/lNdPZ6) >> which relates to 600ms on my T61p, obviously not good enough to pass on >> 4clojure. >> @ctzsm: would you mind to share your solution strategy?
thank you for sharing the hint on random algorithms which lack experience with. This explains your super fast solution.
With ~360 ms on my T61p it is 10x slower than yours, but on par with other already accepted solutions (~200ms and ~380ms on my laptop). I think you mentioned in a former post that your first solution was accepted with a runtime of ~600ms.
I added the timing information on ideone.com because it might be interesting for those who are using that platform. In other threads of this forum, this is information is also shared as a reference, as 4clojure only provides passed/failed.
It is kind of frustrating not to know what the time limit of a problem is. It should be part of the problem description.
If 4clojure were more education oriented than a competition platform, a less restrictive time limit would be reasonable. I think, the run time of solutions would be better reflected in the ranking.
Bye, -fb
Am Montag, 12. November 2012 15:27:42 UTC+1 schrieb ctzsm:
> There is a function 'time' in the core of clojure, so I always use it to > test my codes' time costs. > I think it's more accurate than ideone's estimation method, therefore the > 2.05s on ideone may just cost hundreds of msecs.
> If you really want to know my method, it's just based on an obvious > observation. > The original idea to the problem is to check all the matrices the square > contains. > But in fact, to the big data, most of the matrices doesn't contribute to > the answer, they are redundant. > So in order to decrease the time, you can just check some of the matrices. > Then there is a question. How to know which set of matrices we need? > If you have some experience in random algorithm, that's it.
> Yours.
> On Monday, November 12, 2012 5:24:22 AM UTC+8, fbmnds wrote:
>> The accepted solution of _pcl takes 1.88s (http://ideone.com/L96buo) >> versus mine taking now 2.05s (http://ideone.com/cLGx2u), which is still >> rejected, although the solutions were clearly on par with ~360ms on my >> laptop during several tests.
>> Any comments on the time out threshold?
>> Am Sonntag, 11. November 2012 18:05:50 UTC+1 schrieb fbmnds:
>>> My updated solution took 2.18s on ideone (http://ideone.com/lNdPZ6) >>> which relates to 600ms on my T61p, obviously not good enough to pass on >>> 4clojure. >>> @ctzsm: would you mind to share your solution strategy?
On Wednesday, November 14, 2012 12:23:41 AM UTC+8, fbmnds wrote:
> Hi ctzsm,
> thank you for sharing the hint on random algorithms which lack experience > with. This explains your super fast solution.
> With ~360 ms on my T61p it is 10x slower than yours, but on par with other > already accepted solutions (~200ms and ~380ms on my laptop). I think you > mentioned in a former post that your first solution was accepted with a > runtime of ~600ms.
> I added the timing information on ideone.com because it might be > interesting for those who are using that platform. In other threads of this > forum, this is information is also shared as a reference, as 4clojure only > provides passed/failed.
> It is kind of frustrating not to know what the time limit of a problem is. > It should be part of the problem description.
> If 4clojure were more education oriented than a competition platform, a > less restrictive time limit would be reasonable. I think, the run time of > solutions would be better reflected in the ranking.
> Bye, > -fb
> Am Montag, 12. November 2012 15:27:42 UTC+1 schrieb ctzsm:
>> Hi,
>> There is a function 'time' in the core of clojure, so I always use it to >> test my codes' time costs. >> I think it's more accurate than ideone's estimation method, therefore the >> 2.05s on ideone may just cost hundreds of msecs.
>> If you really want to know my method, it's just based on an obvious >> observation. >> The original idea to the problem is to check all the matrices the square >> contains. >> But in fact, to the big data, most of the matrices doesn't contribute to >> the answer, they are redundant. >> So in order to decrease the time, you can just check some of the matrices. >> Then there is a question. How to know which set of matrices we need? >> If you have some experience in random algorithm, that's it.
>> Yours.
>> On Monday, November 12, 2012 5:24:22 AM UTC+8, fbmnds wrote:
>>> The accepted solution of _pcl takes 1.88s (http://ideone.com/L96buo) >>> versus mine taking now 2.05s (http://ideone.com/cLGx2u), which is still >>> rejected, although the solutions were clearly on par with ~360ms on my >>> laptop during several tests.
>>> Any comments on the time out threshold?
>>> Am Sonntag, 11. November 2012 18:05:50 UTC+1 schrieb fbmnds:
>>>> My updated solution took 2.18s on ideone (http://ideone.com/lNdPZ6) >>>> which relates to 600ms on my T61p, obviously not good enough to pass on >>>> 4clojure. >>>> @ctzsm: would you mind to share your solution strategy?
So if you are just looking for a workaround, do not use the for macro. It can be replaced by (much uglier) combinations of map, mapcat, filter and take-while, e.g.
