3 ms·

Great suggestions for general-purpose code, but I would NOT recommend following them in 'mathematically dense' code (e.g., deep learning models), for which bein

by cs702 6y ago

Great suggestions for general-purpose code, but I would NOT recommend following them in 'mathematically dense' code (e.g., deep learning models), for which being able to fit as much logic as possible into a single editing screen becomes increasingly important as we increase the complexity of the code. Taken to the extreme, the "fit as much logic as possible into a single screen" approach leads naturally to code that looks a lot like something written in APL or one its descendants (J, K, etc.). I recognize this is not for everyone. Personally, I think Jeremy Howard and the folks at fast.ai have struck a pretty good balance of readability and succinctness with their coding style for ML/AI code: https://docs.fast.ai/dev/style.html https://docs.fast.ai/dev/style.html

0x402DF854 6y ago
I don't quite enjoy "explicit mathematically dense" code, it leads to bad habits, see item 4: Python's syntax makes it all too easy to write single-line expressions that are overly complicated and difficult to read. If you really need to pack a lot of math, just define it in a module (e.g. tensorflow does that nicely). I've had an intern who came from MATLAB. Convincing them to stop packing numerical constants in the middle of every expression was unexpectedly difficult. "But it's shorter that way!"
sweezyjeezy 6y ago
I work in deep learning, and I'm very dubious of the benefit of terse code. In my experience 90% of novel deep learning models can be coded with base layer classes from tf/pytorch/keras + maybe a few hundred lines of 'new' code. For this code I feel like you will avoid mistakes and make things so much easier for the reader (probably yourself in 6 months), if you modularise, write it as clearly as possible and explain what each part is doing. I have used code from the fast.ai codebase and personally I find it horrendous to work with - I find the way they structure and name classes consfusing, they use wildcard imports everywhere, they use tiny variable names for everything - it's all extremely reader-unfriendly, which for an educational tool seems completely bizarre.

by cs702 6y ago

0x402DF854 6y ago

I don't quite enjoy "explicit mathematically dense" code, it leads to bad habits, see item 4: Python's syntax makes it all too easy to write single-line expressions that are overly complicated and difficult to read. If you really need to pack a lot of math, just define it in a module (e.g. tensorflow does that nicely). I've had an intern who came from MATLAB. Convincing them to stop packing numerical constants in the middle of every expression was unexpectedly difficult. "But it's shorter that way!"

sweezyjeezy 6y ago

I work in deep learning, and I'm very dubious of the benefit of terse code. In my experience 90% of novel deep learning models can be coded with base layer classes from tf/pytorch/keras + maybe a few hundred lines of 'new' code. For this code I feel like you will avoid mistakes and make things so much easier for the reader (probably yourself in 6 months), if you modularise, write it as clearly as possible and explain what each part is doing. I have used code from the fast.ai codebase and personally I find it horrendous to work with - I find the way they structure and name classes consfusing, they use wildcard imports everywhere, they use tiny variable names for everything - it's all extremely reader-unfriendly, which for an educational tool seems completely bizarre.