The core problem with the "just a neural net" idea is how to tell a robot what it is supposed to do; the whole AI currently relays on some sort of external harness either training the model or pushing the control algorithm into a desired operation. You may implement something very thin like artificial pain or hunger, but the odds that it will push the system out of a metastable stupor are likely negligible.
When used as a login shell, shell is expected to source some init scripts to fix PATH, locale and stuff; if a particular distro is not written with alternative shells in mind this will fail, esentially making you use two shells which is cumbersome enough to be a deal breaker.
Possible next step in this direction is to get rid of both Xen and unikernel by making a specified Java/Erlang VM that only has syscall-calling op-codes for network traffic and virtual disk I/O, while uses hardware virt goodies to secure execution of JITed code. (;
There are two camps, one for which it is all about points, and second for which it is all about odds. When failing, first one fails at validation, while the second at performance. Obviously both mostly use the same tools and tricks, though with different ideologies, and overall produce comparable results.
Shameless plug; I'm a co-author of a method that leverages adding artificial junk features and removing original ones that are likely nonsense to approximate the set of all features that are relevant to the problem (rather than standard make best model, which may be pretty deceiving). https://m2.icm.edu.pl/boruta
There is also unison; it is not automatic (custom inotify script is required to mimic Dropbox, and it will force manual intervention upon conflicts) nor stores history, but handles large blobs, many clients and crappy connections quite well.
Even with proper algorithms, per-file encryption leaks quite a lot of meta-data, sizes and usage patterns; also the cloud provider can transparently delete, corrupt and revert files to previous versions.
For superfluid mechanics (which they seem to be using as a foundation) Donnelly's "Quantized Vortices in Helium II"'s introduction is a pretty good start. The field is quite hermetic, though.
It is more-less globally true; locally it depends on the weather itself -- sometimes you can make up to few weeks and be confident about it from ensemble self-consistency (think desert in dry period), sometimes it blows up few hours into future. Also there is no way of defining single "weather prediction accuracy"; this one you cite is probably some meaningless mixture of various factors (;
I once was on a workshop organised by and for mathematicians which supposed to be about biology. There was a talk where guy was discussing PDE system describing some colony growth; at some point near the beginning he concluded that the results for real input are "boring", and one can get "intriguing chaotic behaviour" with negative cell number, and continued with that assumption (;
It is sad that substantial part of this lib assumes flat Earth; it will work well on a city scale, but one has to expect spectacular fails on a longer distances and near the poles :/
This makes me wonder what is the "default" license that applies to all that minified, not labelled anyhow JS code fetched from random CDNs (this especially applies to ADs)... If JS is software, is it even legal to browse the web without JS blocking?
The problem here is not the for-loop itself but the time used by the R runtime on executing the mapped function multiplied by the number of iterations (this is BTW the main source of advantage for dynamic and GCed but JITed languages like JS or Julia).
*apply functions are loops underneath -- they only look better and save you time possibly wasted on growing some dynamically sized output structure. The way of solving slow loop in R is to find package which implements it in C/Fortran (or write your own in case there is none).
It really is not; my dovecot, opensmtpd and dkimproxy (needed almost exclusively to ensure delivery to Gmail) config is 45 lines total (with comments).