I think you can do "real" ownership in ATS; or check ownership with a static analysis tool in many languages, including C; and you should be able make a hacky version as a library that dies at runtime in any language with parametric polymorphism and modules. "Modern C++" too, ish.
Which Lisps are you thinking of? CL and Scheme both allow having multiple copies of mutable objects.
The argument is that it is not fundamentally better to use the longer name in the given context, so why make it longer? I'd say it isn't about how long the variable takes to type either, but how long the code takes to read and parse.
I agree with the previous poster; there is simply no place that provides you with bleeding-edge real-world projects that are doable within a month. I have a top 10 CS university M.S. degree so I can compare; Udacity also prepares many courses with top 10 university staff (Stanford, MIT, Gatech etc.)
So I have only taken Master's courses at two schools, but I have taken many courses at these schools, and a few online.
The professors were from famous institutes and from unfamous ones. It was a top 20 (but not top 10) school. So assuming that it was a wide sample, I think I have some sense of how good the courses are.
You are right in that they might have even clearer teaching at the top 4 (Stanford, MIT, CMU and Berkeley), though some of the teachers I worked with had taught at some of those schools and/or got PhDs there.
The article, from how I read it, is not suggesting single-implementation interfaces are the problem but instead where those interfaces are stored. The package accepting the interface should define the interface it needs (and perhaps that package defines the mock implementation), and the implementation should exist somewhere else.
I've programmed in both ways and they each have there place. But in general this is the right way, you shouldn't export interfaces, you should export concrete types and then use the documentation and tests to example what types of interfaces the types can cover.
Better isn't always straightforward, sometimes unintuitive steps need to be taken to reach a better fitness value. The advantage of evolutionary methods over backprop is that evolutionary methods can take steps "backwards" and avoid local minima.
It definitely is a problem. For instance there was a recent post about trying to teach a robot to put a board with a hole in it into a peg. It would just learn to shove the board next to the peg.
It's a shown/kind of proven result that deep neural networks don't fall into local minima in the very high dimensional parameter space.
GANs and reinforcement learning are different. Research on getting those to converge to good local minima is still much more in its infancy. I don't particularly consider those just a "neural network", but sorry, I should have been more clear.
This thread is about reinforcement learning which definitely suffers from local minimas.
But even vanilla supervised nets suffer from local minima. Anyone who's played with them has encountered it. Here you can mess around with a neural net live in the browser and it very easily gets stuck if you try more than 3 layers (especially try the spiral dataset): http://playground.tensorflow.org/
That's why I said high dimensional neural networks. There's been a lot of literature explaining why local minima aren't a problem in very high dimension loss surfaces.
Local minima are something that people thought was gonna be a problem, especially back in the 2000s. They played around with small neural nets on toy examples such as yours, and thought it was intractable. It's the entire reason why neural nets fell out of the fashion in the early 2000s, and people moved towards techniques like SVM.
These toy examples don't generalize to high dimensions, and if you take a look at the literature, you'll see that the consensus agrees with my statement.
Ehh these theoretical results have questionable application to real life. Sure it might be very easy to learn simple correlations like "this patch of pixels correlates highly with the output '8'". But it's trivial to construct examples where neural nets get stuck in local minimas. For instance, try training a net to multiply two binary numbers.
Maybe with a billion neurons, just by random chance some of them would correspond to the correct algorithm and get reinforced by backprop. But very few NNs have layers larger than a thousand neurons. Because the cost of layers that big grows quadratically. And the chance of random weights finding the solution decreases exponentially.
One of the biggest reasons things like stochastic gradient descent, and dropout are used is because they break local minimas.
The statement "deep neural networks are not affected by poor local minima" is not really a personal opinion/theory at this point; it's the dominating consensus in the research community.
These are not just theoretical results. They're theory papers trying to explain the empirical result of why neural nets don't get stuck at local minima.
> Given that deep networks are highly nonlinear systems optimized by local gradient methods, why do they not seem to be affected by bad local minima?
And other such results.
As I said above, neural nets are obviously able to get stuck in local minima in toy examples. If you read my above comment, you'll see that that has no bearing on my initial statement.
Dropout's main motivation is not to break local minima. It's to achieve better generalization. If it were the case that it was meant to break bad minima, we'd have better training loss upon adding dropout, which is obviously not true.
As for SGD, we used to think that it was mainly for computational purposes. That is, we're unable to batch our entire training set at once, so we have to split into mini batches.
Modern theory states more that SGD is good for avoiding sharp minima, as well as some other desirable properties.
I'm not sure you're really reading my comments thoroughly nor checking out the links, so if you're actually interested in understanding what's really going on, please do some proper research on the topic.
"The most important thing to know about Go's assembler is that it is not a direct representation of the underlying machine. Some of the details map precisely to the machine, but some do not... The details vary with architecture, and we apologize for the imprecision; the situation is not well-defined."
Seems the point of it is to enable easier porting of assembly between architectures, by providing a consistent syntax.
I was expecting something akin to LLVM assembly language, but no, they're come up with their own bizarre high-level assembly-language intended to map fairly directly to various different instruction-sets. It's not an abstraction layer in the usual sense; the exposed register-set and instruction-set are faithful to the target architecture.
It's a finite register machine which isn't just faithfully exposing the underlying architecture. Not something we often see. iirc SPIR and GNU Lightning are both finite register machines, but, to quote Douglas Adams, this has made a lot of people very angry and been widely regarded as a bad move.
How is it compiled? Presumably it doesn't get translated to LLVM as an intermediary.
It strikes me as an awful lot of work. Does their high-level assembler really outperform LLVM? Would've thought a project of that sort would deserve to exist in its own right, not just as an obscure component of Go.
It's a finite register machine which isn't just faithfully exposing the underlying architecture. Not something we often see. iirc SPIR and GNU Lightning are both finite register machines, but, to quote Douglas Adams, this has made a lot of people very angry and been widely regarded as a bad move.
TAOS operating system used such a virtual ISA, and was able to achieve around 90% efficiency of native code. The worst case was PowerPC which fell to 80%. That's pretty darn good, IMO.
Less government regulation makes sense in places that don't endanger people (e.g. food quality) and in fields with a lot of competition. A large number of people in the united states only have access to one ISP, or one fast ISP[1].
Your single ISP available to you could decide that you don't get to access your favorite site(s) without charging an additional fee to access them. They could refuse to offer any unknown sites, and just offer facebook, youtube, etc, each costing some number of dollars to use.
