FaceKicker

That was a summer project after my last semester of undergrad, posted at the beginning of my first semester in a PhD program in AI (lucky timing there). Graduated in 2017 and have been working in the field since.

I tried GP's example, and in this particular case both --patience and the default (Myers) work the same, both doing the thing you want them to. Which perplexes me, because I know I've seen the bad case too, but can't seem to find a minimal example of it (I tried a couple variations on the example; they all did the 'right' thing).

I agree that repair costs and depreciation grow (probably roughly linearly) with miles driven, but those would have been factored into the $9100 median separately from the car payment.

> But it's not like his car payment magically disappears when he becomes a Lyft driver. Or magically stop having to carry insurance.

Right, my point is that those costs are essentially fixed w.r.t miles driven, not that you wouldn't need those things. If you drive 36000 miles a year as a Lyft driver your car payment is still the same as someone who drives 12000 miles a year, whereas the author's model assumes the payment would be 3x as much. And re insurance, I know insurance companies take mileage into account in determining insurance premium, but it's certainly not the only thing in the formula.

> According to this Consumer Reports article, “the median car costs more than $9,100 a year to own” over the first five years of ownership driving 12,000 miles a year. That means the median cars costs about 76 cents per mile driven ($9100/12000). I’m just guessing that I’ll average a speed of 30 miles/hour while I’m doing my Lyft job. So my expenses will come to about $22.80 per hour (0.76*30).

Doesn't that $9100 a year median include a bunch of fixed costs (or at least costs that wouldn't grow linearly with the mileage driven)? e.g., the lease/cost of car itself, insurance, etc. I'm not saying this would take the profitability of being a Lyft driver from pretty terrible to great, but it does seem like a pretty significant oversight.

Ah, cool, my mistake. Thanks for the clarification!

"Works like a debit card when you swipe it" - I'd probably get this if I wouldn't effectively be paying several hundreds of dollars per year for it in losses of credit card rewards.

> One thing that annoys me about closed ranges (and it's not much talked about) is that it is impossible to express the empty range: in python [i:i] is an empty range, while closed ranges always contain at least one element. That makes closed ranges strictly less expressive than half-open ranges, making often necessary to write special cases for zero-length.

In matlab/octave you can write an empty range as a(i:i-1). Not to say that that's at all elegant or aesthetically appealing, but it does work. But I 100% agree with the sentiment; one of my favorite things about using NumPy rather than matlab in my research code is the vastly superior indexing, in large part due to the fact that it's 0-based. matlab's indexing really is painful and off-by-one-error prone for doing anything other than a(1:n).

Scenario A: The setup is (1) lose $100, gain 1 ticket (current state is -$100, +1 ticket); (2) lose 1 ticket (current state is -$100, 0 tickets). The choices are (a) lose $100, gain 1 ticket (yields state -$200, +1 ticket) or (b) do nothing (yields state -$100, 0 tickets).

Scenario B: The setup is (1) lose $100 (current state is -$100, 0 tickets). The choices are the same as above.

The final 'state' at the end of each setup is the same, and the choices are the same, so the argument is that a rational actor would make the same choice in both situations. Maybe there's an argument that the state should include more than just $ and tickets though?