scotpip
17 Sep 2024, 13:15

RE: CBot instance crashed with error #C15EF25B - BUG (issue found).

Bug still unfixed as of 17/09/24.

scotpip
13 Sep 2024, 10:40

Hi

I realise that things have been moving quickly since the .Net 6 release, but it seems that many of the example bots and indicators in Automate need updating. If I try and launch them In Visual Studio with .Net 6 I often get an incompatibility warning, and they show as No Code Available in the CTrader client. The ones that do load often include depreciated code.

Also, the docs in the client editor are out of sync with the online docs. This led me astray till I realised. Take this example, which is still using MarketSeries rather than Bars.

Any plans to tidy this up? Working examples would be particularly helpful.

 

scotpip
13 Sep 2024, 10:40

Hi

I realise that things have been moving quickly since the .Net 6 release, but it seems that many of the example bots and indicators in Automate need updating. If I try and launch them In Visual Studio with .Net 6 I often get an incompatibility warning, and they show as No Code Available in the CTrader client. The ones that do load often include depreciated code.

Also, the docs in the client editor are out of sync with the online docs. This led me astray till I realised. Take this example, which is still using MarketSeries rather than Bars.

Any plans to tidy this up? Working examples would be particularly helpful.

 

scotpip
09 Sep 2024, 17:51 ( Updated at: 10 Sep 2024, 05:12 )

The workaround!

No response :-(

I've noticed from the Suggestions forum that this has been an issue for years now, so it's not me being dim as I first thought.

Is there really no move to get this fixed? It seems like a pretty ugly anti-feature. 

In an algo, there is the workaround I mentioned where we can calculate volume ourselves using the OnTick() event. But we can't see volume on the charts when trading manually or checking our algo trades. 

I was about to write an indicator, but a kind soul in the community got there first. For anyone who stumbles on this thread, here's the fix:

https://ctrader.com/algos/indicators/show/3045/

scotpip
08 Sep 2024, 15:24

Still not fixed in late 2024!

I've just run into this. Like you, I had to figure out why my algo was broken…

It's ugly, but at the time of writing they still haven't fixed it (Sept '24)! I posted a query about it some time ago on the Algo section of the forum, but no response to date.

I did figure out a workaround. We have the OnTick() event both live and backtesting. So I wrote a little class to keep track of the volumes that way. Ugly and little absurd, but it does the job.

Ironically, they DO provide the tick volume in the tick bars, where the are quite useless…

scotpip
05 Sep 2024, 14:16 ( Updated at: 05 Sep 2024, 22:44 )

Struck me that I should also check volume in live demo mode.

Same problem - Range Bar volume is always set at 1 in both OnBar() and OnBarClosed().

I really do hope I'm missing something, or CTrader won't be viable for me.

EDIT:

I've realised that I could calculate the volume myself in the OnTick() event - so not a show stopper. But not ideal either - I'd still appreciate a solution.

scotpip
23 Aug 2024, 11:02

RE: Improving backtesting speed

Hi Panagiotis

My backtester is fairly comparable, and as I say a lot faster. The speed increase was mainly due to tackling a large number of small issues, but the cumulative effect was impressive.

I was also a beta tester for Tickblaze, another C# platform that's faster. Tickblaze is a professional trading platform and highly featured.

And I've done some work in Zorro - which is highly featured and very much faster - though to be fair it's built in C++. 

Are you really saying there's no scope for increasing the speed?

scotpip
22 Aug 2024, 18:56 ( Updated at: 23 Aug 2024, 06:32 )

Backtesting Settings -> Data Dropdown Bug

I'm not clear where we're supposed to report bugs. If this is the wrong spot, please advise.

In this release, I'm seeing a repeated option in the Backtesting Settings → Data dropdown dialogue.

scotpip
22 Aug 2024, 18:38 ( Updated at: 23 Aug 2024, 06:32 )

A decade now, and this essential feature hasn't even made it onto the Planned list :-(

With the new console feature, CTrader offers a serious execution environment for sophisticated algo traders. It could attract some big players to the platform, given that most other consumer platforms have a reputation for being flakey in production. This would generate the kind of volume that your brokers would appreciate!

But the lack of proper walk forward testing is a huge turnoff for anyone serious. It's not really optional on an algo platform.

This is something I've implemented twice with my own backtesters, and it was relatively straightforward. You guys are much smarter than me - surely you can get this done?

If you want an example of how to do it right, please take a look at Zorro, which offers both rolling and anchored testing:

https://zorro-project.com/manual/en/numwfocycles.htm

scotpip
22 Aug 2024, 18:18 ( Updated at: 23 Aug 2024, 06:31 )

RE: RE:

I do this, and also prefix my bot names with a code. 

That way I can use the filter field to quickly filter down to the class of bot I'm working with.

scotpip
22 Aug 2024, 18:12 ( Updated at: 23 Aug 2024, 06:31 )

RE: How to Access OHLC Prices in the Backtester?

Hi Panagiotis

Many thanks! That seems to be working now, both with m1 data and tick data.

I assume that all 4 prices are used when evaluating exit stops, and calculating indicators like the ATR which need OHLC values?

If you're open to feedback, I feel that the bar event methods and docs are confusing. This is something you might care to review.

In the tutorial, OnBarClosed() isn't even mentioned:

https://help.ctrader.com/ctrader-algo/articles/for-developers/create-a-cbot-in-5-mins/#add-a-new-cbot

The wording doesn't make it explicit that you will be accessing an incomplete new bar, rather than the newly completed old bar with all the OHLC data. In every other platform I've used (quite a few now) OnBar() passes or signals the interesting old bar rather than the uninteresting new bar.

The next point of confusion is the dropdown from the cog menu item, which clearly states that you are only getting open prices. While in fact as you have just explained you can access all 4 prices. (And there's also the bug where it shows the same option twice). Surely this is a UX glitch?

So unless the user takes a deep dig through the API docs, the procedure for accessing this vital data is both unintuitive (in the sense that other platforms do it differently) and well hidden (in the sense that the tutorial doesn't explain it and the cog dropdown text is misleading).

Maybe I'm unusually dim, but I'm surprised that more people haven't run into this roadblock. It would be helpful if the tutorial and the dropdown were more user-friendly…

Geoff

scotpip
21 Aug 2024, 16:29

Another issue - the dropdown Data selector is showing a duplicate entry for the "m1 bars from Server" option. Is my client corrupted in some way? This clearly isn't right.
 

scotpip
15 Aug 2024, 10:57

Just a heads up - this thread is now out of date. 

Range and Renko backtesting have (at last) been added to the platform!

Now we've got the basics, let's hope we will begin to see more professional-level backtesting features such as decent reporting and walk-forward testing.

scotpip
18 Sep 2023, 07:22 ( Updated at: 18 Sep 2023, 08:20 )

RE: Bug? Performance issue with tick-data backtesting

Hi Panagiotis

I'm not finding this a welcoming experience to the community - is this really how bug reports are handled here?

I've explained that I'm experiencing this issue when running the hello world default script.

What more do you want? Instead of giving me the brush off, please explain why you are dismissing this information and insisting that my report will be ignored unless I provide a different script that has the same issue?

I'd also point out yet again that others are reporting the same problem.

To repeat - when I run 8 years of server ticks through the hello world script, the client pauses for around 6 minutes at the end of the run, thrashing my CPU, before writing the stop message to the log and ungreying the run button. With shorter runs I get shorter pauses, but still much longer than I would expect given that this is a dummy script and there is nothing to analyse.

This is 100% repeatable on a Win 10 Pro workstation with 2 x 12 core Xeon processors and 96 GB of memory.

I really don't see how I can be any clearer.

If I was a developer and multiple users reported this issue I would want to check it out rather than ignoring the report. I'm happy to provide any additional information needed, provided the request makes sense and moves the issue forward. 

scotpip
15 Sep 2023, 15:40 ( Updated at: 16 Sep 2023, 13:59 )

RE: RE: RE: RE: Bug? Performance issue with tick-data backtesting

I've shown a simple way to replicate the bug - so I'm not clear what you're objecting to?

Are you backtesting with extended runs of server ticks? Because that's where the issue occurs. 

Also, as I've said, others are reporting the same problem.

It would be comforting if someone from the CTrader team responded. They don't seem to have a formal bug reporting system, so this is all we've got - hopefully they monitor the forum regularly?

scotpip
15 Sep 2023, 15:35

RE: RE: RE: Bug? Performance issue with tick-data backtesting

scotpip
14 Sep 2023, 19:00 ( Updated at: 05 Sep 2024, 16:32 )

RE: Bug? Performance issue with tick-data backtesting

Thanks for responding!

No need for my script - I think this is a generic bug.

To reproduce:

1. I created a new hello-world script and built it without alteration.
    
2. Ran EURUSD from 2014 - 2022 with server ticks.
    
3. From the point the progress bar stopped at the last tick to the point the Stop message was printed to the Log and the Run button was re-activated took very nearly 6 minutes. This is pretty extreme!

During this extended pause, the CTrader client was thrashing my CPU pretty hard. with a dark red High Power Usage flag in the Task Manager. It wasn't leaking memory.

I experience these extended pauses at the end of every tick-resolution run, whatever the script. The longer the run, the longer the pause.

I note that at least one other user has reported a similar issue in the forum.

As I've said, I have an HP Z-series workstation with Windows 10 Pro, 24 Xeon cores and 96 GB of memory, so it's not a client-side resource issue.

Seems to me that you have a significant issue on your side. I'd very much appreciate a fix.

scotpip
12 Sep 2023, 23:53

Just spotted this thread. 

As I reported in my own thread, I'm experiencing the same thing.

My script is simply streaming the ticks for a single symbol to run some simple analysis of the spread.

Then it writes out half a dozen lines to the Log from the OnStop() handler. 

Couldn't be simpler.The bot is not trading, so nothing for CTrader to analyse there.

For short runs of a few weeks, the pause is around 100 secs. For longer runs, the pause can be truly painful - I have to leave the client running in the background and get on with something else.

I have a Win 10 Pro workstation with 24 cores and 96 GB of memory, so it's not a resource issue. Running the script barely registers on the Resource Monitor.

There surely must be something wrong here? With a workstation of this power it's hard to imagine what the client could be doing that would take so long.

scotpip
12 Sep 2023, 18:44

You will find life MUCH more pleasant and productive if you take advantage of CTrader's integration with Visual Studio, VS Code or Rider.

The built-in editor is basic, to put it kindly, and isn't meant for anything serious.

IDEs demand a bit of a learning curve, but it pays off handsomely in the longer run.

scotpip
10 Jan 2023, 23:10 ( Updated at: 10 Jan 2023, 23:15 )

RE: RE: RE:

Hi

It's still in development, but nearly done.

For a developer, generating price bars from the runtime tickstream is trivial. 

If you want to speed things up by serialising completed bars and using them in your backtests you're in for a bigger project, because you'll have to simulate the cTrader exchange. cTrader itself will only know about the bar you specified in the bot instance, and will know nothing of your own bars.

The charting was fairly easy too. I strongly recommend the AnyChart javascript library, which is free for personal use. It is powerful performant and well documented - much the best of the bunch that I evaluated.

There is a feature to backtest against bars in CSV files, but here too they seem to have hard-coded for time-based aggregations.

Indicators are more of an issue. In my use-case accessing the cTrader indicators was more trouble than it's worth - especially as an API class I'd want to extend is sealed. I only use a couple of simple indicators so have built my own system. There are examples of indicator logic in C# and other languages all over github and on TradingView as well as here in the cTrader community if you need anything more exotic.

For me the main development effort has been elsewhere - for serious trading I'm having build a lot of functionality that's not available out of the box. The price-based bars have been a relatively minor part of the project.