kdcp999
11 Feb 2017, 23:20

why include commission in volume

Hello, Thanks for this btw.

I may be misunderstanding something here:

 

            // Add the stop loss, commission pips and spread to get the total pips used for the volume calculation.
            double totalPips = StopLoss + CommissionPips + Symbol.Spread;

But why include commission in you volume to trade. You are going to be charged that commission anyways. So if you make a winning trade you cover the commission loss along with the profits.

But if you lose then you still pay the commission for entering and exiting along with the added value you lose for including the commission rati into your volume level.

Could you please clarify - I appreciate that this is a very old post. Any advice would be great thanks.

---

@kdcp999

kdcp999
07 Feb 2017, 17:03

Yes I see, thank you for clearing that up. Much appreciated.

---

@kdcp999

kdcp999
06 Feb 2017, 22:00

Yes, it is.

---

@kdcp999

kdcp999
29 Oct 2016, 21:18

RE:

kdcp999 said:

Currently I have to use Visusal studio's autocomplete to figure out what the types are the values being returned by many of your functions.

The documention is not very usefull aside from the most simple of operations and examples. Even then the specificatoin is to simple.

Random example: /api/reference/indicators/ichimokukinkohyo

None of the values listed in the documentation above when clicked on actually state the 'type' of those values?
Nor is there an explanation as to what those values mean and at least on same basic principle - how they are calculated comapred to curreent price.  

Tbf cAlgo documention is one of the biggest downfalls if the entire API. 

Devil's in the details - would be nice if you folks coudl fix this.

** of the entire API

** could fix this.

---

@kdcp999

kdcp999
27 Oct 2016, 00:51

Got it, I do blame the documentation though.


Instead of setting your own constructor - You just define the args you pass to the "GetIndicattor" method as public prooperties on the class so they somehow are matched and get instatiated becasue you have explicitly set them as "parameters" in the indicator class.  Go figure.

Support - Please  open source you documentation!  Have people set up pull requests for updates, I am sure consultants for cAlgo would contribute to up their visibility along side poeople like my self. The state of tthe docs is not at all worthy of praise.
MetaQuotes may be a PITA, but their docs are thourough, and well maintained.

---

@kdcp999

kdcp999
09 Oct 2016, 21:48

Hi Thanks for the reply. I am not sure I understand. That method will essentially do exactly the same thing I am doing in my example code. But I must admit I am probably missing something. The very fact that the function you suggested is of type "long" means that my precision value will be truncated. Or in the case of the function your suggested. Rounded down to the nearest whole number i.e 5 instead of 5.34 .. I should be able to make a trade using a volume value of exactly 5.34 lots... Not just whole numbers like 1,2,3...etc Any ideas?

---

@kdcp999

kdcp999
09 Oct 2016, 17:11

RE:

haha you can't edit you own post!  O_O
There is obviously a typo in my example. sorry about that.

The example code should read:

Decimal this_is_a_decimal = 5.34
(long)this_is_a_decimal  == 5  // long types don't have precision 

 

kdcp999 said:

Hi Folks

Building a bot that works with a micro account.

Currently I have an automated lot size calculator. The issue here is as follows:
I have X amount of money equating to 5.34 lots in lot steps of 0.01.
When I convert this to a long type(because the cAlgo API insists volume to be of type long) - I lose the 0.34 lots I wanted to trade. Obviously the cast truncates the precision.

Example:

Decimal this_is_a_decimal = 5.34
(long)this_is_a_decimal  == 5  // long types don't have precision 

But I don't want 5 lots I want 5.34 lots?

Any ideas - Also the "Normalize" method returns a "long" type. Hence no 0.01 precision either.

Thanks 

David

 

---

@kdcp999

kdcp999
09 Oct 2016, 17:11

RE:

haha you can't edit you own post!  O_O
There is obviously a typo in my example. sorry about that.

The example code should read:

Decimal this_is_a_decimal = 5.34
(long)this_is_a_decimal  == 5  // long types don't have precision 

 

kdcp999 said:

Hi Folks

Building a bot that works with a micro account.

Currently I have an automated lot size calculator. The issue here is as follows:
I have X amount of money equating to 5.34 lots in lot steps of 0.01.
When I convert this to a long type(because the cAlgo API insists volume to be of type long) - I lose the 0.34 lots I wanted to trade. Obviously the cast truncates the precision.

Example:

Decimal this_is_a_decimal = 5.34
(long)this_is_a_decimal  == 5  // long types don't have precision 

But I don't want 5 lots I want 5.34 lots?

Any ideas - Also the "Normalize" method returns a "long" type. Hence no 0.01 precision either.

Thanks 

David

 

---

@kdcp999

kdcp999
09 Oct 2016, 17:11

RE:

haha you can't edit you own post!  O_O
There is obviously a typo in my example. sorry about that.

The example code should read:

Decimal this_is_a_decimal = 5.34
(long)this_is_a_decimal  == 5  // long types don't have precision 

 

kdcp999 said:

Hi Folks

Building a bot that works with a micro account.

Currently I have an automated lot size calculator. The issue here is as follows:
I have X amount of money equating to 5.34 lots in lot steps of 0.01.
When I convert this to a long type(because the cAlgo API insists volume to be of type long) - I lose the 0.34 lots I wanted to trade. Obviously the cast truncates the precision.

Example:

Decimal this_is_a_decimal = 5.34
(long)this_is_a_decimal  == 5  // long types don't have precision 

But I don't want 5 lots I want 5.34 lots?

Any ideas - Also the "Normalize" method returns a "long" type. Hence no 0.01 precision either.

Thanks 

David

 

---

@kdcp999

kdcp999
08 Oct 2016, 15:59

---

@kdcp999