Looks like an idea for a semi-supervised ensemble method for machine learning:
Prepare two equally sized ensembles of classifiers, let's call them A and B.
1. Train each classifier in ensemble A on labelled data to predict does a picture contains a cat.
2. Take some other unlabelled dataset and collect answers from classifiers from A for each picture from this dataset.
3. Train each classifier in ensemble B to predict average answer of classifiers from A for each picture from the unlabelled dataset.
Then for a picture from the test dataset it would be possible to get answers from ensemble A and from ensemble B and calculate what would be the surprisingly popular answer.
While it is pretty cool, using such tool increases general lock-in to GitHub, in terms of both habits and potential use of it for automation of processes.
I wish there was an open standard for operations that hub allows to do and all major Git forges [1], including open source ones, such as Gogs/Gitea and GitLab, supported it. In that case having a command-line tool that, like Git itself, is not tied to a particular vendor, but allows to do what hub does, could have been indispensable.
No one mentioned Riker https://github.com/riker-rs/riker, another actor framework for Rust. It would be interesting to hear comparison of both from those who used it.
> You say Markdown has a common set of features, but what is that common set? There's no standard, and I find myself surprisingly frequently struggle with figuring out what's the correct way in a particular markdown engine to do what I need to do.
> Frankly, I do not believe that the above success rate can be explained by my lateral ideas being particularly good. More likely, this tells us that poking in new directions, even randomly, is more rewarding than is generally perceived. We are probably digging too deep within established areas, leaving plenty of unexplored stuff under the surface, just one poke away. When one dares to try, rewards are not guaranteed, but at least it is an adventure.
I thought it was about doing scatter plot on graph paper and trying to draw a line with a ruler so that it “almost all points fit”, then empirically measuring the slope and the intercept. I had an impression that it was the way to go in cases when the requirements for accuracy were not strict and calculators was not around.
Suggestion: add an ability to write a hash of prediction to the Bitcoin blockchain (for a fee from the user) and the ability to see this hash alongside the prediction on day X with the link to the corresponding blockchain record. This way it won't be necessary to trust your website about the fact whether the prediction was actually made on the date you claim.
There is https://www.kaiko.com/, they collect and sell bid/ask and orderbook data for most of the exchanges that are active now or were active in past.
In some sense, the current trend of chasing quick predictions at cost of giving up on understanding of the inner working of things resembles the described in the article approach that was taken by Babylonians.
A lot of resources is being put into machine learning, as it provides relatively quick solutions that delivers results that are superior in comparison to other approaches for many of problems. And I find it to be fascinating. However, I'm concerned a little about a possible paradigm shift that can happen if we continue to grow this "prediction-first" attitude and let it become a part of our scientific philosophy.
Such a shift might make people who actually try to figure out the underlying mechanics of the problems they work on to be perceived as "inefficient", as they are going to be (and often already are) inherently less competitive to machine learning algorithms in terms of ability to quickly provide predictions that are good enough to be practically used. If it happen, it probably would make the areas of science that involve building and invalidation of theories less attractive to youth in comparison to those that are centered around building better predictive models and application of them to complex phenomena with a focus on making practically useful predictions.
I see the culture in this type of future as something similar to Babylonian culture as it was presented in the article and compared to the Ancient Greek culture. No to say that this future looks completely bad, but I think it is not as exciting as the one where true understanding of the things is valued first if not the most.
A relevant book is Think Bayes [1] by Allen B. Downey. It also uses only pure Python to solve simple problems of Bayesian inference. I like the simplicity of the way it communicates the ideas of Bayesian approach.
But the subject is not a duplicate of that one, as it seems to put more focus on sampling.
A nice analysis, and it shows how SQL makes it easy to quickly explore data.
However, it seems like the plots of the results of the queries were done manually by writing some code to make each plot.
I can't stop but mention that using Apache Zeppelin Notebook [1] with Postgres interpreter for Zeppelin [2] (Spark SQL should provide comparable analytical capabilities as well, but this comment is not about it) it is possible to show graphical representation of query results without writing a single line of code.
I doubt that the subjective experience of the world is as immaterial as some want to believe.
Our subjective experience of the outside world can be quantified in terms of our ability to make predictions about the world and use them. All of us make and use predictions about the perceived reality as part of our conscious experience. However, if you have accurate enough representation of the outside world in your mind, it puts physical limits on the minimum amount of entropy your brain can have. And entropy is a completely physical quantity.
There is an article [1] I found to be interesting that explains why entropy, as defined in Physics, of the same physical system can be different in eyes of different observers with different prior knowledge/reasoning abilities/etc. In a nutshell, it makes perfect physical sense because if one would take into account that all these observers can't exist without physical medium and that their mediums should also be considered to be parts of the physical system of interest.
But then it becomes clear that accuracy of the subjective representation or experiences of the outside world has a direct effect on the entropy of the underlying physical medium because this is what the second law of thermodynamics, applied to the whole system of an observer and the system it interacts with, says.
I personally find recurrent highway networks (RHNs) as described in [1] to be easier to understand and remember the formulas for than the original LSTM. Because as they are generalizations of LSTM, if one understands RHNs, one can understand LSTMs as just a particular case of RHN.
Instead of handwaving about "forgetting", it is IMO better to understand the problem of vanishing gradients and how can forget gates actually help with them.
And Jürgen Schmidhuber, the inventor of LSTM, is a co-author of the RHN paper.
I (actually not only me but also a few other guys) wrote an open source GUI dictionary for Linux [1] (it uses Qt selection features that don't work the same way on other platforms, so although it compiles on, say, Mac, it doesn't fully work). It was started with Qt4 10 years ago, then it was ported to Qt5. So I think I can share my perception of Qt.
The framework is very solid, the components are easy to combine and in general, once you get used to it, it becomes quite easy to work with them. The resulting app is very performant and has low memory consumption in comparison to JS-based apps. Also, adding asynchronicity is actually not hard, at least for things like HTTP requests, as you can use Qt signal/slot system to receive events asynchronously so that in simple cases it is not necessary to mess up with threads.
However, the developer productivity is, in my perception, is a somewhat less than with modern JS frameworks. Not 10x less, but a bit less. I think one of the issues is C++ itself: after changes in the code, it is necessary to not only rebuild but rerun the app, and in general writing C++ code is something that requires some attention as otherwise, it is possible to have SEGFAULT somewhere in your app and then spend time looking for the place in your new code that causes this SEGFAULT.
Note that I'm talking here only about classical QtWidget/C++ apps, not QtQuick ones. I think productivity with the second ones should be better. However, one might argue that if you started to write your code in Javascript, it's better to do it in a way that allows you to have the same code running natively in browser (QtQuick experimentally runs in it, but it is experimental and not mainstream), so that you can share components and code for example between your site and your desktop app.
I wonder would it be possible to use it somehow with Linux (in kernel space, not with fuse, because fuse has work slower because of necessary context switches from kernel to user space). I mean it is interesting can a wrapper kernel module be written for interfacing with Rust code, or there are some obstacles that would prevent from doing it efficiently.
Also there are differences in further employment perspectives.
I mean if you have a problem to solve and you have a choice to use some old tech that you already know, but it is going out fashion, and some new one, then the choice of the newer one improves your employability in the future. For example, I guess in 2000 there was not that much people with 5 years of experience of using Java in production, but those who had it, had to have pretty good chances to easily find decent job.
Of course there is a risk to bet on wrong technology, but at least you keep learning instead of just using ageing tools and becoming more and more disconnected from the current state of the art. It can be as scary as this https://news.ycombinator.com/item?id=11886753, a story of a guy who successfully solved business problems and delivered products with jQuery for a long time and then eventually found that he was out of demand because businesses started looking for people with experience of using React and he didn't have it.
Remote: Yes
Willing to relocate: No
Technologies: C++, Java, Python, JavaScript/TypeScript.
Résumé/CV: https://docs.google.com/document/d/1zg9bD8jXTI1OHVvQYvEwhsIc...
Email: Available in the resume