alexlikemath007's blog

By alexlikemath007, 20 months ago, In English

Warning: This problem is like the warden of competitive programming. It is a force of nature — like a hurricane, and when you see a hurricane you don't fight it, you run. It is a big bad boss with a bunch of hitpoints, and deals big damage to your sanity. But when you kill it, it doesn't drop much loot, experience, or educational value compared to other problems. It would be wiser to go and solve some problems and learn how to use binary search.

The problem: https://codeforces.net/gym/102452/problem/F

It's tutorial says: Since n is small, $$$O(n^2)$$$ simulation is OK. Advanced 3-D geometry methods are highly required.

The tutorial doesn't describe what the advanced 3-D geometry methods are. So, I have written this blog to remedy that gap.

Chapter 1. Prologue
Chapter 2. Math StackExchange
Chapter 3. Wikipedia
Chapter 4. Finally an easy case
Chapter 5. Real-world applications of Calculus: Traumatized Edition
Chapter 6. Deja vu
Chapter 7. Deja vu vu
Chapter 8. What is a Euler Angle?
Chapter 9. Put it together
Chapter 10. Edge cases/Debugging
Chapter 11. Optimization

Full text and comments »

  • Vote: I like it
  • +434
  • Vote: I do not like it

By alexlikemath007, history, 21 month(s) ago, In English

The Problem: http://www.usaco.org/index.php?page=viewproblem2&cpid=1285

The Editorial: http://www.usaco.org/current/data/sol_prob2_platinum_jan23.html

I was stress testing against the model solution, and I think I found an error in the provided solution.

I ran this test case on the model solution as shown in the editorial:

3 6
4 6 4 
1 2 3
1 3 3
2 1 1
2 3 2
3 1 3
3 2 2
10
1 3
8 1
1 2
8 1
3 3
5 2
10 1
8 3
1 2
8 1

It appears to be a valid test case adhering to the problem. However, when ran against the solution, I got a runtime error. The following was printed to standard error.

Assertion failed: (a.f > b.f) && (a.s < b.s), file d:/C++ programs/usaco/jan/B/brute.cpp, line 36

However, the correct answer to the test case is:

4
94
6
94
18
42
122
80
6
94

Needless to say, I don't think this is correct.

Can the USACO staff please investigate this?

Edit: I have another test case which doesn't set off the assert, but sometimes gives either 7 (WA) or 12 (AC). (Perhaps it depends on the version of C++?), which means that the model solution also exhibits some strange undefined behavior.

3 6
6 6 5 
1 2 2
1 3 3
2 1 2
2 3 1
3 1 1
3 2 2
1
2 2

Edit 2:

I believe there may be a typo which caused that: On line 39, the model written:

    ll addOne = ((addOne%slopeDif)==0)?1:0;

When it should be

    ll addOne = ((addDif%slopeDif)==0)?1:0;

Full text and comments »

  • Vote: I like it
  • +88
  • Vote: I do not like it