lqr
Even if they manage to avoid straight-up factual incorrectness, the writing is full of ambiguities and vagueness when you look closely. Meanwhile, space is wasted repeating the same claim in multiple ways, or explaining something simple.
They also seem unable to resist the hype/advertising tone, overselling the contribution while exaggerating the limitations of related work.
I would much rather read grammatically incorrect or awkward sentences.
While academic writing does have a few pointless historical conventions, the huge majority of "status quo writing style" is a logical consequence of 1) minimizing ambiguity, 2) organizing ideas coherently, 3) distinguishing opinion/interpretation from fact, and 4) providing enough detail to be reproducible.
An oblate spheroid is an example of a Riemannian manifold: a smooth object that looks like a plane (or, in general, any ℝ^n) locally, and has a way to measure angles between vectors in that local plane.
All Riemannian manifolds have an object called the Levi-Cevita connection, which defines how vectors in the local plane (tangent space) most naturally map to vectors in other tangent spaces in the immediate neighborhood.
Standing at a point on the Earth and looking in a certain direction gives us 1) a point on the manifold, and 2) a direction in that point's tangent space.
We then take an infinitesimally small step forward, and apply the Levi-Cevita connection to get from the old tangent space to the (infinitesimally nearby) new tangent space, and repeat. This defines an ordinary differential equation. Integrating the differential equation gives us a curve through the manifold.
Within some neighborhood of the initial point, this curve is a geodesic, i.e. the shortest path between the initial point and all subsequent points on the curve. This matches our typical intuition of "straight".
(Disclaimer: I am currently learning about this topic, but am not an expert.)
edit: https://en.wikipedia.org/wiki/Geodesics_on_an_ellipsoid goes into some interesting specifics about the results of this process on ellipsoids.
I wish there was some way to do the same for programming. Imagine a classroom full of machines with no internet connection, just a compiler and some offline HTML/PDF documentation of languages and libraries.
If you sample a random person with a math degree, the probability that they believe Erdos had more impact than Euler is 0. ;)
The application-submitting phase of the current cycle is over for TT positions, and some of the listings have been taken down. No idea if non-TT hiring follows the same cyclic pattern. But if the listings are looking thin, you should check again around November.
Not having a Ph.D. might disqualify you for some positions, but definitely not all of them. Teaching experience with positive evaluations will help a lot!
I wouldn't worry too much about laid-off developers/researchers. The huge majority of them will try to find another high-paying job.
Frank-Wolfe is a somewhat less well-known (compared to simplex, interior point, etc) convex optimization algorithm with many interesting properties [2, Section 3.3].
But once you get into something more sophisticated like using rotations in a dynamical system, statistical filtering, optimizing a rotation, etc., the abstractions begin to leak.
Often you realize that some parts of the original problem statement were adding complexity with no real benefit. And the techniques you use for the simple version are likely still relevant for the big version.
If the simplified version is still hopelessly difficult, it might be a good starting point for a counterexample/lower bound to convince yourself that the full problem is hard.
Loose coupling is good if you mainly use open-source packages and modify one component for your research paper. I'm not sure it's a net positive when building most components yourself.
A big multithreaded program can still use queues instead of locks to share data between threads.
> We introduce algorithms that use predictions from machine learning applied to the input to circumvent worst-case analysis. We aim for algorithms that have near optimal performance when these predictions are good, but recover the prediction-less worst case behavior when the predictions have large errors.
An example is using learning to decide which variable to discretize next in a branch-and-bound integer linear programming solver. The algorithm might be extremely similar to the classic version, but the analysis is new.
https://arxiv.org/abs/2006.09123
More broadly, I think there's a lot of work on applying more refined analysis to classic algorithms - online settings, smoothed analysis, etc.
> The main difficulty is high dimensionality. We simply do not have mathematical frameworks to analyze structures in the 100s of dimensions.
The main difficulty in deep learning is the non-convexity of the optimization problem. We can handle simpler problems in high dimensions just fine. The oracle complexity bounds for projected gradient descent in convex optimization even hold for infinite-dimensional problems - see work of Nesterov.
Most of the hard questions about deep learning remain hard even for neural networks with low-dimensional inputs, outputs, and hidden layers. Also, some of the more fruitful approaches in deep learning theory involve taking the limit as the width of one network layer goes to infinity.
> For some reason, theoretical computer science seem to contribute quite little to the practical deep learning world, while primarily concerning itself with the complexity theory and computability questions. Fun stuff, but... Somebody needs to do this.
Lots of theoretical researchers are trying to figure out why deep learning works. Check out the work of Jason Lee, Simon Du, Sebastien Bubeck, etc. Most of these researchers have a CS background.
TL;DR: Under reasonable assumptions, one should choose a stew volume such that half of the stew is consumed each day.
As academics, I feel we should put in our best effort to use and contribute back to open-source platforms. It's not crazy to spend the first year of your PhD adding a feature to an open-source package if it will boost your research productivity for the next 4 years. It's also easier to work around limitations when you only need to run one experiment instead of producing a robust product.
[1] Qualcomm Snapdragon Flight, a RPi-sized board with onboard stereo cameras and GPS. The hardware was unbeatable at the time.
Therefore, angular velocity is determined by jerk - the rate at which this thrust vector is changing.
The angular velocity cannot be changed instantaneously, because the quadrotor can only exert a finite torque about its rotational axes. So we need to design trajectories that do not attempt to change the angular velocity -- and hence, the jerk -- too quickly.
Therefore, we should try to minimize something like the maximum norm of the snap along the trajectory.
In practice we often minimize the integral of the squared norm of the snap, because it can be posed as a convex quadratic optimization problem with respect to the control points of a spline.
It's always worth trying a multi-start approach, i.e. run the same algorithm more than once (in parallel if possible) with different random initial guesses. If your problem is differentiable, then multi-start continuous optimization (gradient descent, Newton's method, etc.) can be more efficient than something like SA.