Errors, bugs, questions - page 397

[Yedelkin]

TEXX:

Honestly, it's bullshit....

What the fuck do you need a bojan for?

A position is always one; there can be several orders that were involved in forming it, and each order is triggered at a different price. What price should we set relative to the position formed by several orders? The developers have chosen this option. This is the same variant that is used in the banks.

By the way, a leading question: what is the breakeven level for a position formed by several orders?

[[Deleted]]

Yedelkin:

A position is always a single order; there can be several orders which were involved in forming it, and each order is triggered at a different price. What price should be specified in relation to the position formed by several orders? The developers have chosen this option. This is the same variant that is used in the banks.

By the way, a leading question: what is the breakeven level for a position formed by several orders?

Correction - it is rather an average opening price of a position (as an aggregate of all transaction prices) rather than a CU. For a BU, there are at least some swaps to calculate.

[Yedelkin]

Interesting:
Correction - this is more like an average opening price (as an aggregate of all transaction prices) and not a BU. For a Buy, there are at least some swaps to calculate.

You will answer all your questions for TEX :)

[[Deleted]]

Yedelkin:
You will answer all your questions for TEX :)

Of course not, I just wanted to clarify. And in principle, what difference does it make, let it be CU (I often use that term myself in relation to the price of an aggregate position)...

[Yedelkin]

After upgrading to 458 build, one thing came to light. I was able to localise it:

void OnStart()
  {
   short real_index=-1;
   real_index++;
   real_index++;
   real_index++;
   real_index++;
   real_index++;
   if(real_index<0)
     {
      Print(__FILE__," ",__FUNCTION__,": real_index=",real_index,"<0, программа выгружается");
      return;
     }
   Print(__FILE__," ",__FUNCTION__,": real_index=",real_index);
   for(uchar u=0;u<real_index;u++)
      //for(char u=0;u<real_index;u++)   //Если поменять uchar на char - результат тот же.
     {
      Print(__FILE__," ",__FUNCTION__,": uchar u=",u,", real_index=",real_index);
     }
  }

After compilation, a warning appears which causes the for loop statement not to run. XP, 32.

[Aleksandr Chugunov]

Yedelkin:

After upgrading to 458 build, one thing came to light. I was able to localise it:

After compilation, a warning appears which causes the for loop statement not to run. XP, 32.

Yeah, I've had 3 or so of these occurrences when upgrading to 458 build....

I didn't dig, just changed variable types.....

[Alexey Da]

Yedelkin:

After upgrading to 458 build, one thing came to light. Was able to localise it:

After compilation, a warning appears which causes the for loop statement not to run. XP, 32.

Yes, there is an error. We will fix it.

Thanks for the message.

[MONTEGRO]

stringo:

Do you only have local agents?

This situation will be rectified shortly.

build 450. win XP SP3. the optimizer often generates errors during testing, often with agent disconnection (both local and remote):

2011.05.27 15:26:24 Core 1 slow agent failed
2011.05.27 15:26:24 Core 1 connection closed
2011.05.27 15:26:22 Core 2 too slow agent. busy time is 5641 ms. avg time is 1405 ms
2011.05.27 15:26:20 Core 1 too slow agent. busy time is 5625 ms. avg time is 1405 ms.
2011.05.27 15:26:18 Core 2 common synchronization completed
2011.05.27 15:26:17 Core 2 authorized (agent build 450)
2011.05.27 15:26:17 Core 2 connected
2011.05.27 15:26:15 Core 1 common synchronization completed
2011.05.27 15:26:15 Core 1 authorized (agent build 450)
2011.05.27 15:26:15 Core 1 connected

it is practically impossible to work. an hour long optimization turns into a four hour one.

P.S. am i the only one who suffers, and the rest are fine ? or nobody is optimizing ))) ?

[Ilyas]

Yedelkin:

After upgrading to 458 build, one thing came to light. I was able to localise it:

After compilation, a warning appears which causes the for loop statement not to run. XP, 32.

Thanks for the post, the error has been fixed.

[Slava]

MONTEGRO:

build 450. win XP SP3. the optimiser often generates errors when testing, often with the agent disabled (both local and remote):

Actually 458 build has already been released