Hopfield Networks in Go
mlexplore.org
Hopfield Networks in Go
1–10 of 20 posts
Re: Hopfield Networks in Go
#2Golang: a language where you divide statements with `if err != nil`
Re: Hopfield Networks in Go
#3Golang: a language where you divide statements with `if err != nil`
Much more readable than using `;` as a separator, imo.
Re: Hopfield Networks in Go
#4The number of neurons Hopfield networks can use seems like a serious limitation. I think the max number in his graphs was 300? Does anyone know if this is a real problem or not?
On another note, what is the state of the art in "'memory networks". I'm thinking beyond LSTMs to a network that might be able to remember high dimensional features across a large span of time.
Re: Hopfield Networks in Go
#5Golang: a language where you divide statements with `if err != nil`
A language where it's natural to think about and properly handle every error condition.
Re: Hopfield Networks in Go
#6I encountered Hopfield networks in LLVM [0]. I still do not understand how you would model Spill Code Placement as a Hopfield network.
[0] https://github.com/alexjordan/LLVM-TMS320C64X/blob/master/li...
Re: Hopfield Networks in Go
#7Golang: a language where you divide statements with `if err != nil`
A language where it's natural to think about and properly handle every error condition.
Someone who gets it.
In Go, this is one of the most difficult concepts of the language to wrap one's head around. Moreso, it's a concept that makes you bang your head against the wall at first; at least it did for me. After being so used to "getting away with" not thinking about this in other languages, being forced to think this way in Go can be maddening.
Then a light goes on.
...and then you look at your old code and go "eeesh"; in my case, I was coming from a PHP background at the time I was learning Go.
Don't get me wrong - I still like PHP and other languages, and I don't use Go much as it is, but once I wrapped my head around many of it's "strangeness" (compared to other languages), I really appreciated it (because I recognised that the whole point of the language was to help prevent common errors and in many cases force better programming practices to that end), and began to enjoy it.
Re: Hopfield Networks in Go
#8Earlier quoted context omitted.
A language where it's natural to think about and properly handle every error condition.
Someone who gets it. In Go, this is one of the most difficult concepts of the language to wrap one's head around. Moreso, it's a concept that makes you bang your head against the wall at first; at least it did for me. After being so used to "getting away with" not thinking about this in other languages, being forced to think this way in Go can be maddening. Then a light goes on. ...and then you look at your old code…
I hate to be the one who brings Rust into a Go thread but if you find forced error handling to be a revelation then you'll find the borrow checker does the same thing for your program structure and architecture.
There's also a ton of really nice error handlers[1] that let you ergonomically deal with errors while still being forced to confront them.
Re: Hopfield Networks in Go
#9Golang: a language where you divide statements with `if err != nil`
Feels like Javascript callbacks with the error first arguments.
Not something I miss, since promises became more available.
Re: Hopfield Networks in Go
#10Golang: a language where you divide statements with `if err != nil`
A language where it's natural to think about and properly handle every error condition.
Personally the syntax seems like a regression to me, as a JavaScript programmer who moved on to promises from the old callback function(err, Val){ if err pattern. Higher order control flow abstractions are really nice, but hard to do in go because of the weak type system. If it was fully dynamic we couldn't worry about it, and if it allowed a bit more power like generics we could have elegant stuff like Haskell's either monad.