Even if you get the perfect training data, the state-of-the art neural networks will not be 100% reliable. Convolutional neural networks work by recursively recognizing shapes. In theory, the first layer should match the picture on something like this and conclude "it's probably an eye":
o o X o o
o X X X o
o X X X o
o o X o o
(above, "X" denotes low relative brightness, "o" denotes high relative brightness).
The next convolutional layer is supposed to see something like this and conclude it's a face:
(eye) (not a bumper) (eye)
(not a door) (nose) (not a wheel)
(not a shovel) (mouth) (not a window)
That's in theory. In practice, each input to the second layer will be a vector of probabilities. Like 90% eye, 80% wheel, 1% door. The output will also look like a vector of probabilities, and the layer is supposed to figure out a linear formula matching inputs to outputs that results in the best statistical outcome. So it can very easily come up with kernels like this:
* A: (an eye or a wheel) and maybe a bumper to the right of it
* B: (an eye or a wheel) and maybe a bumper to the left of it
* C: (two wheels) side-by-side
In this case, the baby face will be encoded as A together with B and definitely not C. Because each next level produces a linear combination of the previous level's outputs, the "or a wheel" parts will get nicely canceled out as long as the "2 wheels" kernel input is a low value, concluding that it's a face with a confidence of 99%. Until the light falls from a different angle and the baby holds a round lego brick near their face, suddenly yielding 80% confidence that it's a car.
Drawing parallels to organic life, neural networks are good at replicating inborn instincts. Like animals instantly recognizing predators, food or poisonous plants. But they are still far away from having a situational awareness needed to make judgement calls in most real-world situations.
Turns out I'm not alone who spent considerable time fighting with CMake configuration issues. I ended up patching it to support a basic debug server protocol, so you could step through the CMakeLists.txt files in a debugger. In case anyone's interested, here's the CMake fork with debug support [0] and there's a detailed tutorial [1].
Sure, an FPGA does the job faster, but how popular are the FPGA boards compared to something like STM32 Nucleo? What we are trying to achieve is make a software logic analyzer that will work on top of the hardware that everyone has for prototyping anyway. 8 boards is just the beginning...
Oh yeah, we looked into the open-source ones. The main problems there were irregular sampling and software that will make you sweat before you get your first reliable measurement. So we wanted to create something that will be extremely easy to use and will reliably work out-of-the-box.
I guess, this is a lot about the taste and preference, but an IDE is much more than a text editor. Talking about debugging, there's an illustrated listing of top 10 Visual Studio debugging tricks here: http://visualgdb.com/debugging/
It would be interesting to see how could one do something as efficient with just a text editor.
That's probably because people are different. And so their tastes and habits are. That's why there are Windows, Linux and MacOS all co-existing in parallel. That's why there are iPhone, Android and Blackberry. That's why where are Mercedes, Toyota and Chrystler...
I guess, you just like the command-line tools more, as many other guys do. And lots of other people really enjoy GUI tools such as Visual Studio. And the goal of the article is to show those guys that they can now enjoy their favorite IDE while developing for Raspberry PI.
Hey, what about all those guys that are used to "Plug-and-play" tools like Visual Studio? That don't want to rediscover the common problems and spend countless hours trying to figure out how to do something slightly less trivial than just Hello, World? What if somebody just wants to get things working fast and does not want to learn how to make the cursor move up in vim?
There are for sure a lot of guys used to simple tools like vim, but there are also plenty of people that believe that tools are just tools and the more intuitive the tools are the better it is.
And as for the development today, it's becoming more and more about the result and not about the process. About how fast you can get your application or game up and running. And hours spent on figuring out why something is not working when it should is becoming rather an avoidable annoyance than the experience of "real" programming.
Well, you could also say that gcc is a 10-megabyte shim for the GNU assembler and would prefer to code each and all your programs in assembly language.
However at some point you would probably get bored computing the stack offsets manually each time and would let the C compiler do it for you, while you think about more high-level problems.
Same with debugging. GDB itself is cool for small simple projects, but once your project becomes large enough, you would probably just enjoy clicking on a line to make a breakpoint and hovering your mouse over an expression to see itsvalue rather than typing the line numbers and variable names manually each time and keeping it the back of your mind where was the breakpoint #42...
And, BTW, if you're a student, it's only a half of the $99 for you...
In fact, that purely depends on your goals. If you're just tinkering around, the text editor or something simple like CodeBlocks or KDevelop is probably fine.
If you are doing a bigger project where productivity becomes a must and spending time on doing the same routine things over and over becomes annoying - an IDE as powerful as Visual Studio can be a really good investment...