m3koval

It should be possible to do that using one Ethernet port using VLANs. You could buy a cheap L2 managed switch and use it to trunk two different Ethernet networks on the same port. Then you would configure the Linux networking stack to split the VLANs into separate interfaces.

I am by no means a networking expert and was able to use technique to work around a similar issue in the past. It was easier than I expected!

SIGBOVIK is a parody of computer science conferences. It's a running joke hosted on April Fools Day every year at CMU - and apparently a quite convincing one. ;-)

Source: I attended SIGBOVIK a few times in grad school.

As someone who lives in Pittsburgh - and likes the city quite a bit - I can attest to the fact that: (1) the weather is rarely perfect, (2) the entire city is under perpetual construction, and (3) the lines have not been painted in years. It took me quite some time to comfortably drive in the city because to the narrow streets, poor road maintenance, and bizarre traffic patterns induced by the many bridges and tunnels.

It will indeed be interesting to see how the well the Uber deployment goes in practice. They certainly did not choose an easy place to start.

Concepts, modules, a file system library, and an asynchronous I/O library have all been discussed as additions for C++17 and beyond. Most of these features are standard in modern languages. I would not consider any of these to be "scarcely useful." As someone who uses C++11 on a daily basis, I very much look forward to using these features without a Boost dependency.

That being said: I don't think that a graphics is a good addition to the standard library. It would tremendously difficult to standardize this for the reasons others have mentioned.

I had this issue fixed on my mid-2012 15" rMBP. It's known issue with some of the early LG panels on that model. The technician at the Apple store ran some standard image persistence diagnostic script to replicate the issue.

They replaced the display for free outside of AppleCare. I didn't have to argue with them at all, so I suspect that this is their standard response. YMMV if you have a newer model.

The bitfield example is misleading. Section 6.7.2.1/10 of the C99 standard says:

"The order of allocation of bit-fields within a unit (high-order to low-order or low-order to high-order) is implementation-defined"

There is no guarantee on the order of the bits inside a bitfield. The compiler may also introduce padding, e.g. for alignment purposes. This makes bitfields unusable for unpacking binary data.

Unfortunately, you're stuck with shifting and masking to replicate the same effect.

Why would you not use A* from the beginning? It's a trivial extension to Dijkstras and is often orders of magnitude faster when an informative heuristic is available.

Also, both algorithms require identical data structures. After all, Dijkstras is just A* with a zero heuristic.

I do agree about the constant factor, though: it's likely that a binary heap would be faster on most data sets.

Unfortunately not. Matrix inversion (or any type of linear algebra, really) deals with real numbers. This problem is nearly a linear program, which can be solved very efficiently, except that some variables are constrained to { 0, 1 }. As a result, it's an integer program, which is NP-hard. Intuitively, this is hard because there are no derivatives (e.g. gradient, Hessian) to exploit in discrete optimization problems.

One heuristic is to solve an IP is to relax the integer constraint to inequality constraints, solve the LP, and round the results. However, this can do arbitrarily poorly on most problems.

Nit: You can't, by definition, prove an axiom. Memorizing axioms is quite necessary because they are the building blocks for all other theorems.

In any case, I don't disagree with your high-level point.

Matlab is much faster. For a sense of scale, a relatively simple image processing script ran 125 times faster in Matlab than Octave. This is, most likely, because Matlab has a better code optimizer.

I don't see a compelling reason to use Octave unless you're trying to avoid paying for a Matlab license. If you're going to switch tools, why not switch to NumPy/SciPy and get the advantage of using a full-featured programming language?

Like antics said, this isn't true for graph planning. Here are three concrete examples that I know of:

1. Anytime D* was used by the winner of the DARPA Urban Challenge

2. Field D* was used by Spirit and Opportunity on Mars

3. ARA* (and other A* variants) are a method of optimal motion planning in robotic manipulation

It's not that uncommon in CS. I just started a Ph.D. program (Robotics at CMU) straight out of undergrad and a decent number of the other incoming students are in the same boat. It varies depending upon the field and the university. For example, several of the top mechanical engineering programs require a M.S. to apply for the Ph.D. program.

I doubt it. The article makes this sound pretty specific to producing the magnetic disks used in hard drives. I don't see any reason why this would also work for silicon processes.