lqr

In CS right now, people with a very strong PhD can go straight to the tenure track.

I took a postdoc because my PhD is solid but I jumped around topics a lot, so it's not quite coherent enough. My postdoc is also at a more prestigious institute.

I'm rolling the dice that it might be enough to get that tenure track job. But I also have no dependents and don't care about material possessions very much. If my situation were a little bit different, it would be foolish to do what I'm doing.

Looked it up, it seems more targeted to page layout applications. Is it really that much better for something like a drawing in a math textbook?

If the author is here: There is a mistake in this article. In Section II, the text discusses a wagon capacity of 19, but the code and printed output are for a wagon capacity of 1000.

I take notes on the lowest-tier Strathmore 9x12" spiral-bound sketchbooks. I strongly prefer totally blank paper for math and diagrams. The paper is plenty high-quality, you can tear out pages without ruining the appearance, and they are cheap.

However, I don't view those notes as a permanent record. Anything really important gets transcribed to LaTeX (math) or text files (TO-DOs, etc.)

The transcribing takes extra effort. I'm not sure it's worth it, but it's a good opportunity to distill things to their essence and double-check logic. My future self doesn't need to wade through as many dead ends when looking back later.

Matlab toolboxes: Lots of algorithms. Good documentation. Converting LPs/QPs into standard forms is kind of a fun puzzle but very error-prone. Manual gradient/Jacobian for general nonconvex/nonlinear problems can be painful. Not open-source, so I stopped using it.

SciPy.optimize: Similar pros/cons as Matlab other than open-source.

CVXPY (& its default backends): Modeling languages are great. First thing I will try for a new convex problem.

CVXGEN: Amazing, but infuriating that it can only be used through a web app.

PyTorch: Only supports unconstrained first-order methods. Automatic differentiation of arbitrarily complex functions is huge. Somebody should implement interior-point and SQP on the GPU for PyTorch.

---

As a researcher, my first impression is that your product is designed for people who want to deploy optimization in some service or business process, not for me.

In another life I would love to be a BCI researcher.

The poster is an advertisement for the paper. Same goes for oral sessions. Almost all talks include the phrase "for details, see our paper".

Posters are a nice middle ground between an abstract and a full paper. Spending 5 minutes at a poster talking with the author is almost always enough information to decide if you want to read the paper carefully. This is especially important in theoretical fields where it can take hours/days to fully comprehend difficult proofs.

Poster sessions are also important for meeting people in your niche.

The Perceptron is also interesting because its classic mistake bound analysis is one of the earliest instances of modern learning theory. The mistake bound states that if the data is linearly separable (i.e. a perfect linear classifier exists), then Perceptron makes no more than (r / m)² misclassifications, where r is the radius of a ball containing the data set and m is the margin between the two classes.

The analysis is modern because 1) unlike traditional statistics, it does not make any assumptions about the distributions of each class, and 2) is a non-asymptotic guarantee. It is also an online analysis, in the sense that it only compares performance against the optimal fixed classifier for the sequence that was actually observed, rather than any notion of an underlying distribution.

More details: http://www.argmin.net/2021/11/04/perceptron/

It does seem like it should be simple to avoid those. I can imagine it might be complicated if the model treats turns as instantaneous and only considers edges in the road graph as taking time.

I would love a road navigation tool that gives more options to modify the cost of various route features other than pure distance/traffic. To me, Google is too willing to give a complicated route to save a tiny amount of time. It makes the driving more mentally draining. I would raise the cost of all turns, stop signs, and intersections where I don't have priority.

If by "unprotected" you mean "no green arrow", in what part of the LA area is it feasible to avoid unprotected lefts? They are all over the place in my neighborhood.

If by "unprotected" you mean a left from a stop sign onto a street that does not stop, then I agree. They can be almost impossible. Waze was especially notorious for them a few years ago.

The LP solver might find a solution with fractional toys.

If we add the constraint that x must be an integer vector, then it becomes an integer linear program. Solving integer linear programs is NP-complete.

My main workflow improvement over the course of my PhD has been making my papers reproducible. This means: I clone a github repo, then I execute a single command to re-run all computations, re-generate all figures and tables, and compile the final paper.

Any manual step like "resize the figure window until the proportions look good", or "run script A, then run script B", or "upload this file to Overleaf" creates an opportunity for your results (figures and tables) to become out of sync with your source code. This can cause big problems.

I use Makefiles, Anaconda, and Github CI to accomplish this [1], but the techniques don't matter. The point is the end goal.

More broadly, in research it's always tempting to do things quick and dirty. Conference deadlines loom. Code bases are usually small and short-lived. But in my experience, your 4-months-later future self will appreciate tests, documentation, etc. just as much as your 4-years-later future self.

You can still be quick and dirty when it comes to project scope. This is where you get most of the speedup anyway. Go ahead write a function that doesn't handle edge cases, but add a comment about it!

[1] https://github.com/jpreiss/reproducible_papers

Geometrically-growing arrays (std::vector) and hash tables also have amortized O(1) insertion complexity. They are some of the most widely-used data structures of all. I agree that amortized guarantees can be a problem in certain applications, but it seems that programmers are happy to accept them most of the time.

One example with model-based RL is "World Models" by Ha and Schmidhuber. They pre-train an autoencoder to reduce image observations to vectors, then pre-train a RNN to predict future reduced vectors, then use a parameter-space global optimization algorithm (but any RL algorithm would work) to train a policy that's linear in the concatenated observation vector and RNN hidden state.

The important thing here is that the image encoder and the RNN weren't trained end-to-end with the policy. The learned "features" captured enough information to be an effective policy input, even though they only needed to be useful for predicting future states.

It's also interesting that the image encoder was trained separately from the RNN. I think that only worked because the test environments were "almost" fully observable - there is world state that cannot be inferred from a single image observation, but knowing that state is not necessary for a good policy.

Graphics-wise, the assumptions are quite different. Game scenes are a large collection of low-detail objects that are constantly moving and not all visible at once. CAD scenes are a small collection of high-detail objects that don't move except in response to input events.

If the CAD project is big and serious, I would be afraid of eventually hitting some limitation of the game engine that is hard to work around due to such different assumptions.