HN user
Location: Russia
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
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.
It is possible to do string interpolation in Rust with a macro:
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.
There is CommonMark specification: https://commonmark.org.
I like this quote:
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.
There is also the classical Buffon's needle experiment: https://en.wikipedia.org/wiki/Buffon%27s_needle#Estimating_%...
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.
Look at this part of the video from https://zeppelin.apache.org: https://www.youtube.com/watch?v=_PQbVH_aO5E&t=3m21s. It shows plotting directly from SQL.
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.
[1] https://zeppelin.apache.org/
[2] https://zeppelin.apache.org/docs/latest/interpreter/postgres...
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.
[1] http://lesswrong.com/lw/o5/the_second_law_of_thermodynamics_...
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.
But what about Tesla? It managed somehow to compete with Toyota, Honda, etc, although it had to create a new market (market of electric cars) to do it.
And also there is a more introductory book by YA. B. Zeldovich and I. M. Yaglom "Higher Mathematics for Beginners" [1] that is a fun to read book about calculus.
[1] https://archive.org/details/ZeldovichYaglomHigherMathematics - for some reason the book at archive.org has extension .pdf , but in fact it is a djvu document, so it has to be opened with DjView instead of a PDF viewer.
Thank you. So basically the parent comment was talking about experiments for validating quantum non-locality at galactic scales.
And the experiment mentioned in your link confirms this non-locality up to the distances of 600 light years, but we want to confirm it for even larger distances and times, that's why there is a need for techniques like the subject of this discussion.
Could you please provide an example of such experiment involving quantum phenomena?
Also doesn't the proposition that the act of designing/conducting some experiment and the noise generated by some events that took place in past (but can't be classically observed at the moment of conducting the experiment because the light generated by those events didn't reach the location of the experiment before the moment of finishing the experiment) cannot be correlated contradicts the non-locality of quantum mechanics?
There is also a nice small book by Paul Dirac https://books.google.ru/books?id=Jtu-n8AzJhMC
Unlike other texts, it derives everything through embedding of the space-time manifold to a high-dimensional Euclidian space. It means that although it lacks some generality, the curvature and covariant differentiation become somewhat more intuitive and the calculations might feel easier to follow for those who are studying the subject for the first time and are not familiar with differential geometry.
The article doesn't mention type annotations described in PEP484 and added to CPython since Python 3.5.
It is possible to add annotations to your code like
class Foo:
x: int
# ...
Under the hood this `push!` function have to do memory reallocation and copying the entire array when the array grows to be larger than some internal buffer, which happens each time the array becomes larger than a^n, where a is usually, but not necessary, selected to be equal to 2.
The amortized complexity is θ(1), but individual insertions might take O(n) time.
It means that it is not hard to have the same in numpy, with the same performance, the only difference is that the growing have to be done manually and that the push_back function has to be called as something like
x, x_len = push_back(x, x_len, 10)
def push_back(x, x_len, value):
if len(x) == x_len:
x = np.concatenate((x, np.empty(max(len(x), 1)))
x[x_len] = value
return x, x_len + 1
But AFAIK LED brightness is usually controlled by pulse-width modulation, which is essentially adding flicker.
There are people with flicker sensitivity that have headaches when exposed to flickering light. A link to a HN discussion that touched the problem of PWM and flicker in the comments: https://news.ycombinator.com/item?id=13330611
if you're considering different versions of an algorithm, test it in a tight loop using the time.clock() function.
...but if you are anyway experimenting with your code in a Jupyter notebook, then you could just use %timeit [1] or %time [2] magics to measure execution times and benchmarks without writing any additional code.
[1] https://ipython.org/ipython-doc/3/interactive/magics.html#ma...
[2] https://ipython.org/ipython-doc/3/interactive/magics.html#ma...
I don't want to diminish what they and other similar projects do and actually I'm not really familiar with FPGA development, but I have one thought: what if we don't need one more language, but rather something on a different level of abstraction?
The first neural networks that ran on GPU was written using low-level GPU primitives [1]. This was a non-trivial process that required to do a lot of low-level stuff. It required system programming skills and time to implement new architectures. But a group of researchers at the University of Montreal developed Theano [2], a framework that allows you to define computational graphs in Python programming language and then compile them to CUDA code that could be then executed on GPU. Instead of spending resources on development of a new language they put their efforts on actual thinking out useful abstractions and implementing compiler that works efficiently. It is also notable that they didn't include very high level abstraction in Theano too, but there are libraries like Lasagne [3] and Keras [4] that introduced higher level abstractions (neural network layers and pluggable pre-implemented models) on top of Theano. It is safe to say that Theano boosted Deep Learning research, making programming of new neural networks architectures quicker and accessible.
What if actually we need just the same thing for FPGA? Just a Python library that defines useful abstractions for logic circuits building, allows to construct arbitrary graphs using them, and then compile these graphs to VHDL. Assuming that the basic building blocks defined in Python are well defined and tested, it would be easy to implement verification and some testing in pure Python, the tooling like visualising logic diagrams can be implemented in pure Python too.
In addition to reduced efforts for development (because you don't need to design and implement a new language), it would be easier to pick up by software programmers: they would not need to learn new syntax, but concentrate on core conceptions like gates/summators/other stuff and graphs involiving them. It wouldn't be necessary to develop special-purpose editors, because it just Python, and again, because the tests for the resulting schemas could be written and ran in pure Python, it would be possible to use standard CI tools like Travis for open source development.
Edit: It seems like there is already a project MyHDL [5] that does something very close to what I described above.
[1] https://hal.inria.fr/inria-00112631/en/
[2] https://github.com/Theano/Theano
[3] https://github.com/Lasagne/Lasagne