Outline ·
[ Standard ] ·
Linear+
Jobstreet code challenge, anyone going?
angch
|
Aug 20 2015, 11:49 AM
|
|
QUOTE(CsAtlantis @ Aug 20 2015, 11:12 AM) There was one problem where it was going oh so well for meuntil after test case 13 (14-20 all got time exceeded limit ) Which problem was that? Hmmm, writing test case generators for those problems might be interesting.
|
|
|
|
CsAtlantis
|
Aug 20 2015, 12:56 PM
|
New Member
|
QUOTE(angch @ Aug 20 2015, 11:49 AM) Which problem was that? Hmmm, writing test case generators for those problems might be interesting. I think it was problem 4..........they had a memory limit of 15MB i think and a execution time limit of (can't recall now, was either 0.5s or 1s) Most likely because I was doing it in C++ I had too many loops during the later, more complicated test cases This post has been edited by CsAtlantis: Aug 20 2015, 12:58 PM
|
|
|
|
angch
|
Aug 20 2015, 06:02 PM
|
|
QUOTE(CsAtlantis @ Aug 20 2015, 12:56 PM) I think it was problem 4..........they had a memory limit of 15MB i think and a execution time limit of (can't recall now, was either 0.5s or 1s) Most likely because I was doing it in C++ I had too many loops during the later, more complicated test cases 1s is a crazy time limit, esp. for python. The maximal test case for 4 (water disruption?) took nearly a minute for me, including random (static seeded) cost map. Good learning experience though, finding the bottlenecks. I knew string concat is slow, but yikes, it's *slow* in Go. Also surprisingly I used a map (dict) of int to int, and that was costly. Ditto the perl way of using regexp to parse data. Stupid habits die hard. Managed to make it much, much faster though. Too bad code is twice as hard to read now.
|
|
|
|
CsAtlantis
|
Aug 21 2015, 08:38 AM
|
New Member
|
QUOTE(angch @ Aug 20 2015, 06:02 PM) 1s is a crazy time limit, esp. for python. The maximal test case for 4 (water disruption?) took nearly a minute for me, including random (static seeded) cost map. Good learning experience though, finding the bottlenecks. I knew string concat is slow, but yikes, it's *slow* in Go. Also surprisingly I used a map (dict) of int to int, and that was costly. Ditto the perl way of using regexp to parse data. Stupid habits die hard. Managed to make it much, much faster though. Too bad code is twice as hard to read now. Yeah problem number 4 was not solved completely by any of the contestants, the maximum score was 70% if I recall correctly Regarding the time limit I really can't remember....might have been a bit longer though but definitely less than 20 seconds
|
|
|
|
TheSolver
|
Aug 21 2015, 10:39 AM
|
|
I didn't participate in the contest in the beginning and just got the questions posted here a few days ago so I can't tell much about anything. I'll try to complete the C language counterpart of the Question 1 and post it here. It's sure is not as elegant as I would like to but it'll certainly do its job to be efficient and other desirable effects. Now, first let's see how to squeeze in my schedule (happens to be a busy time of the year)?
|
|
|
|
angch
|
Aug 21 2015, 10:36 PM
|
|
QUOTE(CsAtlantis @ Aug 21 2015, 08:38 AM) Yeah problem number 4 was not solved completely by any of the contestants, the maximum score was 70% if I recall correctly Regarding the time limit I really can't remember....might have been a bit longer though but definitely less than 20 seconds My Cell tower solution was using a stupid naive way. Tightened it up, now runs 2000x2000 distance/radius 50 to around 5 seconds from about a minute, including generation of the random map. Crammed stuff int16 instead of int32 to bring ram usage down to about 22MB including input string. https://gist.github.com/angch/e321743f633e8855acdeRevised my water disruption solution as well. Just because. Making it solve about 20 maximum size problems in less than 6 seconds. https://gist.github.com/angch/d3b75ebcccdd58868e1e'twas fun. Learned lots of fun pprof stuff on the way. Much better than codegolfing.
|
|
|
|