This way, the column in the asset list takes a different meaning when the value is positive.

Now, in the context of the script, the multiplier is actually positive.

For the first question, I'd check out Robert Carver's book Systematic Trading, which goes into great detail on volatility / risk / reward management, maybe more detail than you'd expect from an average trading book.

Pip will be the smallest increment of the price you would see on the ticker feed. The configuration of PipCost depends on 1) your pip configuration and 2) whether you're using T8 (Contracts) or T6 (vanilla bars) for backtesting. The former makes use of the Multiplier value, and the latter is rather multiplied into PipCost.

I'm planning to trade two algorithms, one for SPX500 and the other for US Treasury 10-Year Bonds. Given their distinct risk profiles, such as varying Sharpe Ratios, I'm looking for guidance on how to approach this effectively. What strategies or methodologies should I consider to balance the risk and optimize performance across both instruments?

Additionally, I'm unsure about setting the asset variables, particularly Pip and PipCost, for futures. Any insights or best practices in this regard would be greatly appreciated. Thanks in advance!

Your code is wrong. You need to explicitly select trades to get their info. Try trade loops or TMFs.

In the context of Hedge mode = 6, tradeUpdatePool() will enter and exit positions.

I would like a special flag that causes tradeUpdatePool() to only close positions.

Obvious use case:
1) Hedge mode is 6.
2) Have hundreds of positions open, and margin is maxed out.
3) Need to change portfolio. Call enterLong and exitLong for multiple algos and assets. (Pool trades are not affected yet.)
4) Reduce positions in order to free up margin by calling modified tradeUpdatePool().
5) Wait for margin to free up.
6) Call tradeUpdatePool() again, but this time to open positions.

multiple timeframes? Not sure about that. typically use: ZigZag(Data, [MaxVal(Data, 1440) - MinVal(Data, 1440)] x factor, 5, BLUE). where factor = {0.318, 0.618, 1.618}. Plot them separately; you should get multiple ZigZag of different scales.

Looking good, though I will never understand why 3DGS is so often selected for bible games lmao

Yeah, I think (as I've experienced myself) that you should stick to one thing, especially in the beginning. Here it's best to choose something you're already familiar with. Meaning Algo-Trading if you're already able to program, longer term investing if you have experience in Accounting and Management of bigger companies, etc. Interestingly I noticed two things as I progressed.

Firstly you'll understand how others (who haven't choosen your path) trade. At some point I realized, how many long-term profitable discretionary Traders trade and why it works. But as this isn't my path it's just a fun thing to know, that you can maybe exploit later on.

Secondly, especially in the later stages (when you really know what you're doing) it seems to me, that it is actually better to look in other directions. Those directions don't have to do something with trading directly, as long as you can somehow project your learnings onto trading. There are dozens of examples of this in the trading world like Ehlers applying Digital Signal Processing and FM/AM Processing onto Prices to catch cycles.

Good knowledge in other fields will probably help you to get more profitable, but only if you've already advanced sufficiently in your path. And you should never leave your path and always come back to apply what you've learned to your path.

But that's just my experience and everyone's approach to trading is (and should be) different.


To the question above:
When I'm building strategies I'm following a plan, that seems to work quite well for me. (As I've noticed it is quite similar to JCL's Plan, definitely check it out). Meaning that I'll search for Filters (one to two at max) to apply to my signal. Sometimes I use ones I already found/developed, sometimes I develope/search for new ones. Since every strategy you trade should be different not every filter will fit every strategy. I'm not struggling with finding a particular filter but sometimes it is just a bit difficult to find ones that are fitting.

But in my experience you get better at finding them with time (just as with signals) and if you don't find a fitting one, that may mean that you're idea is just not working. Document the idea and move on.

There are so many possible choices in this field, but I don't think the actual edge difference between them is significant.
I think it's better to stick with one thing you've chosen and push it consistently and to the end, no matter what anyone around you says.
It may seem like everyone else and I have similar conditions, but we actually have different conditions to do well and different preferences.
I don't know about anything else, but I do know this. That I shouldn't get lost.

Hi @all again,
Sorry for the above, meanwhile figured out a few things.
But currently i am again at ZIGZAG indicator. Would like to use it in mutliple Timeframes.
For example one in 1 hour and the other in 4 hour. Is this possible now?
By the way, am still using Zorro version 2.40.
Any hints and tricks are welcome,
Thanks in advance ...

It depends on your strategy if per cycle oversamping makes sense. For instance, when your strategy trades at fixed times, all cycles will obviously have the same trades and you need no oversampling.

Meine neue Autorenseite: https://books.lotter.org/

Hi Petra,

Thank you for answer. Can you please elaborate how time offset makes different price curves needed for oversampling? I made a quick test and it seems it does not. It only runs _n_ cycles with time offset as you mentioned, and according to docs SampleOffset is used for a histogram of the performance dependent on start time, rather than generating slightly different price curves.

I'm sorry if I wasn't clear in the original question, but I try to achieve this:
Oversampling the bars is a method to run multiple test cycles on slightly different price curves that are derived from the original curve and contain the same inefficiencies. This produces more trades, generates more realistic backtests, and allows to evaluate the effect of price curve randomness on the system performance.