Hello,
We are excited to announce that two of our most requested features have
launched today!
1. Scoreboard view by location.
2. Scoreboard view of people you choose to follow.
You can try them out in all our past scoreboards in the archive
Ok thank you I will try that and see how to optimize the calculation if N
is becoming big.
Le mercredi 15 avril 2020 22:37:26 UTC+2, porker2008 a écrit :
>
> The problem with your code is function *ncr()*
>
> It can easily go overflow when *n* is too big.
>
> Here is one fix for *cnr()* and it
Yes sorry about, I didn't see the message saying that my post need to be
validated first.
I will check that.
Le mercredi 15 avril 2020 22:37:26 UTC+2, porker2008 a écrit :
>
> duplicate question I believe.
> Please check my comments in the other threads
>
--
You received this message because
Please checkout FAQ: https://codingcompetitions.withgoogle.com/codejam/faq
Section "Coding"
Question: *How should my program read input and write output?*
*TL;DR; *Your program should read from *standard input stream* (e.g. *scanf*,
*cin* in C/C++, *input()* in python, *System.in* in Java, etc)
The reason to avoid floating point arithmetic is that floating point number
has wider range than integer but has lower precision.
In any case, if a problem can be solved without using floating points
(meaning that all operations are done using integers and they fit the range
of long long)
you
I have been doing some of the practice problems and have an answer which
works. I can't pass that answer and get a pass because I'm not sure what
we're supposed to be submitting. Is there an input file we should be
parsing and using, or should we just input the data correctly? If that's
the
duplicate question I believe.
Please check my comments in the other threads
--
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
Thank you, Edward!
On Wednesday, April 15, 2020 at 11:46:32 AM UTC-4, Edward wrote:
>
> The suggestion is that you avoid using float at all (because floating
> point arithmetic is hard), and instead use integer arithmetic. In this
> case, you can do that by not computing the average.
>
> On
Maybe the cells you choose do not give the appropriate sum. Or, you may be
not hoping only among neighbors, as described in the problem.
To test if your selected cells give the appropriate sum, you can use the
following python3 script:
To use it:
* In your solution, print the "Case #..." line,
The suggestion is that you avoid using float at all (because floating point
arithmetic is hard), and instead use integer arithmetic. In this case, you
can do that by not computing the average.
On Wed, 15 Apr 2020 at 16:42, Matt Fenlon wrote:
> That fixed it! Thank you so much. Out of curiosity,
Hello all,
My code for Pascal Walk is throwing me a WA for the test set 2 but I don't
know why.
I check that there is not twice the same element used and that two elements
are 'touching' in the triangle but my test have shown no error on eclispe
even if I tested from 1 to 1000.
Here is the
Hello all,
I have tried to solve this puzzle :
https://codingcompetitions.withgoogle.com/codejam/round/0019fd74/002b1353
But so far my code only pass the first test and then I got a WA.
I tested on Eclipse my code and I do not manage to find out what is wrong.
I can't tell if it
That fixed it! Thank you so much. Out of curiosity, for what reason should
we avoid float when calculating average?
On Tuesday, April 14, 2020 at 5:41:05 PM UTC-4, porker2008 wrote:
>
> I think the problem is related the following line
>
> *total += f[i][j] * when[i][j];*
>
> Since f[][] and
Yes, thank you.
That condition was initially because I didn't order the activities first.
Now I've changed it with that little memory of the last assigned activities
and it is NlogN.
On Tue, Apr 14, 2020 at 9:28 PM porker2008 wrote:
> Oh didn't notice that you override the equal() to for
14 matches
Mail list logo