06 September 2020

Codeforces Round #668 (Div. 2) Postmortem

Trying a different format with problem-by-problem breakdowns, which hopefully will be more useful when I review my postmortems. I will also backfill the postmortems.

A: I first implemented the metric computation (sort sums of adjacent elements) without having any idea of how to create a different permutation to achieve the same metric. Then I realized that reversing the input preserves the adjacent sums. I won't complain about a 0:02 submission.

B: If the first nonzero element were negative, then we have to incur cost equal to its magnitude. I thought this was it, but some sample inputs didn't pass. Then I noticed that if the first nonzero element were positive, we can add the magnitude to negative terms later in the array, which existed because of the constraint that all elements sum to 0 and that the sum stays 0 after every operation. I quickly patched my solution to keep a reserve from the magnitude of positive elements and using the reserve to decrease the cost of negative elements before incurring their costs. Again, not complaining about a 0:08 submission.

C: This is where I started to struggle. Having the same number of 0s as 1s in every K subarray is the same as the subarray sum equal to K/2. I got hung up on the "system of equations" representation, where every question mark was a variable (question mark at i would be a_i), which seemed extremely hard to solve. Then I thought that I can just look at the number of equations and the number of variables, which seemed sketchy, but I YOLO-ed and incurred a WA.

At about the 0:55 mark, I realized that the system of equations implied that a_i = a_j for i = j mod K. Facepalm. I quickly coded this solution for a 1:02 submission. RIP

D: Clearly, if B is at most DA away from A, then A can reach B in the first move and win. From the problem statement, I inferred that their 10^100 limit meant that either A will reach B in finite time, or B can always move to stay DA away from A. I quickly realized that the best chance of B dodging A is on the diameter of the tree, since in no other scenario will B have the space to run away from A. This implied that if A can go from the center(s) to the ends of the diameter in DA, then A can catch B.

I made the assumption that if DA > DB (it seemed intuitive), then A will be able to reach B eventually because B will run out of space. Thinking that these three criteria were sufficient, I submitted at 1:31 for my first WA on D. Given feedback that my solution failed pretest 2, I came up with the following counterexample to my solution:

1---2---3---4---5---6
        ^           ^
        A           B
DA = 2, DB = 3

My solution would incorrectly say that A never reaches B, while after two moves, A will first move from 3 to 5 and B will move from 6 to 3, letting A move from 5 to 3 on the third move. This really tripped me up, leading me to think about the relative difference between DA and DB. I tried that if the relative difference is larger than the half the diameter of the tree, then A cannot catch B, for another WA at 1:44. Finally, as a last ditch attempt, I thought that if DB is twice or more than DA and if the diameter is greater than twice DA, then A cannot catch B, for my third and final WA at 1:59.

25 June 2020

Educational Codeforces Round 90 Postmortem

What went well
  • B, C, D took me 5 minutes, 9 minutes, and 24 minutes respectively.
What went poorly
  • A took 21 minutes (drew a huge blank; no, I did not wake up late), which was a massive penalty, since it increases the penalties for B, C, and D.
  • Couldn't get E in an hour.
Where I got lucky
  • D was on the easier side.

23 June 2020

Codeforces Round #652 (Div. 2) Postmortem

What went well
  • 0:00 submission for A!
  • Got ABCD (albeit slowly).
What went poorly
  • Incurred one wrong answer for B and C each (and took a long time too).
  • Took half an hour to recognize the recursion for the tree structure in D.
  • Thought that the residues of numbers compare the same way as the the numbers themselves (i.e. a > b implies (a % m) > (b % m)…no, just no).
Where I got lucky
  • Got D with 9 minutes to go, which involved a slight wild guess.

21 June 2020

Codeforces Round #651 (Div. 2) Postmortem

What went well
  • Decently fast ABC (0:01, 0:10, 0:23).
What went wrong
  • Walled by D. I didn't recognize that binary search works because I didn't know how to verify that a subsequence with max less than or equal to a target value was doable in O(N).
  • I thought incorrectly (yet again) that O(N lg N) is too slow for N <= 10**6, so I tried something silly to find the minimum # subsequences of the form (01)+ or (10)+, when a straightforward O(N lg N) would have worked.
Where I got lucky
  • Gained rating!

13 June 2020

Bugforces (ft. senile logarithmic exponentiation)

Sad things happen when you lose your mind:
using i64 = long long;

// Precondition: (base, exponent) won't cause overflow
i64
my_pow(const i64 base, const i64 exponent)
{
  i64 accumulator = 0;
  for (i64 exponent2 = exponent, current_power = base; exponent2 > 0;
      exponent2 >>= 1, current_pow *= current_pow)
  {
    if (exponent2 & 1)
    {
      accumulator += current_power;
    }
  }
  return accumulator;
}

04 June 2020

Codeforces Round #647 (Div. 2) Postmortem

What went well
  • Got B in 5 minutes -- straightforward problem.
  • Got C in 5 minutes -- another straightforward problem.
  • Got D in 20 minutes, once I figured out how to read. :-P
  • New personal best!!!
What went poorly
  • Wrote an extremely clumsy solution for A because I decided after a brief tradeoff analysis to match the problem statement as close as possible instead of thinking about a better implementation
  • IlliterateForces strikes again -- misread D, so submitted a solution that solves a similar problem, which cost ~20min and a submission penalty.
  • Couldn't get E.
Where I got lucky
  • Got extremely lucky with B and C. I have been struggling with Bs recently; this B's 5 minute solve time thankfully bucks the trend. My previous fastest C solve time was ~15 minutes.

26 April 2020

Bugforces (ft Education Codeforces Round 86)

Consider the following implementation to find the smallest multiple of x at least as big as y:

typedef long long i64;

i64
next_mult_ge(const i64 y, const i64 x)
{
    return ceil(y / (double) x) * x;
}

What can go wrong?

Educational Codeforces Round 86 Postmortem

What went well
  • Sampling other submissions, my solution to C is cleaner and more intuitive (if only it worked!!!)
What went poorly
  • A took a long time
  • My C implementation died to nuances of ceil(); I wanted to find the multiple of a number at least as large as some threshold.
Where I got lucky
  • I was able to use fast-slow testing to determine a test case that breaks my C.

25 April 2020

TopCoder SRM 784 Postmortem

What went well
  • I was able to solve Div2C/Div1A.
  • I was able to fix a bug in my implementation for C.
What went poorly
  • Got A wrong because I couldn't understand the problem.
  • I realized the bug in my C after submitting my code, so the resubmission incurred a significant (200pt) penalty).
Where I got lucky
  •  Div2C/Div1A seemed a lot easier than usual.

14 April 2020

Codeforces Round #635 (Div. 2) Postmortem

What went well
  • A was trivial.
  • B was easy.
  • I didn't feel stuck when attempting D.
What went poorly
  • C took a long time because I didn't realize that I had to consider two criteria for the greedy solution (first Wrong Answer). Then I didn't realize that the two criteria were not mutually exclusive (second Wrong Answer). All said and done, I spent 1h30.
Where I got lucky
  • Somehow still above 1700!

06 April 2020

CA-1 Drive: Short Version

Start: CA-1 exit off US-101
First choice: CA-1 (orange) or Panoramic Drive (red)
Second choice: Petaluma (blue) or Santa Rosa (green)
  • There's a great restaurant in Santa Rosa called "Naked Pig." They serve the lightest waffles with optional bacon bits embedded.
Return: US-101 South

03 March 2020

Codeforces Ozon Tech Challenge (Div. 1 + Div. 2) Postmortem

What went well
  • C was a silly number theory problem, which I got in ~10 minutes. This might be my fastest C solve yet.
What went wrong
  • I was unable to debug my solution to D in ~2 hours. I initially started pursuing an idea which involved querying vertices from pairs of vertices, but then I wasn't sure which two of the (up to) four vertices I should query. Then I noticed that I can just "trim the tree" by querying two leaves at once and pruning the tree if the LCA were neither leaves queried. However, I overcomplicated my solution by removing the vertices in the path from the leaf to the LCA, so I'm sure the bug is somewhere in there.
  • I wasn't sure how to prove B, which took me 20 minutes to solve.
Where I got lucky
  • I gained elo so my rating is back above 1700. Yay!

30 January 2020

Educational Codeforces Round 81 Postmortem

What went well
  • If I had actually solved 4 problems, I would have gained over 100 elo…
  • I solved D, which was a number theory problem. (Nick missed this problem; muahahaha)
What went wrong
  • My impure thoughts on problem B died on system test #11. Since I passed all 10 pretests, I didn't think to revisit my solution and verify with fast-slow testing.
  • I took a long time to recognize the totient function. My first reaction was "some inclusion-exclusion counting" upon realizing a pattern from my scratch work. Then I needed two tries to code a fast (sqrt N) totient function.
 Where I got lucky
  • Everyone else died on B. Turns out it is rated 1800.

19 January 2020

Codeforces Round #614 (Div. 2) Postmortem

What went well
  • A was a fast 3-minute problem.
  • B was easy and I solved it decently quickly in 9 minutes.
What went wrong
  • C took way too long to code, mainly because I didn't have a good representation on blocking either diagonal path. Turns out that if cell (r, c) is blocked, then I just needed to check (1-r, c-1), (1-r, c), and (1-r, c+1). Furthermore, if I used a 2x(N+2) grid instead of 2xN grid, then I wouldn't have to do any bounds checking because the (*, -1) and (*, N) cells could never be set.
Where I got lucky
  •  I didn't do so terribly so as to get demoted to green.

16 January 2020

TopCoder SRM 775 (Div. 2) Postmortem

What went well
  • My TopCoder career is off to a good start! I solved A and B for +199 rating, which puts me midway through blue (1300-1499).
What went wrong
  • I apparently failed to understand A, so wasted 5 minutes implementing something else.
  • I was rusty on floodfill and took 40 minutes to solve B, where 30 minutes was debugging.
Where I got lucky
  • I'm decently quick on easy problems, which luckily A and B were.

14 January 2020

Educational Codeforces Round 80 Postmortem

What went well
  • The contest was so hard that I really wanted to quit after reading A, but persevered to the end. Somehow I solved three problems…
What went poorly
  • I'm terrible with floors and ceilings. I'm also apparently bad at quickly recognizing monotonic functions.
  • I'm also bad at bijecting problems; I did not recognize during the contest that C was asking for a monotonically increasing sequence of length 2n, rather than two sequences of length n with weird constraints on elements.
Where I got lucky
  • Solving three problems with a high penalty only cost 8 elo.

10 January 2020

Codeforces Round #613 (Div. 2) Postmortem

Link to contest here

What went well
  • I found a most elegant solution to B: much more elegant than the editorial.
  • I figured out D, a bits (bitmasks?) problem! I think I'm really weak at bits and xors.
What went wrong
  • B took ~50 minutes and two wrong submissions.
Where I got lucky
  • I had to think a little for A to prove correctness, but end-to-end latency still only took 3 minutes.
  • I submitted C without proving correctness and got it right??! Lucky me!

06 January 2020

McLaren 600LT Spider First Impressions

Author's note: This test drive was done in April 2019, but I have been procrastinating with publishing this post. In any case, enjoy!

I had the opportunity to drive a 2020 McLaren 600LT Spider at McLaren of San Francisco! I never got a chance to test drive a 600LT couple since their debut last year, nor have I gotten a chance to test drive a 570S Spider that I so dear wanted once upon a time. Unfortunately, the test drive happened during mid-day on a weekday, which wasn't the best time to tour back roads.


600LT specific comments:
  • No creep! This is important to me because I struggle with chauffeur braking in automatic transmission cars. On that note, I also appreciate that Tesla provides a no-creep option.
  • Same great hydraulic steering is considerably heavier than in the 570S and 570GT, especially in "track" handling mode.
  • The gunshot/whip crack downshifts are not a lie. They are incredible to experience with the top down.
  • No flames were to be seen during mild street driving in daylight :-(
  • I feel like the LT cars have stiffer (or just solid) engine mounts. I felt a massage from the seat while sitting at a red light.
  • No comment on the upgraded brakes; they were fine for street use. No comment on comparing the upgraded system from the 720S to the normal ceramics on the 570S or to the steel brakes in the 570GT.
  • No comment on the lighter weight. Need to hit the back roads or track…
  • No comment on downforce from its cute little fixed wing. Definitely need to push a bit on the track for that.
  • The normal power seats didn't go as far forward in this 600LT as I thought they would. Speaking of normal power seats…
  • This test car didn't have the critically-acclaimed Senna seats! I think that the dealer has a second demo Spider with the Senna seats. I hope I can take that car for a proper spin!
Yes, this is my normal seating position. Marvel at the amount of space behind the seat!

Other:
  • I preferred the short metal shift paddles over the extended carbon fibre paddles. Something about the metallic clink when I tap my fingernails on the paddles that's lacking with the carbon paddles…
  • Having experienced the 720S Spider roof mechanism, the legacy system in the 600LT Spider feels slow as I put the top down prior to leaving the dealer.
  • Sport Series Spider cars: the high shelf provides little rearward visibility regardless of roof position. (but who needs to see what's behind them in a supercar??)
  • 2018 and later Sport Series cars: Backup camera is in the instrument cluster screen. To me, it's harder to use in conjunction with the rearview mirror than the postage stamp display in the centre screen in the 2016/2017 cars.
  • Chicane Effect is Chicane Grey with orange metallic flakes:


I really want to do a proper test drive in the back roads with little traffic, and in a car with the Senna seats. This will almost certainly need to happen on a Saturday morning shortly after the showroom opens at 9a!

How I would spec this car: pretty barebones. The only "must-haves" I think are the Senna seats, as well as small practical items such as the soft-close doors, front lift, and battery charger. Skip the visual carbon exterior (the standard palladium pieces are actually painted carbon fibre pieces), skip the carbon interior, skip the leather, skip the audio…
  • Colour of my choice. These days, I'm feeling MSO Amethyst Black, ever since having seen a Senna in this colour during Car Week last year.
  • Standard 10 spoke wheels.
  • Soft close doors.
  • Standard Alcantara interior. Maybe splurge for the orange "By McLaren" Alcantara interior if I'm feeling lucky…
  • Senna seats, regular fit.
  • Front lift.
  • Battery charger.

Before driving this car, I used to think that the 600LT coupe is the car to get because of the possibility of the roof scoop (for the uninitiated, it makes for an unique soundtrack). However, that's available in any LT coupe, and the uniqueness of the top-firing exhaust in the 600LT cars is most accentuated by a convertible, which was confirmed by this short drive. Therefore the 600LT Spider is now my pick of the two.

[1] Neoprufrok, Roof scoop noises. https://www.youtube.com/watch?v=rte0WJjJIgU
[2] Vehicle Virgins, 600LT delivery. https://youtu.be/-XqaoHCWuK0?t=936

05 January 2020

Codeforces Round #612 (Div. 2) Postmortem

Link to contest here

What went well
  • I know how DP works?!
What went wrong
  • I failed to read B correctly the first time. The problem is about Set (the game), which I have only played once, over 10 years ago. I thought that all features had to be same or different, instead of each feature being independent of each other.
  • I took an hour to debug C because I wasn't confident in my dp transition function. Amusingly, my initial state was wrong, which luckily triggered an assert I left in my code, quickly highlighting an issue.
Where I got lucky
  •  Somehow placed in the top 5% with just ABC???!