AlexanderRC
06 Nov 2014, 21:58

Can you provide specific parameters you are testing with?

What behavior should be expected with these parameters?

AlexanderRC
05 Nov 2014, 13:43

RE:

Spotware said:

The problem I encountered is that [Robot] attribute is recognized even when it is enclosed in //, /**/ comments

We can recommend you to remove Robot attribute instead of putting it into the comment. We are not going to change this behavior in near future.

That is exactly what I am doing. That is a manual step. Too sad that tokenizer does not differentiate between comments (or excluded parts of the source code) and actually applied attribute. (I assume that the analysis for several classes with applied [Robot] attribute is done at the source level, not at the compiled [in-memory] assembly level).

You should get an error message "Project "Robot1.csproj" contains more than one algo source file."

We will change this message.

Good, the error message is misleading now. The introduction of VS integration permits us to use additional .cs files as a part of .csproj. Even files included by reference (from external directories) work as expected.

I am trying to create a Multi-cBot backtest solution here by gathering several cBots into one.

cAlgo and cTrader do not support .algo files with several algo types (cBots or Indicators).

That is why I have created a solution to run several cBots inside a main multi cBot to see the combined curve in backtesting mode or even to optimize volumes for individual cBots to get a smoother curve when they work simultaneously.

To minimize source code changes when compiling as part of invidual cBot or as a part of multi cBot I am using conditional compilation to include or exclude required changes for multi cBot integration. Removing [Robot] attribute via #ifdef should have allowed me to do just that. Now I have to add #define MULTI_CBOT and comment out [Robot] attribute and change it to something like //[NRobot] in a .cs for individual cBot when compiling it as a part of multi cBot.

Also, symbols defined at the project level seem to be ignored.

You are right, conditional compilation symbols are ignored. We will consider to support conditional compilation in the future.

The symbols are ignored only when defined at the project level. When I add #define FOOBAR into the source file directly, #if FOOBAR works later in that file as expected. The only effort to support project level symbols would be to pass symbol defines down to the C# compiler engine.

AlexanderRC
05 Nov 2014, 00:40

Should not OnError() virtual method be marked as [Obsolete]?

As it is not possible to deduce which API call caused the error?

AlexanderRC
05 Nov 2014, 00:20 ( Updated at: 21 Dec 2023, 09:20 )

Also, symbols defined at the project level seem to be ignored.

AlexanderRC
30 Oct 2014, 17:35

RE: RE:

tradermatrix said:

AlexanderRC said:

You can compare EntryPrice of an opened position with Symbol.Bid or Symbol.Ask. To get the difference in pips you have to divide the delta between the two by Symbol.PipSize.

hello 
have an example in writing?

You can contact me via the email in my signature for additional help.

AlexanderRC
29 Oct 2014, 20:39

You can compare EntryPrice of an opened position with Symbol.Bid or Symbol.Ask. To get the difference in pips you have to divide the delta between the two by Symbol.PipSize.

AlexanderRC
29 Oct 2014, 15:45

RE:

Spotware said:

Is tick data being downloaded from broker server to user's computer? if yes, where can i find them? if no, would like to know how reliable is tick data backtest in calgo. afaik, in mt4, tick data has to be downloaded locally so not sure if calgo does the same?

cAlgo automatically downloads tick data from Spotware's servers. Tick data is broker specific. Tick data is 100% reliable because it contains every tick. You can find tick data on your machine in the following directory:

C:\Users\%UserName%\AppData\Roaming\%BrokerName%-cAlgo\BacktestingCache\Ticks

For every date there is a separate file in folder named after the symbol. The files are in a proprietary format with scrambling (reversible encryption). The only value of looking at them is to check whether the specific date and symbol has been cached or not.

and it also seems like users need to be connected to the internet to run a backtest, why?

We plan to remove this restriction in the future. Thank you for your feedback.

Please add the ability to use user specified tick data from a CSV file at the same time.

AlexanderRC
28 Oct 2014, 05:28

A combined indicator can be written which would instantiate two indicators and copy data from them onto a combined chart. That should be pretty easy even for a beginner cAlgo programmer.

AlexanderRC
22 Oct 2014, 17:22

You should extract the time portion from Server.Time and compare that with start and end TimeSpan's. Look for DateTime.TimeOfDay. Note that if start time is grater than end time (night), the comparison must be adjusted. Also, beware of the TimeZone property of Robot attribute.

AlexanderRC
22 Oct 2014, 16:40

Better yet some kind of a public API into backtesting engine or optimizer itself.

AlexanderRC
19 Oct 2014, 14:33

Create a request on vote.spotware.com

AlexanderRC
19 Oct 2014, 14:32

There are no "Scripts" concept in cAlgo as of now. You can make a cBot which does some things in OnStart() handler and then calls Stop() to stop itself.

AlexanderRC
17 Oct 2014, 14:16

RE:

Spotware said:

OHLC data mode quarantines that second tick in every minute is the highest price of current minute and all other ticks in current minute will have smaller prices. It is extra information that could cause misleading Optimization and Backtesting results. That is why we decided to remove OHLC data mode from backtesting and optimization.

Now I see.

Another approach would be to add an additional piece of information to the bar: whether high or low occurred first (or when they occurred exactly). That you would simulate highs and lows in the order they occurred (or even at the exact time they occurred).

For now to get the best combination of speed an accuracy I am going to skip certain OnTick() events if the price went monotonically up or down and that does not require reevaluation. But that depends on the logic of the specific cBot in question.

AlexanderRC
16 Oct 2014, 17:08

RE:

Spotware said:

Why are you not satisfied with m1 open prices data mode?

We decided to remove m1 OHLC mode because it provides extra information to cBot during backtesting. Imagine that you could collect prices during a minute, than choose the highest/lowest one, go back in time and trade at that price. It is not possible in live running, but OHLC data mode worked in that way in backtesting. That is why we decided to replace it to open prices data mode.

"Going back in time" during backtesting? What do you mean? As far as I remember Server.Time increased monotonically during OHLC backtesting.

AlexanderRC
15 Oct 2014, 18:29

RE:

Spotware said:

We have changed m1 data mode in cAlgo 1.27. Since now we generate 1 tick (open price) per minute bar.

Please bring back the old mode of "open, high, low, close". Adding "open, low, high, close" as a variant would also be helpful.

Using m1 (or any other timeframe) with high and low may be faster than tick data for cBot optimization when such tradeoff between accuracy and speed is acceptable.

AlexanderRC
10 Oct 2014, 14:04

Another quick feature to add would be to show max equity and balance draw down in absolute values in Trade Statistics tab in Optimization and Backtesting sections. There are columns for that in optimization results, so adding them to Trade Statistics should be pretty trivial.

AlexanderRC
10 Oct 2014, 13:57

RE:

WhiteSage said:

Is there a better method? This doesn't work with classes used only as a set of functions ( as its never instantiated).

If all of your methods in your custom helper class are static, then you need to store the reference to the currently running cBot in a static field of your custom class. You can do that in a constructor of a cBot or in the OnStart() method before using any of the static methods of the custom helper class. Print() methods are now public and do not require a subclass exposing them as public via some proxy methods. As every cBot seems to be running in its own AppDomain storing in a static member should be safe. But I may be wrong here as all cBots may be running in a separate, but shared AppDomain, I have not investigated that yet. If the AppDomain is shared, then if one of the cBots is stopped, the stored reference would prevent it from being garbage collected. The consequences of that are unknown.

Another approach would be to poke around with a Reflector tool and find the eventual method which is used in printing to the log. If I remember correctly the internals, the eventual call is static so you would not need an instance of a Robot (Algo) class for that. But that is a very hacky and unreliable way to do that as internals may be changing from release to release. Also, you may need to work around some security issues to call non-public methods via reflection.
 

AlexanderRC
30 Sep 2014, 17:19

Multiple orders (pending/limit) can be done quickly from a cBot with whatever parameters you desire. It is fairly trivial to write one.
 

AlexanderRC
30 Sep 2014, 17:15

RE: RE:

jobenb said:

Just to confirm the limitation that we are dealing with here and to put it into perspective...

My broker currently offers 64 currency pairs. If cTrader / cAlgo can only handle a maximum of 500 open orders / positions then that means I can only trade with about 7 - 8 orders / positions per currency pair. This is really limiting for traders since it is common to scale in and out of positions.

I sincerely hope that this issue is dealt with as soon as possible.

Thank you!!

Please vote for Modify volume of a position on vote.spotware.com. If the feature is implemented, you will be able to change the volume of the current position(s) instead of opening additional ones.

AlexanderRC
28 Sep 2014, 16:39

I had a similar problem.

Currently I am setting a timer with the first interval for to be fired at expected time of bar in a different timeframe and in the handler I restart the timer with the interval adjusted for the next bar. I have to recalculate the interval in the handler every time due to the handler being fired

Are there any better solutions to generate OnBar() events for a timeframe that is different from the one selected on a chart or specified as a parameter in backtester/optimizer?