If you want to lose money, this is a good way to do it.
You're better off buying what you believe in and holding it. It's easy to fit a perfect model to historical data, but it rarely works going forward, unless you have insider information.
Oh, the issues from that repo are entertaining. This issue alone should be enough to make the case that you shouldn't build a production trading system in JavaScript.
Lmao Oh JavaScript first you steal time by being an unproductive language and now you help lose money because you’re not an industry grade language smh.
Also, this isn't a javascript problem; this is a problem of trying to be too clever and not understanding implicit conversion, which happens in many languages.
`0 === false` is maybe the only thing that I actually hate about javascript. Mutability, I understand and thus can deal with it. Scope, no biggie. But resolving a number to false, when all other numbers resolve to true? Inexplicable.
"Are there any errors? No (0) there are no errors."
Not necessarily. It's just a (mostly POSIX and Linux kernel) convention to use 0 as "no error" result, but there are plenty of code that returns 0 as an error and >0 for success. It has nothing to do with C language itself, as C functions let you return pretty much anything or nothing at all (void functions).
Again, it's not a yes/no flag. The question is rather 'what error happened?' - in which case, it makes eminent sense for 'no error' to be the first exit code, hence 0.
The question it answers is "what was the exit status of the process", where zero typically means success, and non-zero means that there was some kind of error or exceptional exit condition. The most important difference from a boolean is that the exit status is often used to enumerate several kinds of exit conditions, some of which are defined in POSIX (sysexits.h).
In a shell, for example, the 0 exit status is normally actually truthy:
Granted, Lua doesn't consider 0 false either, but at least Lua isn't a dumpster fire.
Let's just leave it at C languages + Python, which account for a large percentage of developer mind-share, so to say that it's unintuitive that 0 is falsey is either disingenuous or slightly ignorant.
The point is that the status code is an enumeration of several different values, neither of which are "true" or "false" and that whenever you want to derive some boolean meaning from it, you are going to have to decide which is true and what isn't because it's not an inherent property of the value.
You say that it answers the question "Are there any errors?", but that's just one possible boolean interpretation of the status code.
That said, I don't know of a shell that doesn't interpret zero status as true, because true(1) and false(1) in Unix returns status zero and non-zero respectively. It's not just Unix, it's Windows, DOS etc. In that sense, the prevalent boolean interpretation is that it answers the question "Did the process end with a success status code?", the exact opposite of what you think.
That you or anyone else finds bash or this boolean interpretation in general unintuitive is besides the point, and ignoring that I've already said half of this to complain about bash is a pretty rude way to short-circuit a discussion.
This is only the case with `==` in JavaScript, not `===`. I think most would consider using `==` a bad practice these days. That said, I agree with your point
This isn't a javascript problem. They were trying to be too clever and test whether a value was set in the same statement where that value was used for a comparison.
The non-truthiness of 0 is something present in many languages.
It's not specific to JavaScript (I've made the same bug in python), but it should be a sign that a language designed to make websites interactive fulfills different requirements than a language designed for building real money trading systems.
Can you expand on why you don't think algo trading with predictive algorithms is a viable strategy?
GDAX has 0% fees on limit orders. Say you set a limit sell at +1% and a stop loss at -1%. You could trigger a buy whenever you predict that it's >80% likely to hit +1% before -1%.
Plug in everything you can get (trades, order book, etc) from GDAX's WebSocket API into an RNN, and I'd guess you can be right more than you're wrong. Aka profitable.
Another interesting idea is that patterns can hold if the market is mostly being affected by bots. Especially at the micro level.
Even basic ML/AI strategies can be easily profitable with the current volatility. It drastically reduces the risk of the HOLD strategy, and while not necessarily the top profits, can be much safer.
I've been running various algorithms for the past 4 months with varying success (whole system homemade in Python), all profitable.
I'd also note that as mentioned elsewhere in the thread, what algorithm is very important. This market is like few others, and thus I have found lends itself to very different strategies.
"When you place an order at the market price that gets filled immediately, you are considered a taker and will pay a fee between 0.10% and 0.25% for BTC books and 0.10% and 0.30% for ETH books.
When you place an order which is not immediately matched by an existing order, that order is placed on the order book. If another customer places an order that matches yours, you are considered the maker and your fee will be 0%.
When you place an order that gets partially matched immediately, you pay a taker fee for that portion. The remainder of the order is placed on the order book and, when matched, is considered a maker order. The fee is 0% for that part of the total order."
No problem. The key is choosing "Limit Order" and checking the "Post Only" box under "Advanced". That will prevent your order from turning into a taker order if you accidentally set the Limit Price too high when buying/too low when selling.
I make profits on something like 95% of my trades when I'm trading manually. I do so because I have a bunch of rules that I stick to... If a market is too 'hot' I don't touch it. If the market turns right when I buy I set my profitable limit and let it sit until the market does eventually flip back around and the trade fills.
This ruleset that I stick to is essentially a basic algorithm. An algorithm that could be improved upon vastly by adding on-the-fly TA and sound, complex math (that my brain is too slow to calculate).
Those who believe an algo can't reliably make profits trading also believe that humans can't reliably make profits trading since every decision we make is a result of some form of algorithm.
Exactly... And one of the big benefits of algo trading is that it takes the emotion out of the decision.
That's the main factor of human losses and mistakes. We always doubt ourselves.
You turn your 95% trading rules into an algo you can be sure it won't take a quick out to cut it's loss when it looks like the market is going wrong... the machine will always trust itself.
I was hoping to see some discussion about market-making bots or arbitrage bots, which I know for a fact can make money. Can these kinds of prediction bots actually beat random chance? I assumed price fluctuations mostly followed a random walk.
That's not really related to it being a bot, though. For any form of trading (whether manually or through some form of automation), of course there's going be some choice of buys & sells that return a profit.
How you choose such a profitable strategy is a huge area of discussion. However, it's a completely different subject to the article, which is just focused on the mechanism of running a bot.
All this post is how to set up a github project. Nothing more. I’d hope to rather see writing on portfolio management, risk management, or other strategies.
That said, Zenbot actually provides a decent platform to start trading.
I've heard of strategies where multiple accounts can collude to manipulate the solo bots that make statistical decisions. Is this a real danger when professional companies start getting involved in crypto?
Hmm, just looking at GDAX's API, you aren't able to tell who's making an order. You don't know if it's one account with ten orders, or ten accounts with one each. So I don't see why multiple accounts would be an advantage.
One thing that springs to mind is that it would allow you to have POSITIONS on both sides of the market, you could use this to create a series of small sell orders that would lure the bots down towards a larger buy order.
You could do this by just placing orders, but I guess in some instances it would be beneficial to be able to hold positions in both directions.
The API let's you take positions on both sides with a single account, or prevent yourself from self-trades by setting a flag.
EDIT: Nvm, the flag just specifies what the behavior is in the event that the system encounters a self-trade: decrement and cancel, cancel resting, cancel incoming, cancel both.
44 comments
[ 3.4 ms ] story [ 81.4 ms ] threadYou're better off buying what you believe in and holding it. It's easy to fit a perfect model to historical data, but it rarely works going forward, unless you have insider information.
> Many people are reporting losses in live trading even if the simulation results and/or paper trading is positive.
Someone's missing the big picture.
https://github.com/DeviaVir/zenbot/issues/1037
Also, this isn't a javascript problem; this is a problem of trying to be too clever and not understanding implicit conversion, which happens in many languages.
And that doesn't happen in many decent languages. That is, languages with strong typing.
EDIT: `!0`
int main (int argc, char* argv[]) {
The concept of using 0 to mean false is not new to javascript is what I was getting at.
Not necessarily. It's just a (mostly POSIX and Linux kernel) convention to use 0 as "no error" result, but there are plenty of code that returns 0 as an error and >0 for success. It has nothing to do with C language itself, as C functions let you return pretty much anything or nothing at all (void functions).
In a shell, for example, the 0 exit status is normally actually truthy:
Let's just leave it at C languages + Python, which account for a large percentage of developer mind-share, so to say that it's unintuitive that 0 is falsey is either disingenuous or slightly ignorant.
You say that it answers the question "Are there any errors?", but that's just one possible boolean interpretation of the status code.
That said, I don't know of a shell that doesn't interpret zero status as true, because true(1) and false(1) in Unix returns status zero and non-zero respectively. It's not just Unix, it's Windows, DOS etc. In that sense, the prevalent boolean interpretation is that it answers the question "Did the process end with a success status code?", the exact opposite of what you think.
That you or anyone else finds bash or this boolean interpretation in general unintuitive is besides the point, and ignoring that I've already said half of this to complain about bash is a pretty rude way to short-circuit a discussion.
The non-truthiness of 0 is something present in many languages.
GDAX has 0% fees on limit orders. Say you set a limit sell at +1% and a stop loss at -1%. You could trigger a buy whenever you predict that it's >80% likely to hit +1% before -1%.
Plug in everything you can get (trades, order book, etc) from GDAX's WebSocket API into an RNN, and I'd guess you can be right more than you're wrong. Aka profitable.
Even basic ML/AI strategies can be easily profitable with the current volatility. It drastically reduces the risk of the HOLD strategy, and while not necessarily the top profits, can be much safer.
I've been running various algorithms for the past 4 months with varying success (whole system homemade in Python), all profitable.
I'd also note that as mentioned elsewhere in the thread, what algorithm is very important. This market is like few others, and thus I have found lends itself to very different strategies.
When you place an order which is not immediately matched by an existing order, that order is placed on the order book. If another customer places an order that matches yours, you are considered the maker and your fee will be 0%.
When you place an order that gets partially matched immediately, you pay a taker fee for that portion. The remainder of the order is placed on the order book and, when matched, is considered a maker order. The fee is 0% for that part of the total order."
https://www.gdax.com/fees/
That's the main factor of human losses and mistakes. We always doubt ourselves.
You turn your 95% trading rules into an algo you can be sure it won't take a quick out to cut it's loss when it looks like the market is going wrong... the machine will always trust itself.
Yeah... No shit
How you choose such a profitable strategy is a huge area of discussion. However, it's a completely different subject to the article, which is just focused on the mechanism of running a bot.
That said, Zenbot actually provides a decent platform to start trading.
You could do this by just placing orders, but I guess in some instances it would be beneficial to be able to hold positions in both directions.
EDIT: Nvm, the flag just specifies what the behavior is in the event that the system encounters a self-trade: decrement and cancel, cancel resting, cancel incoming, cancel both.
> $ npm install
So we know for sure that there's not a malicious leftpad.js getting pulled in there that looks for and exfiltrates your exchange credentials?
Yeah - I'm not going there... Not anywhere near there...