This issue has been fixed, it's been a while. I cannot reproduce it. Make sure you download historical data when you backtest.
Hi Panagiotis,
The values I get for the account margin are still not matching while backtesting the code above. Are you backtesting an index? Probably not.
I selected the historical data, as suggested. However, the account and symbol currency is the same (USD) and still I am getting different results when selecting/unselecting this option. Why?
I checked this with both Varianse and Pepperstone (using historial data). Below is the backtest output with Varianse.
Hi ncel01,
Yes I do
However, the account and symbol currency is the same (USD) and still I am getting different results when selecting/unselecting this option. Why?
The functionality should work correctly when the option is checked. We are checking why it is not working when unselected and the quote currency matches the account currency. In the meanwhile, keep it checked.
Panagiotis,
The functionality should work correctly when the option is checked.
How come, when my screenshot clearly shows that Account.Margin is returning 0 even with an open position? Did you check this with some other accounts/brokers (apart from Spotware)? If not, can you please double-check this?
This issue has been fixed, it's been a while. I cannot reproduce it. Make sure you download historical data when you backtest.
Hi Panagiotis,
The values I get for the account margin are still not matching while backtesting the code above. Are you backtesting an index? Probably not.
I selected the historical data, as suggested. However, the account and symbol currency is the same (USD) and still I am getting different results when selecting/unselecting this option. Why?
I checked this with both Varianse and Pepperstone (using historial data). Below is the backtest output with Varianse.
Are there any plans to improve CLI functionality, given that it has been launched more than one year ago without any improvements so far?
It's almost 2025 and many traders still don't have a full/effective alternative to cTrader desktop for algo trading, which is really required for obvious performance limitations and this can be frustrating.
I believe that most of the effort to develop the CLI has been already made. Please consider to give it some priority to this to make it “final”.
Thank you.
Hi ncel01,
The answer remains the same :)
Best regards,
Panagiotis
Panagiotis,
Clear enough.
Not even having any plans to improve this is very surprising and disappointing, to say the least.
Are there any plans to improve CLI functionality, given that it has been launched more than one year ago without any improvements so far?
It's almost 2025 and many traders still don't have a full/effective alternative to cTrader desktop for algo trading, which is really required for obvious performance limitations and this can be frustrating.
I believe that most of the effort to develop the CLI has been already made. Please consider to give it some priority to this to make it “final”.
ncel01
06 Aug 2024, 21:06
( Updated at: 07 Aug 2024, 05:28 )
Yes, please delete this as it does not make any sense for such an advanced trading platform. This is not only annoying but also inappropriate as it can be understood an investment recommendation.
ncel01
06 Aug 2024, 20:59
( Updated at: 07 Aug 2024, 05:28 )
Hello,
I've already mentioned this long time ago but, apparently, it is not yet available in cAlgo. Since on the apps all the symbols are grouped by class assets, I assume that these already contain this attribute.
Why not making available something like Symbol.ClassAsset (Forex, Indices, Crypto, Metals, Shares, etc..)? Because, as for the symbol names, it is hard to standardize this among all brokers, maybe? Can be.
You would need to get all the bars from the server and check the high/low. Try M1 to save time.
Best regards,
Panagiotis
Hi Panagiotis,
How can that be achieved programmatically?
Symbol.AllTimeHigh would be straight forward but I believe there is no such property available. So, what can be a work around here?
Thank you.
Hi ncel01,
You can load all the bars by using Bars.LoadMoreHistory(). Then you can use Bars.HighPrices.Maximum(Bars.Count) and Bars.LowPrices.Minimum(Bars.Count) to get the respective high and low.
Best regards,
Panagiotis
Panagiotis,
Thanks.
Bars.LoadMoreHistory() does not seem to change anything, no matter the time frame. On the other hand, it looks like max/min historical prices are only caught when using monthly bars :
var bars = MarketData.GetBars(TimeFrame.Monthly);var maxHistorical = bars.HighPrices.Maximum(bars.Count);var minHistorical = bars.LowPrices.Minimum(bars.Count));
Hi there,
Note that Bars.LoadMoreHistory() currently works only in real time execution and you need to call it until it returns 0, so that all bars have been loaded.
Best regards,
Panagiotis
Right. I was testing it in real time but I was not aware that multiple calls would be (maybe) needed.
However, it looks like for shorter time frames it is not possible go as far back in time, even when all bars are loaded (Bars.LoadMoreHistory() = 0), leading to different results.
Hi ncel01,
It always depends on how much data is available by your broker.
You would need to get all the bars from the server and check the high/low. Try M1 to save time.
Best regards,
Panagiotis
Hi Panagiotis,
How can that be achieved programmatically?
Symbol.AllTimeHigh would be straight forward but I believe there is no such property available. So, what can be a work around here?
Thank you.
Hi ncel01,
You can load all the bars by using Bars.LoadMoreHistory(). Then you can use Bars.HighPrices.Maximum(Bars.Count) and Bars.LowPrices.Minimum(Bars.Count) to get the respective high and low.
Best regards,
Panagiotis
Panagiotis,
Thanks.
Bars.LoadMoreHistory() does not seem to change anything, no matter the time frame. On the other hand, it looks like max/min historical prices are only caught when using monthly bars :
var bars = MarketData.GetBars(TimeFrame.Monthly);var maxHistorical = bars.HighPrices.Maximum(bars.Count);var minHistorical = bars.LowPrices.Minimum(bars.Count));
Hi there,
Note that Bars.LoadMoreHistory() currently works only in real time execution and you need to call it until it returns 0, so that all bars have been loaded.
Best regards,
Panagiotis
Right. I was testing it in real time but I was not aware that multiple calls would be (maybe) needed.
However, it looks like for shorter time frames it is not possible go as far back in time, even when all bars are loaded (Bars.LoadMoreHistory() = 0), leading to different results.
You would need to get all the bars from the server and check the high/low. Try M1 to save time.
Best regards,
Panagiotis
Hi Panagiotis,
How can that be achieved programmatically?
Symbol.AllTimeHigh would be straight forward but I believe there is no such property available. So, what can be a work around here?
Thank you.
Hi ncel01,
You can load all the bars by using Bars.LoadMoreHistory(). Then you can use Bars.HighPrices.Maximum(Bars.Count) and Bars.LowPrices.Minimum(Bars.Count) to get the respective high and low.
Best regards,
Panagiotis
Panagiotis,
Thanks.
Bars.LoadMoreHistory() does not seem to change anything, no matter the time frame. On the other hand, it looks like max/min historical prices are only caught when using monthly bars :
var bars = MarketData.GetBars(TimeFrame.Monthly);
var maxHistorical = bars.HighPrices.Maximum(bars.Count);
var minHistorical = bars.LowPrices.Minimum(bars.Count));
If this is really the case it should be considered a bug, in my opinion.
As expected, the bid/ask prices are updated on the spot, and the same should apply to all the methods/properties that directly depend on these prices, which is the case of NetProfit, among many other.
It's very unlikely that anyone will ever expect something different here.
@PanagiotisCharalampous
Could you please check this with the development team?
Limit orders are expected to be filled at the submitted price or better, resulting in (virtually) no slippage, which is not exactly the case for stop orders.
You made a comparison with MT. I'd like to share the following (considered for me a lot relevant) when it comes to pending orders:
Unlike cTrader, MT does not allow traders to place these when the market is closed, which seems to me very odd/archaic in 2024 🙂
Wrong Account.BrokerName and Account.Number for a bot with cloud instance
Did you double-checked this? This is what I still see with v. 5.0.28:
I've also noticed that the way information is shown in the cloud cBot log/UI is not always matching the code sequence/order.
Backtesting logs: The filter (Information, Trading, Warning, Error, etc.), as well as the DateTime sort option, is still missing. Please make this available again, as it was in the previous 4.x versions.
Keep in mind that eliminating useful features can be frustrating for users. However, if there's a good reason behind this decision, please feel free to share it with the community.
Appreciated.
Hi ncel01,
It seems that the issue is fixed in cAlgo but a fix needs to be released on the server side as well. So you will have to wait a bit more for the solution to take effect. Regarding your suggestions, please post them in the relevant section.
ncel01
20 Aug 2024, 11:14
Given the absence of any clarifications, I will assume that the following has been announced by mistake:
The following issues were addressed
@ncel01