Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hopfield Networks in Go

mlexplore.org

Post reply on HN
Print view View original

11–20 of 20 posts

Re: Hopfield Networks in Go

#11

Post by parenthephobia »

cr0sh wrote: post #7
moreentropy wrote: post #5

Earlier 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…

> 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.

You imply you agree with the parent poster, but if it was "natural" to do error handling this way, surely it wouldn't be the language's most difficult concept?

Re: Hopfield Networks in Go

#12

Post by curuinor »

epberry wrote: post #4

The 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.

Usually if you properly use GPU the real limit is on the order of 20k. I think the graph in his post is old as crap, actually

(if you sparsify connections and do some tricks with sparsification sky's the limit, O(n * small multiplier over 1) with memory)

Hopfield nets don't do memory like LSTMs do. LSTM's already sparsify features and memorize them a long time. There's a medium size literature on adding more shit (NTM, Pointer net, attention) but nearly all of it is not that good (it gets tested on bullshit)

Re: Hopfield Networks in Go

#13

Post by malcolmgreaves »

moreentropy wrote: post #5
est wrote: post #2

Golang: 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.

Which is a great idea: knowing which expressions can fail and which ones cannot. However, the way go encodes this idea isn't very ergonomic or elegant. I'd suggest that you take a look at ways other languages do this. For example, the `Either` type in Haskell or the disjunction type `scalaz.\/` in Scala.

Re: Hopfield Networks in Go

#14

Post by zacmps »

parenthephobia wrote: post #11
cr0sh wrote: post #7

Earlier quoted context omitted.

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…

> 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. You imply you agree with the parent poster, but if it was "natural" to do error handling this way, surely it wouldn't be the language's most difficult concept?

It is natural imo. I think the reason people struggle with it is because of how different it is from most modern programming languages.

Re: Hopfield Networks in Go

#16

Post by kmicklas »

vvanders wrote: post #8
cr0sh wrote: post #7

Earlier quoted context omitted.

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. [1] - https://doc.rust-lang.org/book/error-handling.html

> I hate to be the one who brings Rust into a Go thread

You shouldn't feel bad for this. The Go programmers are legitimately unaware that there's a better world out there.

Re: Hopfield Networks in Go

#17

Post by greenhouse_gas »

kmicklas wrote: post #16
vvanders wrote: post #8

Earlier quoted context omitted.

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. [1] - https://doc.rust-lang.org/book/error-handling.html

> I hate to be the one who brings Rust into a Go thread You shouldn't feel bad for this. The Go programmers are legitimately unaware that there's a better world out there.

Honestly, not at this point of HN. I don't think there was one thread that mentioned (or didn't mention) anything about Go which didn't have comments criticizing it.

Everyone knows its problems, and everyone knows about Rust.

It's just that some people don't need such extreme Real Time that they can't afford GC at the expense of the borrow-checker and lifetimes.

Re: Hopfield Networks in Go

#18

Post by kmicklas »

greenhouse_gas wrote: post #17
kmicklas wrote: post #16

Earlier quoted context omitted.

> I hate to be the one who brings Rust into a Go thread You shouldn't feel bad for this. The Go programmers are legitimately unaware that there's a better world out there.

Honestly, not at this point of HN. I don't think there was one thread that mentioned (or didn't mention) anything about Go which didn't have comments criticizing it. Everyone knows its problems, and everyone knows about Rust. It's just that some people don't need such extreme Real Time that they can't afford GC at the expense of the borrow-checker and lifetimes.

> Everyone knows its problems, and everyone knows about Rust.

I guess they've at least heard of it, yeah, but how many of them have actually tried Rust (or any other language with a modern type system)?

> It's just that some people don't need such extreme Real Time that they can't afford GC at the expense of the borrow-checker and lifetimes.

They should probably be using Java, C#, Scala, ML, F#, Haskell, etc. then.

Re: Hopfield Networks in Go

#19

Post by reality_czech »

kmicklas wrote: post #18
greenhouse_gas wrote: post #17

Earlier quoted context omitted.

Honestly, not at this point of HN. I don't think there was one thread that mentioned (or didn't mention) anything about Go which didn't have comments criticizing it. Everyone knows its problems, and everyone knows about Rust. It's just that some people don't need such extreme Real Time that they can't afford GC at the expense of the borrow-checker and lifetimes.

> Everyone knows its problems, and everyone knows about Rust. I guess they've at least heard of it, yeah, but how many of them have actually tried Rust (or any other language with a modern type system)? > It's just that some people don't need such extreme Real Time that they can't afford GC at the expense of the borrow-checker and lifetimes. They should probably be using Java, C#, Scala, ML, F#, Haskell, etc. then.

I have tried Rust, Go, Java, SML, Lisp, Javascript, and many other languages. I prefer Go in many situations where simplicity, speed of compilation, and portability are important. Rust is an interesting language with a lot of potential but the jury is still out on how wide the adoption will be. There is a steep learning curve, and the borrow checker has limitations.

One thing I don't appreciate is being lectured by pimply-faced nerds about how Go programmers should embrace Java/C++ generics into their heart as their personal saviors. I understand what Java and C++ are, I can choose to use them or not, and it's none of your business.

Re: Hopfield Networks in Go

#20

Post by omginternets »

kmicklas wrote: post #16
vvanders wrote: post #8

Earlier quoted context omitted.

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. [1] - https://doc.rust-lang.org/book/error-handling.html

> I hate to be the one who brings Rust into a Go thread You shouldn't feel bad for this. The Go programmers are legitimately unaware that there's a better world out there.

Gee, it's almost like Rust and Go address different problem spaces ...

Hmmm... perhaps Rust programmers are legitimately unaware that other people's problems differ from their own?

Post reply on HN