ReTraining Live Z12 - Problems & Questions

Hi. Today I reTrained a running Z12 and have these questions/problems:

One of the downsides of Zorro is that it stores only 1 set of data in the Registry. My VPS is running more than 1 strategy on different FXCM accounts from different FXCM entities. Z12 was not the last strategy started, so the wrong data was in the registry. Therefore, the Z12 reTrain accessed the wrong FXCM account.

1) How bad a problem is this? Do I need to ensure the correct Registry data and reTrain?

2) Is there any easy way to prevent this problem in the future?

3) While I happened to be looking at the running reTrain it downloaded 2016 prices but immediately after posted a message that it could not download 2015 prices - why? I believe this was for USD/JPY, but can't be sure - see the next question. Also don't know if there were other reTrain problems. Is the new .par file that is now being used invalid?!

4) Z12 reTrain takes a long time. I had other things to do. When I returned to check, the reTrain window was gone, and I can't find any reTrain log. Where is the live reTrain log stored so I can see what it did and what problems happened?!

Thanks.

It does not matter for training which FXCM account is used - it would only matter for testing. I do not know why you could not download 2015 prices. But it's not good to train or test with missing 2015 history files, so make very sure before that you have them. Z12 retraining does not produce a log as to my knowledge. This could be good to add to the next version. But if you want to see the training process, just do a normal training instead of a retraining.

Thanks jcl.

To clarify, when reTraining a live strategy, where do the values for Spread, Commission, Roll, etc. come from? From the live Assets.csv? From AssetsFix.csv? From somewhere else?

The 2015 History files are not missing - but they are only the files from the install. The reTrain was trying to update one, but failed. Perhaps for more than I saw.

My process has been to Test and Train on a development machine, and Trade on a VPS. This means the VPS gets a vanilla install and nothing else - no run of Download, etc. So History isn't updated - until this reTrain was attempted. Would you suggest a different process?

Yes, I think producing a reTraining log is a useful update - it shouldn't be a "blind" process since it affects live Trading. Is this no log issue specific to Z12, or does reTraining never produce a log?

Thanks.

The spread etc. values come from the asset list, not from the broker.

So, if one has Tested and Trained on a development machine using a customized AssetsFix.csv, and then reTrains on a different machine - f.i. a VPS - which only has the vanilla AssetsFix.csv from the install (since nothing else is needed for Trading), the reTrain is invalid since it did not use the correct broker parameters?

Thanks.

Just make sure no history files are missing, and all is valid.

I don't know if it's relevant for you, DdlV but as I stated in another thread it seems to me that in the M1 Price History 2015..2016 from the Download Page the first 21 days of 2015 in GBP/USD are missing.

Thanks jcl, Sphin!

I'm just trying to understand how it all "hangs together". I thought I understood that the Training was based on "trading" results, which are in turn affected by the broker's parameters (Spread, etc.). And therefore these parameters would affect reTraining as well. But jcl is saying not, and I'm not understanding why?

Thanks.

January 2015 of the GBP/USD history was indeed missing! This will be fixed - thanks for the info. It was not detected by the gap detector because it was missing at the begin. - DdlV, training is for determining the optimal parameters of a system. Aside from special cases, spread or leverage depend on the broker and not on the optimal parameters.

Thanks jcl. I understand that spread, leverage, etc. depend on the broker and not the optimal parameters. What has me confused is the reverse question: Don't the optimal parameters depend on the spread, leverage, etc. of the broker?

In other words, for the same strategy the optimal parameters determined using one broker's spread, leverage, etc. will be different from the optimal parameters determined using another broker's (or account's) spread, leverage, etc., correct?

Thanks.

No. The optimal parameters of a system normally depend on the system, not on the broker.

Only exception are special systems with high cost dependency. For instance, a high speed system that ceases working beyond a certain trade frequency because the trading costs exceed the profit. In that case the training result would be broker dependent.

Thanks jcl. OK, now I understand what you're saying, I think.

Let me rephrase to be sure: For "normal" BarPeriods that we would use with Zorro, say 1 (minute) or greater, all brokers' costs are a tiny, negligible part of a system's profitability, dwarfed by the price moves we're trying to catch, and hence variations between brokers don't really matter.

However, if we try to push the limits to BarPeriods, say, <1 and catch smaller price moves there will come a point where different brokers' costs will have an impact.

Is that correct?

Or are there "gotchas" that will come into play at even the higher BarPeriods and make brokers' costs non-negligible?

Also, referencing a question in another thread, is this at all affected by broker/account type? DD vs. ECN vs. ???

Thanks!

That is almost correct, except that broker costs can have not a tiny, but a large effect on profit. But not on training. Training does not care much about broker costs since it's based on relative profit, not absolute profit. - I would not trade automated with a DD broker.

Thanks jcl. I thought I almost understood...

If broker B's costs are 2x broker A's, wouldn't a given system function differently, trade differently, generate different optimization parameters, Optimal F's, etc.? I.e., train differently because the different cost structures will make it trade differently?

I'm also lost about not auto-trading with a DD broker - isn't that just another set of cost parameters? Or are you saying a DD broker's cost structures and/or historical trading-against-you patterns aren't consistent?

Thanks.

Could it be specified in the manual? Currently fxcm is DD for new accounts

This is sort of self explaining since as to my knowledge, FXCM DD accounts don't allow API trading anyway.

Their policy changes every 2 months, so it would be hard to keep the manual up to date with their account types. But general rules of thumb for selecting brokers and account types are here:

http://manual.zorro-project.com/brokers.htm

My acccount is FXCM DD and I am using Z12 over there. But maybe the account was not DD and then they shifted into DD and thats why I can keep running zorro on it.

I see the updates about fxcm API issues with mini accounts and the description on DD accounts. It wasnt there the time I read it. I should have checked before asking.

Thanks jcl. I've seen the brief description in the manual, and would appreciate your further insights. I understand the philosophical perspective of wanting to trade against the market vs. against the broker, but at a practical level wonder:

a) In a supposedly NDD situation, we'd never really know if the broker had side deals with a liquidity partner(s) and actually traded against us, would we?

b) Another way of saying that: We have no way to know that every client gets the same ticks, do we?

c) All that aside, isn't a DD broker just another set of costs? In what way that matters to automated trading is a DD broker different?

Thanks.

I'll weigh in with my two cents to give jcl a hand:

a) Some brokers will actually supply you with a receipt for each trade which includes the details of the liquidity provider that took your trade. One such broker here in Australia is Global Prime. I use them for some of my automated trading and can recommend them highly.

b) You could always run two accounts side by side and compare the ticks you receive. But maybe your broker is aware of this possibility and gives the same ticks to the same IP address.... I am being slightly facetious, but the best way around this issue is to trade with a broker within a regulated jurisdiction. I know that the brokers here in Australia generally value their licenses extremely highly and would make a lot of effort to play by the rules. If you have a concern, you can lodge a formal complaint with the regulator (ASIC, FOS here in Australia) and be assured that it will be followed up. Trading with an unregulated broker or in a questionable jurisdiction means that you have to take the broker's word that they are playing by the rules. You can always choose who you trade with.

c) Not really. A broker's price structure isn't dependent on whether or not it is DD. The two price structures I am aware of are fixed spread, and variable spread + commission. What works best will depend on your strategy, to an extent. I would avoid DD not because of the price structure, but because of the fundamental conflict of interest.

Thanks boatman!

At the fundamental/theory level, I agree with the DD conflict of interest. However, on the other hand, in my (admitidly limited) experience with regulators, their (real) main purpose is to protect the industry under the guise of protecting you...

I'm really trying to get nearer to the real, practical bottom line. For exactly the same trade at the same time, why is DD worse than NDD? Is DD worse because the broker will simply give you whatever price/spread/etc. at any time that takes your money, and no matter how different from the price/spread/etc. received from the liquidity providers and that given to other DD traders and/or NDD traders at the same time?

Thanks.

Anyone have thoughts on this?

I don't know that I'd ever trade with a DD broker (esp. after jcl's admonition! ), but I would appreciate expanding my understanding with specific, practical examples of what DD brokers do that makes them problematic for algo trading...

Thanks.

The only reason I can talk about with any certainty is that with a DD broker, there is a conflict of interest. Unfortunately I can't talk about differences in execution as that would simply be speculation. Do you need more of a reason than a conflict of interest?

Thanks boatman. Separating the issues:

Broker selection: Yes, conflict of interest is a significant negative. Of course, this pre-supposes that none of the NDD brokers are colluding with the liquidity providers...

Education: There don't seem to be that many "levers" a broker has (given that costs are specified) - perhaps only price & spread & tick frequency & timing? - so I was wondering if there are any documented examples of how a DD broker misuses these levers in comparison to what comes from an NDD broker(s)? Perhaps someone else has examples...

Thanks.

Hi jcl. This thread sidetracked into a DD vs. NDD discussion, but I'd like to return to the original reTraining focus and clear up my remaining misunderstandings.

a) I understand the point that correct History needs to be in place for the reTraining to be good. In terms of my VPS, that seems from what I experienced to mean that a vanilla install isn't good enough, especially if the install happens in 1 year and the reTrain happens in the next year. (I.e., my reTrain successfully downloaded 2016 prices but failed trying to download 2015 prices.) It seems the solution to this History concern is to add a step before reTraining: Download and install (reinstall if updated) all Zorro History zip's (and any other history) needed by the strategy. This would ensure that all available History is present (to be "topped off" by the reTrain); and also that the latest History is available incorporating any fixes for errors that have been discovered. Does this process make sense to you?

b) I'm still having trouble wrapping my head around broker's costs differences not mattering to reTraining. It seems to me that different costs would lead to different trades and hence to different optimizations = different parameters. A specific question from my situation: I develop on one machine & Trade on a VPS, on which I've only done a vanilla install, and updated History (per above ). My development machine has my AssetsFix.csv. The VPS has your vanilla AssetsFix.csv. If I reTrain on the VPS, it will use your AssetsFix.csv - is this correct/OK?

c) If the only thing needed from the broker connection for reTraining is "topping off" History, then reTraining can be done anytime - like, say, Sunday as soon as the broker comes back up - correct?

Thanks!

I try to answer, based on my experience,

a) if you are not sure that the data you have downloaded by yourself from the broker are correct and gap free, the process you have described make sense.

b) I am not sure if training will generate different parameters based on the assetfix you are using. For sure different assetfix will drive to different test results.
I experienced different test results not only with different assetfix but even with different margin setting and the same assetfix.
In old z12 version <1.4 this behavior was very relevant. Not as important with the new version. I do not know why... before trading I test the z12 with 50, 100, 1000 margin setting and I compare the results. With my broker, higher margin generates better test results.

c)I re-train the z12 during normal trading hours just after having updated the assetfix with the download script. Spread and margin requirements are different in low liquidity markets on my broker, but this is broker dependent, I guess.

HtH

Thanks MatPed!

I hope jcl will also add his thoughts/confirmations.

Thanks.

a) Yes, you must not train a system without having correct, gap-free and recent historical prices. The files from the download page won't do. They are correct, but not recent.

b) You normally do not train a system for a particular broker. Only exceptions are systems that depend on certain broker parameters, f.i. a system that exploits rollover. Or a system that trades in different ways dependent on leverage.

c) Since training a system does not require a broker connection, you can train it on Sunday, on Christmas, or at any day you want.