Short answer, as I'm on mobile: this is structured pruning, which is hardly comparable to unstructured methods like IMP (algorithm for lottery tickets)
In unstructured pruning, individual weights of a weight tensor are pruned with no constraints on their position in the tensor. In structured pruning, there are constraints on which weights are pruned. Think of pruning an entire output channels of a convolutional layer vs pruning arbitrary weights of the same tensor. Unstructured pruning allows for a greater percentage of the weights to be pruned, but unstructured pruning doesn't speed up a network on hardware accelerators, which favor dense matrix multiplications.
- First off all, I like the idea! Thanks for making this! HN will often hold a hobby-project to the standards of a professional product, and will hence criticize a lot, but don't get discouraged, I enjoyed it.
- From time to time I got a repeated question, or the question was a bit lame/uninteresting. Maybe add a feature so you're able to "reroll" the question once per conversation (perhaps with agreement of the other). Personally I would like it if you could e.g. choose a category before getting matched.
- I got insta-disconnected quite often. This doesn't really bother me that much as I can try again immediately, but it could put people off when they try out the app and get skipped the first couple of times. People will judge the app on the first conversations. Do you punish frequent disconnecters? (Maybe put a limit, like max 2 disconnects per minute)
- The "no small-talk" is not very effective, some will entirely ignore the question. But I don't really think you can avoid this.
- I never got matched to a troll / something inappropriate. On the contrary: some conversations where quite wholesome (like a very friendly camel farmer with his little daughter). I hope it can stay this way.
- A majority of people I got matched to where from Saudi Arabia. This is not an issue on its own, but I found that many of these had poor English skills or a bad connection, which made conversations difficult.
- Some conversations where interesting, but some were also very lame. It's not so much the question that's important but also the personality of the person you get matched with. There are quite some people that go "idk lol how about you" after getting asked the conversation question.
However the quality of the conversations are really the maker or breaker of the experience. It can be worth wading trough the bad ones for the good ones. Good ones occur less frequent tough, but tend to be longer. Indeed, 2 minutes is very short to have a proper discussion, so you extend it if it goes well. You could try to enhance this by e.g. making each renewal of the timer a minute longer.
This is DEM L316. It might seem like one object, but these are the remnants of two different supernovas (of different types: smaller is Type Ia, bigger Type II).
Because it is not really possible to "compile" an eval expression in the general case.
By definition, in a compiler, translation from symbols to code happens on the beforehand. But eval needs to do this at runtime. This means that to compile a program a la "eval(input_string)" the output program whould need to contain the entire compiler, which gets used to convert the eval_input before running.
So in practice you strapped a kind of interpreter to the output program. This is often inefficient and hackish, and thus it is more desirable to just not have a eval feature.
But if you're going to start cutting out the dynamic features, and those you don't think aren't desirable, then why are you challenging yourself to write a compiler language for a dynamic language in the first place? You could cut out all these troublesome features if you just picked a static language.
I don't think using eval is the main problem he's trying to solve. Eval isn't really a good example of "dynamic programming done right". You don't even need eval to metaprogram in JS.
