On Tuesday, 8 May 2018 23:09:27 UTC-4, David Bradley wrote:
> Thanks again Pablo! I was looking for the radio button for the solution
> download like the old interface used to have. I never saw the tool tip when
> you moused over the names. It works great (and no more zip files!).
>
> For
Thanks again Pablo! I was looking for the radio button for the solution
download like the old interface used to have. I never saw the tool tip when
you moused over the names. It works great (and no more zip files!).
For the rest of the folks in the thread, I scrolled through and found a few
>
> 2) I think several of us here are eager either to see one (or more) of
> said solutions. Hopefully in the near future we will be able to see our
> fellow competitors submissions on the new platform :).
>
>
You can see those right now (the feature has been out for a while, although
it wasn't
Thanks Pablo for the reply! A small number of points.
1) It's comforting to know you Googlers pre-tested in Python and have solutions
that comfortably meet the time limit.
2) I think several of us here are eager either to see one (or more) of said
solutions. Hopefully in the near future we
The original solution is also O(NK), keep in mind that the size of D never
exceed 139. So it does not matter whether you want to check the boundary from
above or below. It is always O(139) for worst case.
Use binary search for finding the boundary could be faster, but the runtime
could be
> h= len(D)-1
> while(D[h]>6*w):#this stops as D[0]=0
> h-=1
The part quoted above makes the algorithm O(n^2) instead of O(nk). (n = number
of ants, k = max height of stack).
We may think that O(nk) and O(n^2) are similar (so do I). But we are wrong.
Instead, for W
I would really like to see how the Python Solutions that pass comfortably look
like. If I understood things correctly, the solutions in this thread which pass
just pass barely (with 13 secs out of 15 secs), and the whole question is not
so complicated that there is a lot of room for
Thanks for the explanation. That's very helpful.
--
You received this message because you are subscribed to the Google Groups
"Google Code Jam" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-code+unsubscr...@googlegroups.com.
To post to this
On Mon, 7 May 2018 12:00:30 -0700 (PDT)
Xiongqi ZHANG wrote:
> Ah ha, you used floating points in converting my variant. What's the
> reason behind that?
I have done it to ensure that this program is a valid Ruby and Crystal
code at the same time. With the only
On Sun, 6 May 2018 22:00:06 +0200
Valentin Vidić wrote:
> Can you try converting this Go code to Python to see if it helps with the
> speed?
>
> package main
>
> import (
> "bufio"
> "fmt"
> "os"
> )
>
> func build2(a []int) int {
> s :=
Ah ha, you used floating points in converting my variant. What's the reason
behind that?
--
You received this message because you are subscribed to the Google Groups
"Google Code Jam" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to
On Sat, 5 May 2018 13:13:17 -0700 (PDT)
"'henrikruep...@googlemail.com' via Google Code Jam"
wrote:
> Thanks a lot! I will try to keep those optimzations in mind when I
> try again next year.
>
> I have the feeling that in previous years (when we just computed and
On Monday, May 7, 2018 at 11:12:02 AM UTC-5, Pablo Heiber wrote:
> Hi everyone,
>
>
> I won't comment on specific solutions, but I just want to let you all know
> that our policy as to what is possible to pass remains the same: for most
> problems, especially in earlier rounds, we aim to make
Hi everyone,
I won't comment on specific solutions, but I just want to let you all know
that our policy as to what is possible to pass remains the same: for most
problems, especially in earlier rounds, we aim to make sure they can be
passed with most languages. In this particular case, we do have
So I became a bit obsessed yesterday tying to get this to pass. Late last
night, I finally got a solution that barely passed. My solution inverts the
order of the two variables vs. your solution (stack height vs. "first i" ants).
My key function is shown below.
def solve(inp) :
(n,w)
Now that it's practice time, you can find out how much too slow it is. Try
having your program solve just some fraction of the test cases, and see
whether you get time limit or just wrong answer. Have it solve a different
subset of the same size to make sure you didn't get lucky or unlucky.
On
Can you try converting this Go code to Python to see if it helps with the
speed?
package main
import (
"bufio"
"fmt"
"os"
)
func build2(a []int) int {
s := []int{0}
for i := 0; i < len(a); i++ {
for j := len(s) - 1; j >= 0; j-- {
Python performance seems to be the issue, indeed.
I'm not a Python guy (unfortunately), but have managed to translate to Python 3
my Java solution you can find at https://github.com/salvois/codejam
The Java version is judged as correct, while the following gets a Time Limit
Exceeded on the large
Thanks a lot! I will try to keep those optimzations in mind when I try again
next year.
I have the feeling that in previous years (when we just computed and submitted
the output file) as long as you got the optimal asymptotic complexity (like sth
in O(NK) in this case), you were guaranteed to
That's pretty odd.
I did some optimization (not affecting worst case complexity though) and passed.
But I serious doubt that the time limit for python(3?) is sufficient.
see my code at https://ideone.com/Qzgziu
--
You received this message because you are subscribed to the Google Groups
20 matches
Mail list logo