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.
You can do a lot of what it does with plain old aliases and really should if you work with multiple forges.
You're also only talking about a single git use case which not everyone follows, even within a single forge.
Something tackling the problem from the other end is phabricator which integrates each VCS into the same forge platform. Well, mostly (badly), it's kind of a total mess with specific things you need to work around for each.
I can see the same thing happening to anything trying it from the forge end.
Just because gitlab has pull requests does not mean that GitHub born idea is the best or will even stay.
How would you marry up Gerrit to GitHub (you can't).
What you're asking for only really works for something following gitflow, which would be kind of stupid to base a standard on because it's broken by design and doesn't scale. But you would have to because otherwise GitHub won't use it.
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.
Yeah, CommonMark is awesome, and if the argument was about CommonMark and not Markdown in general, I'd be on the other side of the argument. However, most Markdown renderers don't implement CommonMark.
> 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.
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