21–30 of 45 posts
An earlier discussion: https://news.ycombinator.com/item?id=14781888
Yup! That version was in Keras. It's now been re-written in PyTorch as well! Thanks to https://github.com/AnshulBasia .
[0] - https://github.com/Spandan-Madan/NLP-Intuition-and-Applicati...
Earlier quoted context omitted.
Yup! That version was in Keras. It's now been re-written in PyTorch as well! Thanks to https://github.com/AnshulBasia .
Any update on the NLP tutorial? I keep checking this repo [0] but seems it hasn't been updated lately. I hope you didn't abandon this project [0] - https://github.com/Spandan-Madan/NLP-Intuition-and-Applicati...
Great explanation and I love the fact that the entire presentation is a Jupyter Notebook! A non-academic observation - the 'real-world' challenge of ML pipelines is what I call the 'last-mile' problem of ML - operationalizing your model. You begin to run into problems of: 1. How often do you 'score' live data? How will this affect latency, data ingestion etc? 2. How often do you have to update your weights, if you wa…
- some values in the command outputs dont match the author's comments (or maybe I misunderstood some?)
- there are some big red blocks of errors in the outputs
- the outputs of the trainings are way too verbose for mobile reading
I guess they are issues on Jupyter's framework side. It would be nice if mobile were treated as first-class viewer.
Earlier quoted context omitted.
Precisely. I strongly believe that the purpose of tutorials is to be inclusive of all people. That's something I realized as a TA, making things explicit never hurts. There's always someone who can gain from more detail :)
I'm going to throw out a plug for that mindset going beyond tutorials. It is a suspect proposition that anything is gained by turning 3 lines of code into one line of code. Unless it is javascript for the Google homepage or somesuch where the bytes matter. Moving code from a bad data model to a good one usually correlates with a big reduction in line count, but the gain is in choosing more appropriate data structures…
In the end, choose code style that matches level of your audience. If you write a one-off python script that automizes some build process in mostly non-python codebase, it should probably be very verbose and easy to understand. If, on the other hand, you're writing code in a decently advanced codebase and most of your colleagues are fluent in the language (or at least, supposed to be), it makes sense to use as much condensed syntax sugar as possible.
Earlier quoted context omitted.
Is your code intentionally verbose (for the sake of being explicit)? It seems like it could be condensed a lot by using Pythonic structures. For example you could replace block 39 with a one-liner: Genre_ID_to_name=dict([(g['id'], g['name']) for g in list_of_genres]) In other places, you would benefit a lot from the enumerate(..) function, which returns (index, item) tuples when called on a list.
A more Pythonic way do to this would be id_to_name = {g['id']: g['name'] for g in list_of_genres} And for i in range(len(list_of_genres)) is really a dangerous antipattern better replaced with for genre in list_of_genres:
Earlier quoted context omitted.
Is your code intentionally verbose (for the sake of being explicit)? It seems like it could be condensed a lot by using Pythonic structures. For example you could replace block 39 with a one-liner: Genre_ID_to_name=dict([(g['id'], g['name']) for g in list_of_genres]) In other places, you would benefit a lot from the enumerate(..) function, which returns (index, item) tuples when called on a list.
Precisely. I strongly believe that the purpose of tutorials is to be inclusive of all people. That's something I realized as a TA, making things explicit never hurts. There's always someone who can gain from more detail :)
Earlier quoted context omitted.
Is your code intentionally verbose (for the sake of being explicit)? It seems like it could be condensed a lot by using Pythonic structures. For example you could replace block 39 with a one-liner: Genre_ID_to_name=dict([(g['id'], g['name']) for g in list_of_genres]) In other places, you would benefit a lot from the enumerate(..) function, which returns (index, item) tuples when called on a list.
A more Pythonic way do to this would be id_to_name = {g['id']: g['name'] for g in list_of_genres} And for i in range(len(list_of_genres)) is really a dangerous antipattern better replaced with for genre in list_of_genres:
Earlier quoted context omitted.
Is your code intentionally verbose (for the sake of being explicit)? It seems like it could be condensed a lot by using Pythonic structures. For example you could replace block 39 with a one-liner: Genre_ID_to_name=dict([(g['id'], g['name']) for g in list_of_genres]) In other places, you would benefit a lot from the enumerate(..) function, which returns (index, item) tuples when called on a list.
Precisely. I strongly believe that the purpose of tutorials is to be inclusive of all people. That's something I realized as a TA, making things explicit never hurts. There's always someone who can gain from more detail :)
Great explanation and I love the fact that the entire presentation is a Jupyter Notebook! A non-academic observation - the 'real-world' challenge of ML pipelines is what I call the 'last-mile' problem of ML - operationalizing your model. You begin to run into problems of: 1. How often do you 'score' live data? How will this affect latency, data ingestion etc? 2. How often do you have to update your weights, if you wa…