28 May 2021

Thought process on Codeforces 1353E

Link to problem

I remember seeing this problem almost a year ago during practice and getting stuck. Well, I finally solved it almost a year later!


Since the problem asks about equal spacing (of length K) between 1s in a binary string, I immediately  thought of numbers of 0s and 1s for each residue mod K. We have enough time to try each residue if the work for each residue is linearly proportional to the number of bits in each residue, i.e. K residues * (N / K) bits in each residue = O(N) total work. We know that while we are trying each residue, the bits at positions not congruent to K mod N have to be off, which is an easy precomputation done in O(N).

Our solution looks like this so far:

i64 solve(const i64 N, const i64 K, string_view S) {
  i64 total_on = 0;
  vec<i64> resid_on(K, 0);
  for (i64 i = 0; i < N; ++i) {
  	total_on += S[i] == '1';
    resid_on[i % K] += S[i] == '1';
  }

  i64 best = N;
  for (i64 resid = 0; resid < K; ++resid) {
    let i64 turn_non_resid_off = total_on - resid_on[resid];

    // gather the bits at resid (mod K) for convenience
    vec<bool> seq;
    for (i64 i = resid; i < N; i += K) {
      seq.push_back(S[i] == '1');
    }
    // TODO implement solve_resid
    let i64 subproblem_ans = solve_resid(seq);
    best = min(best, turn_non_resid_off + subproblem_ans);
  }
  return best;
}

Let's focus on bits at positions whose residues are resid (mod K). We know that they have to form the pattern 0*1*0*, i.e. 1111, 00111, 1000, 0000, 010, etc. So we have reduced the main problem to this problem. How do we solve it?

At first, my smooth brain thought this could be done with greedy. My approach was ignore leading 0s, ignore the 1s after the leading 0s. At the same time, ignore trailing 0s, and ignore the 1s before trailing 0s. Now we want to turn all the bits on in the middle subsegment. However, this fails on a case like:

10 2

0001000100

Because we can simply turn off one of the 1s rather turn on the 3 zeros in the middle.

At this point, my mind turned to dynamic programming. I started building my recurrences as follows:

  1. Define f(pos) = minimum moves to make the suffix [pos, N) valid.
  2. Define g(pos, state: {0, 1}) = minimum moves to make suffix [pos, N) valid such that bit at pos is state. This implies:
    1. g(pos, 1) = (pos != 1) + (moves to make the suffix [pos + 1, N) have the pattern 1*0*)
    2. g(pos, 0) = (pos != 0) + f(pos + 1)
and we want to solve for f(0), which is min(g(pos, *)). The wildcard used here and below represents all possible values for that argument, i.e. {0, 1} here.

This looks promising, but what is (moves to make the suffix [pos + 1, N) have the pattern 1*0*)?? It looked suspiciously "nice", i.e. something that I might be able to turn into a recurrence. OK, let's try that:
  1. Define h(pos, state) = minimum moves to make the suffix [pos, N) have the pattern 1*0*. This implies:
    1. h(pos, 1) = (pos != 1) + min(h(pos + 1, *))
    2. h(pos, 0) = \sum_{i = pos}^N (i != 0)
Well that was nice indeed. Putting it together by plugging h into g, we have:
  1. g(pos, 1) = (pos != 1) + min(h(pos + 1, *))
  2. g(pos, 0) = (pos != 0) + f(pos + 1), as before
Implementation is straightforward:

i64 solve_resid(const vec<bool>& seq) {
  vec<vec<i64>> h(seq.size() + 1, vec<i64>(2));
  for (i64 i = seq.size() - 1; i >= 0; --i) {
    h[i][0] = seq[i] + h[i + 1][0];
    h[i][1] = !seq[i] + min(h[i + 1][0], h[i + 1][1]);
  }
  vec<vec<i64>> g(seq.size() + 1, vec<i64>(2));
  for (i64 i = seq.size() - 1; i >= 0; --i) {
  	g[i][0] =  seq[i] + min(g[i + 1][0], g[i + 1][1]);
    g[i][1] = !seq[i] + min(h[i + 1][0], h[i + 1][1]);
  }
  return min(g.front()[0], g.front()[1]);
}

Voila, Accepted!

19 January 2021

FLPoTD: Writing Checks

This problem was inspired by a puzzle on the 2021 Mystery Hunt:

Given a string S of characters from the latin alphabet (a-z), find the smallest nonnegative amount (dollars and cents) whose spelled-out representation contains S as a subsequence.

  • The dollar amount should not include 'and': 123 is "one hundred twenty three", not "one hundred and twenty three".
  • If the amount is less than $1.00 (one dollar and zero cents), then the dollar amount is omitted: $0.46 is "forty six cents"
  • The cents is always expressed: $46.00 is "forty six dollars and zero cents"
  • This table contains the names of powers of 10: https://en.wikipedia.org/wiki/Power_of_10#Positive_powers
Follow-up:
  • Given a list of strings, all of which use exclusively lowercase letters, find the most expensive word.

30 September 2020

Min-Max Driving Sim

I have always wanted a driving sim, especially after reading about fellow driver/instructor Ian Korf's positive experiences, but don't have much space and didn't want to spend a crazy amount of money.

To give you a sense of the driving sim landscape: on the low end, you have wheels without any force feedback (around the $99 mark) to 6-axis full motion sims for >$60k, which are not dissimilar what professional drivers use for training.

Here's what I got:

ComponentPrice (includes shipping & tax)
VendorWhen Purchased
WheelSimXperience Accuforce$1055.64simxperience.comJul 2020
ComputerDell Inspiron 3670$402.37Dell OutletDec 2018
GPUZotac GTX 1080 mini$369.00eBayFeb 2019
PedalsFanatec Clubsport v3$356.60eBayJun 2019
SeatPlayseat Challenge$242.93AmazonJul 2020
VR HeadsetLenovo Explorer$99.00B&H Photo VideoNov 2018
Power SupplyEVGA 500 W1$43.29AmazonJan 2019
Total$2568.83

I optimized for great driver inputs, e.g. the wheels and pedals. I figured that direct drive is the way to go, and read good things about the Accuforce. Popular alternatives included the OSW (OpenSimWheel) and the Fanatec Podium 1 & 2. I decided against hydraulic pedals (>$1+k, unless you mod your Logitech G920 brake pedal). Looking at options half an order of magnitude lower, the Fanatec Clubsport was the popular choice.

I wanted the sim rig to take up the smallest amount of space and be easy to move, while having a solid mount between the seat and pedals so that the pedals won't slide away from me during braking. The Playseat Challenge was the obvious choice. It even has mounting holes, which are compatible with the Accuforce!

I didn't want to spend very much money or effort on the PC, so I went with a refurbished Dell with passable specs. This unit has a 6-core i5-8500, 8GiB RAM, 1TB spinner, and integrated graphics. Obviously I needed a better GPU to drive the VR headset, so I went with a GTX 1080 (not Ti). It turns out that the current generation of consumer desktops are barely wider than a mATX board, so I need a shorter version of a full-size GPU. Finally, I needed a beefier PSU that the Dell's 300W unit.

If I insisted on building the PC myself, then the components (at the time of purchase, late 2018), would have not been much cheaper. The CPU retailed for $192, motherboard $80, memory $35, disk $40, for a total of $347, which is ~$20 less than the Dell cost before sales tax. (Obviously I would sit the parts on a piece of cardboard instead of getting a case, as well as ditching the optical drive and WiFi, if not integrated into the motherboard)

Finally, for an immersive experience, I went with the (now discontinued) Lenovo Explorer VR headset. I wanted something with at least a 1440x1440 eyepiece resolution since I had a bad experience with the first Oculus Rift, which had an eyepiece resolution of 1080x1280 -- I got extremely nauseous trying to focus on a blurry-to-my-20/13-vision image.

So there you have it! A solid setup, which fits conveniently into any corner:

For its inaugural drive, I spent an hour playing Assetto Corsa driving at the WeatherTech Raceway Laguna Seca in various cars (30min in a NA Miata, then a bit in a McLaren 570S, and the rest in a Porsche GT4 Clubsport). Works pretty well!

Its next upgrade will likely be a yoga mat since the Accuforce's vibrations are felt throughout the Playseat chassis.

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?