The entry price of the position is the average entry price of the deals composing the position. If the position has only one opening deal, then the opening price should not change. If more opening deals are involved e.g. you have increased the size of the position after entering it, the entry price might change as partial volume is closed and deals removed from the position.
Best regards,
Panagiotis
Ok, thanks, that's helpful. I can see from logging that when the volume of a position is INCREASED the calculation of its new Position.Pips value is exactly: (oldPips * oldVol - spreadAsPips * increaseInVol) / newVol which is correctly distributing the pips on the old portion plus the immediate pip loss of the new portion (due to spread) across the new larger volume (and so the EntryPrice will be that many pips from the current price and represent the weighted average). Rounding of the calculation seems usually to the nearest 0.1 pip but sometimes goes the other way, possibly to correct for accumulated rounding error. That's all fine.
HOWEVER, I'm seeing the remaining portion of a position after a REDUCTION in volume ALSO has its Position.Pips altered. Why is that? Possibly the position was not combined really (in the live server or backtest memory) but rather kept as a collection of parts from each modification that increased volume, so that when it is later reduced some specific part is closed, in a LIFO or FIFO order or some other rule? Is this broker driven?
So maybe ModifyPosition does not really modify a position in the sense of ending up with one homogeneous position with a single EntryPrice & Pips profit? Can't brokers running cTrader handle merging modification deals into one net holding?
If not, please could the doc say so, and how do we know what the separate parts are so we can predict partial closing results (without laboriously keeping track of all modifications)? Is there any information in a Position that can tell a cBot the position's stats will not react in a predictable way if later PARTIALLY closed ('predictable' meaning Entry & Pips stay unchanged, profit prorata etc)?
I'm coming to the conclusion it's not good to mix increasing and decreasing volume via ModifyPosition; one or the other yes, predictable, but not both in the same cBot if it's basing decisions on Position.Pips or Account.UnrealizedProfit, or on almost anything other than Equity.
Thanks.
Update re "laboriously keeping track": not that hard, but involves keeping ‘account state’ data outside the cTrader account, like in a local file or cloud, not self-contained in the positions - unless perhaps cTrader could add a large Account.Comment field that could store arbitrary data, or make the Positions.Comment modifyable & bigger?? :)
Later: Actually only one adjustment number per position might need remembering in order to emulate proportional netting when partially closing a position that has been increased earlier - the difference between ‘the proportional Pips or Entry expected before the partial close is done’ and ‘the actual new Pips or new Entry that appears in the Position afterwards’ - so the Bot can apply that offset to later Pips & profit (with opposite adjustment to Balance). Is there any way of storing a small amount of data per position on the server, for instance a modifyable Comment?
We have received the information and the issue will be investigated soon.
Best regards,
Panagiotis
I have found that it can be ‘correct’ for there to be differences between backtests on v4 vs v5 because v5 handes swap differently - it deducts it from the Account.Equity around 22:00 on days it is due, whereas v4 didn't seem to ever deduct swap (it just reported an accumulated amount at the end) - as far as I can see by comparing detailed logs of same test on both versions. So if decisions are based on equity, they will be different.
Whilst having more accurate swap treatment is commendable, it is highly inconvenient to not be able to exactly recreate old saved results in order to know whether a change to the bot has improved it or not. An option to again NOT deduct swap would also act as a sanity checker / confidence booster for our migration to v5.
To address the above, please can there be consideration of adding an option to disable the newly imposed mandatory deduction of swap from equity in backtest & optimise, and an option to specify a fixed custom rate (so old tests can still be recreated even if the automatic rate changes), in much the same way as there is already an option to set commission & spread. Thanks for reading, Martin
martins
06 Nov 2024, 14:42
( Updated at: 06 Nov 2024, 21:05 )
RE: RE: .algo indicators don't reload
I have the same problem on 5.0.40 - if you're looking at an indicator instance (in Indicators tab of Algo) and rebuild it (in visual studio 2022) it unloads but does not reload. The instance remains but does not show its lines until the whole cTrader disktop app is restarted. Doesn't seem to make a difference whether it's .NET 6 or Framework. Might make a difference if it's 2019, I've only noticed this happening with newly created indicators for which ‘edit in visual studio’ starts up 2022.
This is worse than 4.9.2, where although the instance dissappears, it can be re-added without having to restart cTrader.
Update: Building the same new source renamed as another solution configured for and using Visual Studio 2019 makes the same (but differently named) indicator just reload, no problems, on either 4.9.2 or 5.0.40
(To make the 2019 .net4 version: I copied the 2022 .net6 indicator's folder, rename the inner folder too [I added suffix _2019net4], made the long winded .cproj file by editing a copy of a genuine old indicator, added & edited a Properties/AssemblyInfo.cs from same place & an edited copy of its .sln, then opened that in 2019 for a rebuild.) (To switch between 4.9.2 & 5.0.40: I see 2 folders in x:\Users\…\AppData\Local\Spotware\cTrader with long hex names - one came from installing ICMarket's download & contains 4.9.2, one came from downloading from Spotware and contains 5.0.40 [having auto updated from 5.4.39 & still has 2 inner folders but only the cTrader.exe directly in the 2 hex folders will run, bringing up either 4.9.2 or 5.0.40 (not the hidden-by-update 5.0.39), or can run both at same time]).
The OnException method was designed to inform developer that something is wrong in the algo. It is not supposed to be used in the execution flow of the algo. The order of execution of the OnException is not guaranteed and can be changed later. If you want to handle exceptions in predicted way you should use try catch {} blocks explicitly and do not rely on the OnException handler.
Best regards,
Panagiotis
Fair enough, for Indicators possibly, although if a Robot relies on them they need the same fault tolerance. Does it work differently for Robots - reading this https://help.ctrader.com/ctrader-algo/fault-tolerance/ it presents OnException as if it can take the place of individual error handling: “you can also customise how your algos react to certain exceptions, or overwrite the default fault tolerance behaviors entirely. To do so, use the OnException() method. It acts as the dedicated handler for any unhandled exceptions.”
RE: RE: OnException for an an error in Initialize of an Indicator appears to run after all the history Calculate calls
Did you see the same - it's as if, when Initialize runs, the 200 history calls to Calculate are already on whatever .NET scheduling queue c# uses, and any unhandled errors (i.e. without a Try/Catch) result in OnException calls aded to the end of the queue, whereas one might expect OnException to at least run in front of all pre-scheduled stuff, or ideally as an interrupt to the current task.
Can you share a code example so that we can understand the issue?
Best regards,
Panagiotis
Try using the demonstator below: Clear the Trade Chart's Log after starting this with the defaults (which is no exceptions & display a green line .002 above the highs). Then click its Properties or right click the line, and change ‘Exception In Init?’ to Yes. The display will show Highs without the offset added (because the offset isn't copied from the parm until after the error point). Click ok to get rid of the parameter window so you can see the log. On my system the ‘OnException:’ messages don't appear until after all the history Calculates. Similarly, if I instead set ‘Exception In Calc’ to say 1140 (having seen there were 1150 history bars in the earlier log) then the OnException log for that doesn't appear until after all the history Calculates, ie around 1150 (visible on the screen because the default is to leave the indicator Result below Low, rather than above High, for Calculate calls that have exceptions (can make all of them fail by specifying -1 for ‘Exception In Calc’, or only all calls startinf at the 1140th by setting -1140).
Same happens on Backtesting chart, with the indicator added to an already complete backtest. The original place I noticed this was with an Indicator used by a Robot in Backtesting - in that case, the OnException happens after the default 200-bar history has been run through Calculate, i.e. when the (backtest) Server.Date as seen by the Robot is at the start date of the backtest.
As an aside, why does the display line disappear if its IndicatorDataSeries is explicitly CreateDataSeries'ed? (the ‘call CreateDataSeries in Init?’ parm stuff). I was originally doing that in Initialize in another indicator in order to Print its .Count (even though the values would get overwritten later by Calculate) which - the use of name.Count in Initialize without a prior CreateDataSeries - causes an exception (that's what started all this!)
using System; using System.Collections.Generic; using System.Linq; using System.Text; using cAlgo.API; using cAlgo.API.Collections; using cAlgo.API.Indicators; using cAlgo.API.Internals;
namespace cAlgo { [Indicator(IsOverlay = true, AutoRescale = false, AccessRights = AccessRights.None)] public class mjsDemo : Indicator { [Parameter("Offset to add to High", DefaultValue = "0.002")] public double offsetParm { get; set; } [Parameter("Exception in Init?", DefaultValue = "false")] public bool doExceptionInInit { get; set; } [Parameter("Exception in Calc # (0=never 3=third etc or -n = all starting at n)", DefaultValue = "0")] public int doExceptionInCalc { get; set; } [Parameter("call CreateDataSeries in Init?", DefaultValue = "false")] public bool doCreateDataSeries { get; set; } [Output("Main")] public IndicatorDataSeries Result { get; set; } double offset = 0; string whereAreWe = "nowhere"; protected override void Initialize() { Print("Initialize: started"); whereAreWe = "Initialize"; // or System.Reflection.MethodBase.GetCurrentMethod().Name; Print("Initialize: whereAreWe=" + whereAreWe); if (doExceptionInInit) { Print("Initialize: throw exception next"); throw new DivideByZeroException(); } Print("Initialize: copy offsetParm to offset next"); offset = offsetParm; Print("Initialize: offset=" + offset); if (doCreateDataSeries) { Print("Calculate: CreateDataSeries next"); Result = CreateDataSeries(); Print("Calculate: CreateDataSeries done"); } whereAreWe = "nowhere"; Print("Initialize: ending"); } int countCalcs = 0; public override void Calculate(int index) { Print("Calculate: started index=" + index + " Bars[index].OpenTime=" + Bars[index].OpenTime + " offset=" + offset); if (whereAreWe != "nowhere") Print("Calculate: not nowhere so OnException hasn't run yet after an error in... whereAreWe=" + whereAreWe); whereAreWe = "Calculate" + index; // or System.Reflection.MethodBase.GetCurrentMethod().Name + index; Print("Calculate: whereAreWe=" + whereAreWe); countCalcs++; Result[index] = Bars[index].Low - offset; // will be overwritten if no exception Print("Calculate: temp Result[index]=" + Result[index]); if (countCalcs == doExceptionInCalc || (doExceptionInCalc < 0 && countCalcs > -doExceptionInCalc)) { Print("Calculate: throw exception next because doExceptionInCalc=" + doExceptionInCalc + " and countCalcs=" + countCalcs); throw new DivideByZeroException(); } Result[index] = Bars[index].High + offset; Print("Calculate: offset Result[index]=" + Result[index]); whereAreWe = "nowhere"; Print("Calculate: ending index=" + index); } protected override void OnException(Exception e) { Print("OnException: started exception=" + e); Print("OnException: last set whereAreWe=" + whereAreWe); Print("OnException: What can we do in here if history calcs are done already?"); Print("OnException: Better to put try/catch around Init logic?"); Print("OnException: copy offsetParm to offset next"); offset = offsetParm; Print("Initialize: offset=" + offset); whereAreWe = "nowhere"; Print("OnException: ending"); } } }
martins
01 Oct 2024, 15:47
( Updated at: 01 Oct 2024, 17:52 )
RE: Backtest - same code gets different trade results by changing end date
Hi, I've jusy spent a few hours trying to debug why a cBot logic change altered the trade pattern, but couldn't use the feature of clicking on the yellow balance line, or a trade in the history, to redraw the upper chart with the price & trades, because (I think) you can only go back a 1000 or 2000 trades from the end (is that right?) - so I needed to shorten the backtest period in order to find the relevant part of the chart that matched the history.
BUT, because of the 'feature' mentioned in this forum item, the equity after the early trades was completly different (due to, as I now know, it using currency conversion rates from different end dates) so the trades soon became completly different too - in other words I couldn't easily find the relevant parts of the longer before & after charts by shortening the period of backtest. The fact that the program change hadn't actually caused a difference in early trades was additionally confusing - it made me wonder whether the change was in effect or not!
Is there any way of avoiding this effect - say, by using the beginning date for currency rates (since you'd expect trades to alter with a different start date anyway), or some specified date, or even better when the currency pair actually contains the currency rate needed (eg GBPUSD with an account in GBP) then use the proper dynamic rate?
(I suppose another way would be to make cBot decisions based on some sort of overall pips*volume profit measure, to avoid the arbitary exchange rate, but that seems overkill! [and wouldn't include commission or swap])
I suppose another, easier, way, using cTrader as it is, would be to have a cBot parameter to say if/when to stop trading earlier than the backtest end date (using the latter to set the same currency rate and the parameter to control the number of trades or early end date), so there are few enough trades to allow the chart scrolling to work from the yellow balance & the history. BTW, what is the limit for that?
there's a hole in the bucket somewhere! I'm running 4.9.2 and was originally asking about info on the website not info embedded within the product, so…
Where are all the Release Notes - cannot find any between 4.8.30 & 5.0.22 so don't know what's changed since 4.9.2
Thanks for your suggestions but we disagree with maintaining multiple versions of documentation. Old code does not need to be maintained but needs to be updated. Obsolete methods are only supported so that developers have enough time to update their obsolete code without service interruptions. New development is not supported. Therefore we do not plan to make it easy for people not to update their code.
Best regards,
Panagiotis
OK, thank you for your replies on this. Hopefully you understand I wasn't really suggesting “maintaining” the whole old doc, as in having to review or edit it forever, I was merely suggesting either an archive area with complete as-is old doc (ie without relying on internet archive wayback), OR an easy-to-find set of migration docs, issued at the time of the change but to be considered an appendix of the current doc, on how to update from a deprecated way to a new way. Perhaps just an area with all the “what's new in release x” notes would do.
My main point was to suggest the information needed in order to comply with your assertion “Old code does not need to be maintained but needs to be updated” should be somewhere within the official current documentation, and, not only available by searching the internet or interpreting warning compile-time messages or finding old forum or blog items for items such as https://ctrader.com/forum/ctrader-blog/22440/
(My usage of the word “maintain” includes making changes for your “needs to be updated” so I wouldn't [pedantically] agree with “Old code does not need to be maintained”!)
More philosophically: without official information on how old code needs to be updated, there is no support for old code, which effectively means there is no real support for current code because the customer can't trust that a current feature they've used might not become old and without migration information ‘next week’.
Hi martins,
without official information on how old code needs to be updated, there is no support for old code, which effectively means there is no real support for current code because the customer can't trust that a current feature they've used might not become old and without migration information ‘next week’.
For obsolete classes and members you should get a message indicating what you should use instead. See below
Indeed. I was tending to overlook that fact, and accept that issuing warning hint messages does cover the migration aspect. [note to self: must really stop putting off actioning all the warning messages I've been ignoring!] Thanks again.
Clearly that archive may document API features that are deprecated or removed, and in any case, for ‘line’ at least, has identical information to the current doc albeit in a different format. I had a similar query a few days ago, and later remembered it might be there. Only back to 2019 though, whereas I was looking for older :(
You can find release notes for major releases in What's New section
Ok, thanks. I note What's New from cTrader Web has Release numbers, whereas Desktop appears not to, was that deliberate, or perhaps the Web version I'm looking at is newer than my Desktop v4.9.2 and the later versions have the numbers. Do changes & enhancements to the cBot programming API of Automate / Algo appear there too, if not where?
Also, how would I see equivalent information for a version later than the one I have?
And finally, I'm confused by the different cTrader platform names, in particular cTrader Desktop vs cTrader Automate. All the version of Desktop I've used, 3.x to 4.9, have the Automate option for coding (directly or in Visual Studio), and for running, C# automated trading cBots and Backtesting & Optimization, so are these in fact the same thing?
Thanks for your suggestions but we disagree with maintaining multiple versions of documentation. Old code does not need to be maintained but needs to be updated. Obsolete methods are only supported so that developers have enough time to update their obsolete code without service interruptions. New development is not supported. Therefore we do not plan to make it easy for people not to update their code.
Best regards,
Panagiotis
OK, thank you for your replies on this. Hopefully you understand I wasn't really suggesting “maintaining” the whole old doc, as in having to review or edit it forever, I was merely suggesting either an archive area with complete as-is old doc (ie without relying on internet archive wayback), OR an easy-to-find set of migration docs, issued at the time of the change but to be considered an appendix of the current doc, on how to update from a deprecated way to a new way. Perhaps just an area with all the “what's new in release x” notes would do.
My main point was to suggest the information needed in order to comply with your assertion “Old code does not need to be maintained but needs to be updated” should be somewhere within the official current documentation, and, not only available by searching the internet or interpreting warning compile-time messages or finding old forum or blog items for items such as https://ctrader.com/forum/ctrader-blog/22440/
(My usage of the word “maintain” includes making changes for your “needs to be updated” so I wouldn't [pedantically] agree with “Old code does not need to be maintained”!)
More philosophically: without official information on how old code needs to be updated, there is no support for old code, which effectively means there is no real support for current code because the customer can't trust that a current feature they've used might not become old and without migration information ‘next week’.
Thanks for your suggestions but we disagree with maintaining multiple versions of documentation. Old code does not need to be maintained but needs to be updated. Obsolete methods are only supported so that developers have enough time to update their obsolete code without service interruptions. New development is not supported. Therefore we do not plan to make it easy for people not to update their code.
Best regards,
Panagiotis
OK, thank you for your replies on this. Hopefully you understand I wasn't really suggesting “maintaining” the whole old doc, as in having to review or edit it forever, I was merely suggesting either an archive area with complete as-is old doc (ie without relying on internet archive wayback), OR an easy-to-find set of migration docs, issued at the time of the change but to be considered an appendix of the current doc, on how to update from a deprecated way to a new way. Perhaps just an area with all the “what's new in release x” notes would do.
My main point was to suggest the information needed in order to comply with your assertion “Old code does not need to be maintained but needs to be updated” should be somewhere within the official current documentation, and, not only available by searching the internet or interpreting warning compile-time messages or finding old forum or blog items for items such as https://ctrader.com/forum/ctrader-blog/22440/
(My usage of the word “maintain” includes making changes for your “needs to be updated” so I wouldn't [pedantically] agree with “Old code does not need to be maintained”!)
Obsolete documentation has been removed and obsolete classes are not documented, they are kept for backward compatibility only.
Indeed links to types would be helpful but you can still easily search them on the search bar.
Best regards,
Panagiotis
Making old documentation unavailable is a serious reliability issue for the platform - for instance how is a new programmer supposed to know how to maintain an old cBot or to know what the old API does in order to migrate it to the new?? And why should an ‘old’ programmer have to rely on memory in order to similarly maintain it?
And one might wonder what other undocumented features are in the API! I wonder what's going to happen after ‘cTrader Automate API’ is out, will the Algo API doc disappear?
This is not good enough - old doc, especially for APIs you still support it, needs to be available somewhere, at least in an archive area or something. I could point out there are some forum items, & even cBot examples in the current doc, that use the old methods.
Publishing doc as one pdf would be one way to achieve this long term availability , equivalent to a printed manual that can be referred to for ever. Otherwise you seem to be implying the only way to see old doc is to have downloaded the whole doc website a couple of years ago and host it locally. Traditional software companies keep their archived documentation - you can find what IBM API did 50 years ago even if enhanced or different now, or a 30-year old Windows 3.1 win32 API, or old Linux versions etc.
If an API is actually removed (not just deprecated) there at least needs to be migration doc on how to convert to the ‘new way’ (which to be complete would need to include doc on the ‘old way’ anyway!).
Perhaps the simplest solution nor now is to reinstate the old documentation, in an area clearly marked archive & not to be used for new cBots.
Having written “the only way to see old doc is to have downloaded the whole doc website a couple of years ago” I remembered the Internet Archive, and sure enough some old-format doc IS there!
A few dates are available, all very similar eg https://web.archive.org/web/20200811163336/https://ctrader.com/api/reference/bar but not old enough to have MarketSeries, which as I understand from Spotware's 2019 blog re ‘New Features in cTrader Automate API 3.7’ at https://ctrader.com/forum/ctrader-blog/22440/ was exactly equivalent to (a subset of) the Bars object, with the name of each of the several DataSeries within MarketSeries renamed, MarketSeries.Open becoming Bars.OpenPrices etc. The newer Bars object also provide access to a (single) collection/array of Bar structures [via Bars.Last(n) or Bars.LastBar] each of which has a set of property values having the same names as the original (multiple) DataSeries in MarketSeries, ie Bars.Last(2).Open & Bars.Last(2).Low etc.
I've seen the following 3 statements produce identical results (mjsWriteLine just outputs the text to an external log file that gets auto renamed when a backtest ends, to include some of the stats in the filename, and index is always Bars.Count-2 or less to avoid incomplete timesteps):
I still think it would help if there were a reference to MarketSeries in the current doc, rather than having to search around to find the blog item & other references.
“This post awaiting modaration.” - moderation! (e)
Obsolete documentation has been removed and obsolete classes are not documented, they are kept for backward compatibility only.
Indeed links to types would be helpful but you can still easily search them on the search bar.
Best regards,
Panagiotis
Making old documentation unavailable is a serious reliability issue for the platform - for instance how is a new programmer supposed to know how to maintain an old cBot or to know what the old API does in order to migrate it to the new?? And why should an ‘old’ programmer have to rely on memory in order to similarly maintain it?
And one might wonder what other undocumented features are in the API! I wonder what's going to happen after ‘cTrader Automate API’ is out, will the Algo API doc disappear?
This is not good enough - old doc, especially for APIs you still support it, needs to be available somewhere, at least in an archive area or something. I could point out there are some forum items, & even cBot examples in the current doc, that use the old methods.
Publishing doc as one pdf would be one way to achieve this long term availability , equivalent to a printed manual that can be referred to for ever. Otherwise you seem to be implying the only way to see old doc is to have downloaded the whole doc website a couple of years ago and host it locally. Traditional software companies keep their archived documentation - you can find what IBM API did 50 years ago even if enhanced or different now, or a 30-year old Windows 3.1 win32 API, or old Linux versions etc.
If an API is actually removed (not just deprecated) there at least needs to be migration doc on how to convert to the ‘new way’ (which to be complete would need to include doc on the ‘old way’ anyway!).
Perhaps the simplest solution nor now is to reinstate the old documentation, in an area clearly marked archive & not to be used for new cBots.
Trying to transfer cBots & indicators development from Windows 7 to Windows 10. Hadn't started cTrader on the Win 7 for a few months, so first change was the automatic upgrade - Win 7 cTrader upgraded itself and Win 10 new install are both now at version 4.2.22.8457.
The builds still complete properly on the Win 7 system, but hang on Win 10.
What have I missed in "just" moving from Win 7 to Win 10?
It seems YOU HAVE TO RUN a copy of AN OLD PRE-4.2 cTrader at least ONCE ON THE NEW PC (just to the point of it displaying its login window is enough) BEFORE YOU CAN BUILD any UNCHANGED Visual Studio solutions or PROJECTS that have been COPIED FROM PRE-4.2, cAlgo.API based systems. Because I'd installed a fresh download on Win 10, I'd only ever run 4.2, never 4.1 or older, and VS2019 was hanging presumably looking for it. I found a copy of 4.1.11.49761 on the Win 7 system in /User/.../AppData/Local/Apps/2.0/??1/??2/xtrader_7ef.../cTrader.exe (the two ?? look like random 8.3 allcaps names so probably vary). I copied the whole ??2 folder and renamed it on Win 10, then ran the copied cTrader.exe - the build of an unchanged old cAlgo cBot solution then build successfully in Virtual Studio 2019 on Win 10. Running the old cTrader just once seems to be enough.
So the fact the new system was Win 10 was irrelevant - the salient point is it was a system that had never run an old version of cTrader that didn't use cTrader.Automate
The clue to this resolution was the initial message produced by a VS build on the old (Win 7) system:
Application: C:\Users\...\AppData\Local\Apps\2.0\XJNZ....\92J...\xtrader_7ef...\cTrader.exe, version: 4.1.11.49761
Compile project: C:\Users\...\Documents\cAlgo\Sources\Robots\name\name\name.csproj
A similar message now appears on the new (Win 10) system when building these unchanged projects. However, I presume it won't be too hard to create new versions for ctrader.Automate & .NET 6 by copying just the main source to cTrader 4.2 and using 'Edit in Virtual Studio' to create a simple version of the project and then adding the other parts of extra source etc back in.
How do you turn off autoscroll for the backtest chart - it doesn't seem to have free chart mode.
I wanted to scroll back through a test without the vertical scale moving about. Just having it not automatically re-enlarge after I manually shrink the vertical scale would help, perhaps automatically move it up or down to fit would be ok, but without rescaling, so if I've shrunk it enough it won't alter even if scroll horizontally through whole test.
Marvellous, yes that's it, thanks. Seems to operate even more separately than I was expecting, in that it went through a mini install process when creating the 2nd profile, and each profile downloads its own backtest data rather than use what was already downloaded for the other - but then you might well want it to do that if you fiddle with it using the program in here...
...meanwhile, we have to put all Chart.xxx calls inside if statements such as
if (RunningMode != RunningMode.Optimization)
{
Chart.xxx(...);
Chart.yyy(...);
}
In order to be as robust as an alterable Position.Label wouldn't the info in this Order class have to be stored in a file - otherwise only information that can be determined from the positions themselves could be reconstructed after cTrader restarted for whatever reason, for instance after pc crash or power outage.
martins
14 Nov 2024, 17:28 ( Updated at: 15 Nov 2024, 00:28 )
RE: How is the new EntryPrice (& thus Pips etc) of a modified or partially closed Position calculated?
PanagiotisCharalampous said:
Ok, thanks, that's helpful. I can see from logging that when the volume of a position is INCREASED the calculation of its new Position.Pips value is exactly:
(oldPips * oldVol - spreadAsPips * increaseInVol) / newVol
which is correctly distributing the pips on the old portion plus the immediate pip loss of the new portion (due to spread) across the new larger volume (and so the EntryPrice will be that many pips from the current price and represent the weighted average). Rounding of the calculation seems usually to the nearest 0.1 pip but sometimes goes the other way, possibly to correct for accumulated rounding error. That's all fine.
HOWEVER, I'm seeing the remaining portion of a position after a REDUCTION in volume ALSO has its Position.Pips altered. Why is that?
Possibly the position was not combined really (in the live server or backtest memory) but rather kept as a collection of parts from each modification that increased volume, so that when it is later reduced some specific part is closed, in a LIFO or FIFO order or some other rule? Is this broker driven?
So maybe ModifyPosition does not really modify a position in the sense of ending up with one homogeneous position with a single EntryPrice & Pips profit? Can't brokers running cTrader handle merging modification deals into one net holding?
If not, please could the doc say so, and how do we know what the separate parts are so we can predict partial closing results (without laboriously keeping track of all modifications)? Is there any information in a Position that can tell a cBot the position's stats will not react in a predictable way if later PARTIALLY closed ('predictable' meaning Entry & Pips stay unchanged, profit prorata etc)?
I'm coming to the conclusion it's not good to mix increasing and decreasing volume via ModifyPosition; one or the other yes, predictable, but not both in the same cBot if it's basing decisions on Position.Pips or Account.UnrealizedProfit, or on almost anything other than Equity.
Thanks.
Update re "laboriously keeping track": not that hard, but involves keeping ‘account state’ data outside the cTrader account, like in a local file or cloud, not self-contained in the positions - unless perhaps cTrader could add a large Account.Comment field that could store arbitrary data, or make the Positions.Comment modifyable & bigger?? :)
…
modifyDeals.Count=95 i=58 modifyDeals[i].Id=6 modifyDeals[i].Vol=19000 modifyDeals[i].Bid=1.36653 modifyDeals[i].Ask=1.36656
modifyDeals.Count=95 i=59 modifyDeals[i].Id=6 modifyDeals[i].Vol=13000 modifyDeals[i].Bid=1.36404 modifyDeals[i].Ask=1.36407
modifyDeals.Count=95 i=60 modifyDeals[i].Id=5 modifyDeals[i].Vol=4000 modifyDeals[i].Bid=1.36399 modifyDeals[i].Ask=1.36402
modifyDeals.Count=95 i=61 modifyDeals[i].Id=6 modifyDeals[i].Vol=-230000 modifyDeals[i].Bid=1.3605 modifyDeals[i].Ask=1.36053
modifyDeals.Count=95 i=62 modifyDeals[i].Id=5 modifyDeals[i].Vol=-230000 modifyDeals[i].Bid=1.3605 modifyDeals[i].Ask=1.36053
modifyDeals.Count=95 i=63 modifyDeals[i].Id=6 modifyDeals[i].Vol=-77000 modifyDeals[i].Bid=1.36007 modifyDeals[i].Ask=1.3601
modifyDeals.Count=95 i=64 modifyDeals[i].Id=5 modifyDeals[i].Vol=-77000 modifyDeals[i].Bid=1.36007 modifyDeals[i].Ask=1.3601
modifyDeals.Count=95 i=65 modifyDeals[i].Id=6 modifyDeals[i].Vol=10000 modifyDeals[i].Bid=1.35909 modifyDeals[i].Ask=1.35912
modifyDeals.Count=95 i=66 modifyDeals[i].Id=5 modifyDeals[i].Vol=19000 modifyDeals[i].Bid=1.36651 modifyDeals[i].Ask=1.36654
modifyDeals.Count=95 i=67 modifyDeals[i].Id=5 modifyDeals[i].Vol=10000 modifyDeals[i].Bid=1.36892 modifyDeals[i].Ask=1.36895
modifyDeals.Count=95 i=68 modifyDeals[i].Id=5 modifyDeals[i].Vol=13000 modifyDeals[i].Bid=1.37044 modifyDeals[i].Ask=1.37047
…
struct modifyDeal { // https://stackoverflow.com/questions/33809867/c-sharp-struct-in-a-list
public int Id { get; set; }
public double Vol { get; set; }
public double Bid { get; set; }
public double Ask { get; set; }
public modifyDeal(int id, double vol, double bid, double ask)
{ Id = id; Vol = vol; Bid = bid; Ask = ask; }
}
List<modifyDeal> modifyDeals = new List<modifyDeal>(); // 14nov24
…
var deal = new modifyDeal(position.Id, newVolume - position.VolumeInUnits, Symbol.Bid, Symbol.Ask);
//or deal.Id = position.Id; etc
modifyDeals.Add(deal);
Might be able to extract same info using the History interface possibly (how far back does it go?), but haven't found all the doc about it, for instance where is History.OrderByDescending() other than in the example https://help.ctrader.com/ctrader-algo/references/Trading/History/History/#examples
Later: Actually only one adjustment number per position might need remembering in order to emulate proportional netting when partially closing a position that has been increased earlier - the difference between ‘the proportional Pips or Entry expected before the partial close is done’ and ‘the actual new Pips or new Entry that appears in the Position afterwards’ - so the Bot can apply that offset to later Pips & profit (with opposite adjustment to Balance).
Is there any way of storing a small amount of data per position on the server, for instance a modifyable Comment?
@martins