Hi

We trade with price-based bars, which means that trading a portfolio of assets from the same script will be tricky at best.

Until I'm more familiar with the platform, I'd be planning to trade each asset from a separate script. This would involve perhaps 10 Zorro sessions on our small VPS.

Unfortunately, this means 10 times the memory (though the .exe seems pretty frugal), 10 times the bandwidth etc.

We trade 24/5. Can anyone foresee any problems with this (such as cumulative memory leaks), or is it a non-issue?

Why would trading price-based bars preclude you from running a portfolio via a single script? And what do you mean by 'price-based bars'? I'm assuming this is not your regular OHLC bars?

Hi Boatman

The manual for bar() makes it clear that portfolio testing with price-based bars is not trivial:

User-defined bar lengths can normally be used with single-asset strategies only, as different assets would produce different bars. For a portfolio system, user-defined bars had to be simulated with the TimeFrame mechanism or with a tick function.

There's a thread where the developers say that they don't have sample code for doing this, so I'd be on my own. Not for the first iteration, I think.

Hi Scotpip,

Yes, you will need multiple Zorro sessions for range bars, which are not that resource hungry, but if you use multiple MT4 sessions for multiple systems it will start slowing down. I'd say 1 MT4, 5-10 Zorro per 1 core per 1GB RAM is ok.

May I ask what kind of range bars are you using, and are you having success adapting them?

edit:typo

I have been able to trade 2 MT4 with 3 Zorro on 1 core vps and I agree with Finstratech. MT4 is the way far hungrier than Zorro.
I guess that TICK mode will require more resources too.

Ciao

Hi Finstratech

We use Renko and a proprietary price-based bar.

For our style of trading, all our testing has shown that time is not a predictor of outcome - in other words, that the inefficiencies we have found are based on price alone.

As time appears to be noise for our strategy, we find we get better results by eliminating it and trading purely on price and volume.

Your results may vary!

Now I get what you're asking - I previously didn't understand that you wanted to eliminate time.

If I were doing this, I'd use the tick() function to keep track of price changes and the plot() and plotBar() functions for charting the price-based bars. You'd need to set ColorUp=ColorDn=0 so that regular bars are suppressed in the output.

Interesting that you find time equates to noise in your research - I find the exact opposite. I guess it goes to show that there are many ways to make money in the markets.

Scotpip,
Glad to see someone else is working with Renko bars. Are you using the code provided by Zorro for Renko bars?

Time factor however is still present in range bars (sadly), because BarPeriod needs to be always set and THAT always impacts the result. I find it's a drawback for range bars.

Hi Finstratech

I was excited when I saw that Zorro had added the ability to build price-based bars, as it would be good to have a fully developed testing and production platform and none of the other consumer-level options can do what we need.

But I soon ran into show-stoppers. The problem is that most platforms, even some of the mid-market ones, have built the concept of time into their core code. So any attempt to add Renko or Range ends up as a bit of a hack. With Zorro, it looked decidedly non-trivial to do any kind of portfolio work, which is a must-have for us.

So I'm back to my home-rolled setup in JForex. It means broker lockin, but Dukas are a decent broker so it's not a big issue. And although it's been a lot of work, as the JForex SDK is more of a low-level toolkit than a platform, it is extremely versatile and able to handle our somewhat unusual requirements.

It seems that early on they made engineering decisions that meant they could deal properly with price and volume bars, so if you get stuck you might take a look. Also, there is tick level historic and live data, so you can build any bar you can imagine quite easily.

The flexibility comes at a price, as the API is HUGE and the learning curve is steep. But it's quite well documented in the Wiki and the Javadocs are pretty helpful. But at times you'll be writing reams of code for features that are built in to Zorro.

Compared to Zorro my backtester is crude, but it's flexible and fast and does what I need.