Lots of debate here about the best model. The best model is the one which creates the most value for you —- this typically is a function of your skill in using the model for tasks that matter to you. Always was. Always will be.
Quantitative trading, hedge fund, New York, NY, ONSITE
I run a systematic quant trading group that trades globally. We are research driven and are working on solving tough problems at the intersection of math, statistics, and computer science. We believe that the combination of a rigorous scientific approach with solid engineering can expose inefficiencies in the markets.
We are looking for engineers/data scientists who have experience building mission critical distributed systems or large scale data pipelines.
Please get in touch (hiring.quant.trading AT gmail) if any of these things are applicable to you:
* You understand or have worked with applied math or computer science at an advanced level
* You have serious engineering chops and have built large scale high performance systems
* You are fluent in one or more of (c, java, golang, rust) and (python, q)
* You enjoy working in small groups in a fast paced environment
* You have experience building order management and execution systems for trading
* You enjoy working with data
We value the following personality traits:
* Intellectual curiosity
* Good work ethic
* Self-motivation
This is an exceptional opportunity for the right person. There is tremendous potential for both growth and comp, but it is not going to be a smooth ride. Our goal is to build something exceptional and the right person is used to not making choices that are “easy” or “default”.
Well said. If you have or build an "edge" over time the distribution of your outcomes will have a positive mean. Along the way you may see values on the tails which are random spikes.
Quantitative trading, hedge fund, New York, NY, ONSITE
I am starting a new quantitative trading group that will systematically trade global Futures, FX, and Equities. We are research driven and are working on solving some really tough problems at the intersection of math, statistics, and computer science. We believe that the combination of a rigorous scientific approach with solid engineering can expose inefficiencies in the markets.
We are looking for people who are self-motivated, entrepreneurial, love working with data, and more importantly have the ability to go both broad and deep into problems.
Please get in touch (hiring.quant.trading AT gmail) if any of these things are applicable to you:
* You understand or have worked with applied math, statistics, or computer science at an advanced level
* You know mathematical optimization and can write your own convex solver if needed
* You have experience applying machine learning/statistics to noisy data
* You have serious engineering chops and have built large scale high performance systems
* You are fluent in one or more languages (python, c, java, q, R)
* You enjoy working in small groups in a fast paced environment
In additional to really interesting work, we offer tremendous potential for growth and compensation.
I know the Kx people pretty well, and they are trying to get the word out (have been for years), but it never ceases to amaze how little respect they get in the free software world. They are the leading timeseries database, and yet they don't even get a footnote in the article :(
I have actually heard of Kx and Kdb+ and Q and have looked into those products. You're right that I should have mentioned them, because they are important in that space, and in many ways they are miles ahead. The state of time series query languages is quite poor (outside of Influx's effort), so there is a lot to learn from Kdb+ as well.
I was however focusing on recent Open Source efforts and on the general approaches. Hence, I didn't really discuss in detail my own tsdb.
I also find virtually everything to do with K and Kdb to be be simultaneously impressive and utterly unfathomable:
Possibly because they cost an arm and a leg (or at least that's the perception) and are therefore out of reach of most firms, apart from large utilities and hedge funds, and the language looks like line noise.
Yes, I know there is a free version, but limited to 32-bit only (and probably non-commercial?).
Agree about the cost. However, I would think that a wider adoption would eventually bring the cost down and perhaps even spawn a bunch of related open-source projects.
As far as readability is concerned, q(KDB+) is far more readable than k(KDB). Also, nobody stops you from adopting a coding style that is more readable. That is what I personally do.
NSQ is a full-featured messaging platform out-of-the-box, whereas zeromq and nanomsq are lower level libraries that you could use to build (the same) functionality.
We used them recently in nyc and user experience was great. However once you do the math, a 10 - 15% markup on most products in addition to delivery fees, tips, (or prime) is simply too much if you use them on a regular basis. The annualized cost for a small family is easily north of $2000.
Now I know that "price is what you pay and value is what you get". So there are definitely occasions when I will use them.
But I honestly doubt that most of their users realize the true cost of their service.
There is no messaging system; visit the user's profile (click on their name) and cross your fingers they have some kind of identifying information- an email address, a web page, etc.
but I see no e-mail. When I do the
same click on my Hacker News user name,
then, yes, I see a line for my e-mail
but the line (a text box) is empty
because I haven't given my e-mail to
HN.
I have a travel startup that is meant to solve the planning problem in a different way, but I agree with Gary. We painfully learned that -
a) We created an elegant solution to free. That is always a bad idea
b) User acquisition is extremely hard without spending tons of money
c) Even though the users love the product, the fact that they would only use it couple of times a year means that you need to have lots of users, which circles back to the previous point
It sucks because the travel space really needs quality apps and I would like to believe that there is a way around all the issues for startups. But the fact remains that it is a bad idea for most people.
