adviseLong(DTREE produces a .c file that the compiler rejects

A script with adviseLong(DTREE produces an intermediate file which is not accepted by the built-in compiler. Therefore, Zorro dies between the Train and the Test phase.

I can compile the offending file with gcc 4.8.2. So, I can detect no syntax errors on my side. Perhaps the source file is simply too large.

Yes, there is a limit to expressions in lite-C. This is normally only relevant for the pattern finder that can create huge expressions, therefore the FAST flag can be used for a workaround. There is no such workaround for DTREE. But for some sort of consolation: if a decision tree is so complex that the compiler can not compile it, the system would be curve fitted and useless anyway. A sign of a predictive edge is a relatively simple and short decision tree.

When the pattern finder has produced such a file, the fault is not reported to the user until the Test phase.

Additionally, there is a combinatorics problem. Train will produce (2 * WFOCycles * Assets * Algos) prediction rules. Some rules may be simple and others may be huge. All it takes is 1 (?) rogue prediction rule to blow up the file and hit the system limit. It is hard to imagine a set of input signals which has predictive power (enough to avoid runaway tree growth in your library) in all directions, cycles, assets, and algos. That's a statistical came you are bound to lose.

To spare your user some agony, if you're interested, you can
- ensmarten your pattern finder so it bails out before producing absurd output (Ideal)
- tentatitvely compile each intermediate file when it is produced. that way user does not waste time training any further parts of this strat.
- nullify any prediction rules which are over complex. just replace them with return 0. (I'll probably do this in an offline script. but, it breaks TESTNOW.)

I discovered that my strategy had a typo that caused the training targets to be irrational. This supports your GIGO perspective.

I discovered the typo by code inspection. The strongest indication for my error would have been if Zorro reported the avg trade time or some statistics about the training targets, during training. I had a certain idea about the ratio of winning/lossing trades (1:1), and the avg trade duration (<24 bars), that would have been violated in the typo situation and set off alarm bells for me if they had only been surfaced in the UI.

Despite it being my typo
I wonder if the fact that Zorro is capable of quietly producing intermediate files that it cannot itself consume bothers you at a basic level.

I am not sure of the level at which it bothers me, but the compiler is in fact rather simple built and thus subject to restrictions, such as a limited length of expressions. There is however no such restriction to generating rules. They can be of any complexity. Generating a problem is always easier than solving it - that's life.

can you add a depth limit to the rule generator?

The generator must then sort of simulate the expression limits of the compiler - this would be awkward to implement. It might indeed have some advantage, but I think is not worth the effort at this point. With the current method, with no restriction to the generator, you could at least compile the .c code with GCC or VC and include it in a DLL.