One Point Solution

  • Subscribe to our RSS feed.
  • Twitter
  • StumbleUpon
  • Reddit
  • Facebook
  • Digg

Saturday, 25 February 2012

Codeforces 109 1B / 2D - Colliders

Posted on 05:03 by Unknown
Link to statement
I kind of solved this during the contest, I just made the absurdly wrong assumption that I only needed prime factors up to sqrt(100000), this is completely wrong and stupid. A prime factor can be up to (N/2). I also did something complicated to get the number of the conflicting collider (I knew that only a collider can use a prime factor, but I forgot about that when making this operation). I have no idea why this happened.

I find this problem to share a lot of traits to the topcoder problem from the round just after. The same logic to ensure that the numbers are co-prime is very useful in both problems.

n and m can be sort of large, up to 100000. It is best to make the algorithms better than O(n*m), just for example. The following solution will work in O(m * sqrt(n)) time, so that's quite fine.

First of all, co-prime numbers. Although gcd(a,b) = 1 is the definition used in the statement, it really pays to see the problem as (No two colliders can share a prime factor). You can be sure that the maximum number of distinct prime factors a number can have is O(log(n)) (It is actually better than that). For example, try 2*3*5*7*11*13*17 , that is already larger than 100000. Thus you can assume a number will never have more than 7 distinct prime factors.

So, the algorithm is rather simple, when considering that. Assume that you have a list of all the prime factors of each of the numbers from 1 to 100000. That is an array [6][100001]. Which is perfectly fine for the memory limit. Then, let's say that you have an array that for each prime factor, sets whether it is currently in use by a collider (A collider that is a multiple of that prime exists) or not. The solution becomes an easy simulation: When turning on a collider, set the array to true for all of its prime factors. When verifying if you can turn a collider on, see for each of its prime factors if the array is already true or not. When turning a collider off, set the boolean values of its prime factors to false (This works because only one collider at the same time can be a multiple of a prime factor).

We forgot about something, the conflict message requires you to say the number of a collider that conflicts with the request. That is easy, instead of just setting leaving true or false to the array that determines used prime factors. Leave the number of the collider that uses it or -1 if no collider uses it.

Prime factors quickly
The previous solution is correct and works in O(m * log(n) ) time but it assumes we already have a list of the prime factors for each number. We need to get this list quickly.

Looping through each of the n numbers, and factorizing them, may work in time. Maybe 100000 * sqrt(100000) is fine. maybe.... If you want something faster, here is a trick that uses a slight modification to the Sieve of Eratosthenes. In the normal sieve, you mark the numbers you find to be composite as such. However, think of it, whenever you mark a composite number as false for the first time, you are doing so because you have just found the first prime factor of the number. Thus, you can modify the Sieve of Eratosthenes slightly to make it return a list of the first prime factor for each number from 2 to n (For a prime number, its first and only prime factor is itself). You can then use this list to quickly factorize any number from 2 to n:
- Extract first prime factor : q
- Divide x by q until x is no longer a multiple of x.
- Use the new value of x to find the next prime factor, and repeat until x is 1.
Email ThisBlogThis!Share to XShare to Facebook
Posted in codeforces, explanation | No comments
Newer Post Older Post Home

0 comments:

Post a Comment

Subscribe to: Post Comments (Atom)

Popular Posts

  • TopCoder SRM 557 - finally
    SRM 557 Explanation for division 1 Easy and match recap. Explanations for div2 easy and div2 medium. It feels like it has been ages since t...
  • SRM 589 Editorial
    I have finished writing the editorial for TopCoder SRM 589: http://apps.topcoder.com/wiki/display/tc/SRM+589 . As you most likely noticed. L...
  • SRM 590 recap and editorial
    Another week another Topcoder match. Not a great day. I had a bad flu and still do. Div1 500: The one with Xor Given a list of cards with nu...
  • SRM 546: relief
    I figured I should post something about this SRM. I've been very busy these weeks because the semester is ending and I tried to win a t-...
  • SRM 601 editorial (minus div1 hard)
    It is up: http://apps.topcoder.com/wiki/display/tc/SRM+601 This was a very dry editorial to write. All problems were mathy ad hoc or complex...
  • Member SRM 505: Part 1
    So, let me explain a couple of problems from a Topcoder Member SRM that I wrote and never got an editorial. BTW, it was the last member SRM....
  • SRM 533: Div1 500 MagicBoard explanation
    Finally solved it. It is a nice problem that is worth explaining in a post. You have a grid/board of at most 50x50 cells. Some cells contain...
  • SRM 554 div1 hard: TheBrickTowerHardDivOne
    Link to problem statement We got infinitely many bricks of dimensions 1x1x1 and C different colors. Count the number of towers of size 2x2...
  • SRM 526: The killing wait for results
    While I wait for results, here is my perspective on this algorithm contest. It began with issues, it had to be postponed 15 minutes. TC has ...
  • TopCoder SRM 570: CentaurCompany and CentaurCompanyDiv2
    Another 570 editorial update: http://apps.topcoder.com/wiki/display/tc/SRM+570 . This time for the division 2 hard and division 1 medium. My...

Categories

  • acm
  • algorithm
  • answers
  • arenaplugin
  • badday
  • behindthescenes
  • bugs
  • c++
  • censorship
  • codechef
  • codeforces
  • contests
  • crocchamp
  • editorial
  • editorial.srm
  • embarrassing
  • explanation
  • gcj2013
  • gmp
  • goodday
  • google
  • googlecodejam
  • greed
  • groklaw
  • health
  • html
  • httpseverywhere
  • implementation
  • ipsc
  • ispc
  • java
  • kawigiedit
  • kindagoodday
  • lamebook
  • languages
  • lego
  • listedlinks
  • marathon
  • nasa
  • offtopic
  • ouch
  • postmortem
  • postportem
  • practical
  • probably_not_a_good_tip
  • problemsetting
  • programming
  • python
  • quora
  • rant
  • recap
  • slightlygoodday
  • snippet
  • srm
  • stl
  • strategy
  • swerc
  • tco
  • tco12
  • tco13
  • tco2012
  • tco2013
  • ternarysearch
  • topcoder
  • tricks
  • ubuntu
  • uva
  • vjass
  • vkcup
  • wc3
  • zinc

Blog Archive

  • ►  2014 (1)
    • ►  January (1)
  • ►  2013 (141)
    • ►  December (14)
    • ►  November (8)
    • ►  October (13)
    • ►  September (11)
    • ►  August (14)
    • ►  July (15)
    • ►  June (13)
    • ►  May (13)
    • ►  April (12)
    • ►  March (11)
    • ►  February (11)
    • ►  January (6)
  • ▼  2012 (94)
    • ►  December (5)
    • ►  October (6)
    • ►  September (8)
    • ►  August (6)
    • ►  July (3)
    • ►  June (5)
    • ►  May (8)
    • ►  April (10)
    • ►  March (20)
    • ▼  February (16)
      • It is the old and worsened ListedLinks 2012-02-27
      • ACM 2012 World finals warmp up I
      • Codeforces 109 1B / 2D - Colliders
      • SRM 534: Div1 500, EllysNumbers
      • SRM 534: Notes that contradict the problem statement
      • Codeforces round #108
      • What is it like to be a (topcoder) problem setter?
      • SRM 533: Div1 500 MagicBoard explanation
      • SRM 533: Failure
      • Codeforces round #107 : "undefined"
      • ListedLinks 2012-02-16
      • Google autocomplete awesomeness
      • ListedLinks 2012-02-10
      • SRM 532: Easy problems can be evil
      • ListedLinks 2012-02-04 - Censorship edition
      • ListedLinks 2012-02-02
    • ►  January (7)
  • ►  2011 (51)
    • ►  December (7)
    • ►  November (12)
    • ►  October (5)
    • ►  September (1)
    • ►  August (3)
    • ►  July (4)
    • ►  June (3)
    • ►  May (7)
    • ►  April (3)
    • ►  March (2)
    • ►  February (1)
    • ►  January (3)
  • ►  2010 (9)
    • ►  December (4)
    • ►  October (1)
    • ►  June (1)
    • ►  May (1)
    • ►  January (2)
  • ►  2009 (1)
    • ►  December (1)
Powered by Blogger.

About Me

Unknown
View my complete profile