ORDER_POSITION_ID - sayfa 21

Yeni yorum
 
Mikalas :

...

Ancak bunu emirler aracılığıyla uygulamak istedim (bana kısmen uygulanan bir siparişin birkaç güne "maliyeti" geliyor),

...

Michael ve haklı olarak! Neden uygulamadılar? Net pozisyonları analiz ederken, içerdiği emirleri analiz etmeden yapamayacağınız gerçeğiyle er ya da geç yüzleşeceğinizi anlayın. Bunu size bir ayını bu konuyu incelemeye ayırmamış, bu tırmığı defalarca basmış biri olarak söylüyorum :) Ayrıca, tek bir robot ticaretine sahip değil, aynı anda birkaç robotunuz varsa, yapacaksınız. Ayrıca her robotun toplam pozisyona katkısını da hesaba katmak zorunda ve teminatsız da yapamazsınız. Emir ve bunlara dayalı işlemlerde gerekli tüm bilgiler bulunurken, işlemleri tek bir net pozisyona eşleştirmek, aksine bilgileri geri dönüşü olmayan bir şekilde siler.

Ancak sisteminizi emir ve işlem analizine dayandırırsanız, emirlerin kısmi icrasını da göz önünde bulundurmalısınız. Bunu yapmak için siparişin sanal bir sürümünü oluşturmanız ve yeni anlaşmaların akışını kontrol etmeniz gerekir. Aşağıdaki algoritmaya sahibim:

1. Yeni bir anlaşma geldi (HistoryDealsTotal() sayacı değişti).

2. Bu anlaşma herhangi bir sipariş tarafından başlatıldıysa, tek bir anlaşma içeren yeni bir sipariş oluşturun (COSipariş* sipariş = yeni Sipariş(anlaşma)).

3. Ardından, halihazırda mevcut sanal siparişler listemizde aynı tanımlayıcıya sahip bir sipariş ararız. Böyle bir sipariş bulunursa, oluşturulan siparişin anlaşmasını bulunanın anlaşmaları ile birleştirir ve özelliklerini günceller ve oluşturulan siparişi sileriz. Aynı sipariş henüz listede yoksa listeye eklemeniz yeterli.

Böylece sistem tamamen deterministiktir. Her yeni işlemde, sanal emrimizin durumu değişecektir ve gerçek emrin uygulamada takılıp kalması veya geçmişe taşınmış olması önemli değil, onu her zaman sistemimizde fiilen yürütülen hacimde göreceğiz.

 
Contender :
Ve pozisyonu kapatırsanız , ancak siparişin doldurulmamış kısmını çıkarmazsanız, başka bir pozisyon açar (veya değiştirir)?

İyi soru!

Sipariş geçerliyse, tarihte yoktur (bu kesin olarak doğrulanır),

ve geçerli bir emir elbette başka bir pozisyon açabilir, ancak

Kısmen tekrar çalıştırılırsa, ORDER_POSITION_ID ona atanmaz.

Yani ORDER_POSITION_ID sadece geçmişte görülebilir.

 
C-4 :

Evet borsada bu oluyor ve bu durumlar dikkate alınmalı. Bu, limit emirlerinin temel dezavantajlarından biridir.

Örneğinizde, değiştirebileceğinizi düşünüyorum:

Üzerinde:

Çünkü tüm alım satım işlemleri bir çeşit emirle başlatılır.

Hayır, yapamazsınız, çünkü takasta işlemler var, ancak biletleri yok (veya daha doğrusu, bilet = 0 ),

ama bir fiyatı ve türü var (AL ve SAT) ve tabii ki GİRİŞ ve ÇIKIŞ :(

 
C-4 :

Michael ve haklı olarak! Neden uygulamadılar? Net pozisyonları analiz ederken, içerdiği emirleri analiz etmeden yapamayacağınız gerçeğiyle er ya da geç yüzleşeceğinizi anlayın. Bunu bir ayını bile bu konuyu araştırmaya ayırmamış, bu tırmığı defalarca basmış biri olarak söylüyorum :) Ayrıca tek bir robot ticaretine sahip değil, aynı anda birkaç robotunuz varsa, yapacaksınız. Ayrıca her robotun toplam pozisyona katkısını da hesaba katmak zorunda ve teminatsız da yapamazsınız. Emir ve bunlara dayalı işlemlerde gerekli tüm bilgiler bulunur ve işlemlerin tek bir net pozisyona eşleştirilmesi, aksine bilgileri geri dönüşü olmayan bir şekilde siler.

Ancak sisteminizi emir ve işlem analizine dayandırırsanız, emirlerin kısmi icrasını da göz önünde bulundurmalısınız. Bunu yapmak için siparişin sanal bir sürümünü oluşturmanız ve yeni anlaşmaların akışını kontrol etmeniz gerekir. Aşağıdaki algoritmaya sahibim:

1. Yeni bir anlaşma geldi (HistoryDealsTotal() sayacı değişti).

2. Bu anlaşma herhangi bir sipariş tarafından başlatıldıysa, tek bir anlaşma içeren yeni bir sipariş oluşturun (COSipariş* sipariş = yeni Sipariş(anlaşma)).

3. Ardından, halihazırda mevcut sanal siparişler listemizde aynı tanımlayıcıya sahip bir sipariş ararız. Böyle bir sipariş bulunursa, oluşturulan siparişin anlaşmasını bulunanın anlaşmaları ile birleştirir ve özelliklerini günceller ve oluşturulan siparişi sileriz. Aynı sipariş henüz listede yoksa listeye eklemeniz yeterli.

Böylece sistem tamamen deterministiktir. Her yeni işlemde, sanal emrimizin durumu değişecektir ve gerçek emrin uygulamada takılıp kalması veya geçmişe taşınmış olması önemli değil, onu her zaman sistemimizde fiilen yürütülen hacimde göreceğiz.

Vasily, her şeyi uyguladım (senin gibi değil ama fena da değil), sadece arama süresini kısaltmak istedim...
 
Serj_Che :

Sorun çözüldü, ilişki çözüldü)

İlgili bir soru geldi:

Özelliklerini görüntülemek için biletlesipariş seçmek çok sakıncalıdır, çünkü siparişin tarihte veya piyasada nerede olduğu önemli değildir ve bilet değişmeyecektir.

Burada ve orada bir sipariş aramanız gerektiği ortaya çıktı.

MT4 dörtlüdeki gibi yapmak daha kolay olmayacaktı, eğer bir sipariş seçilirse, nerede olduğu önemli değil.

MT4 yardımından:

Kim düşünüyor?

PS Umarım Mikhail yenilerini üretmemek için şubenin devam etmesine karşı değildir?


Mikalas :

P-4, tartışmanın yapıcı bir şekilde ilerlemesine çok sevindim!

Bu nedenle, kârımın ne olduğunu (örneğin bir ay içinde) bilmek için pozisyonun "net" fiyatına ihtiyacım var.

...

İşlevde (şimdi kullanıyorum):

...

Soru alakalı, genel olarak MetaTrader5 API gerçekten oldukça düşük seviyeli. Ama... borsada işlem yapmanın birçok nüansı vardır: çok sayıda işlem içeren bir emrin uygulanması, işlemleri net bir pozisyonla eşleştirme ve takas yoluyla transfer etme, çok sayıda aracılık işlemi vb. Bu nedenle, MetaTrader5 API'si (ve MT5'in kendisi), herhangi bir değişim terminalinin olması gereken şeydir.

Başka bir soru da, API'sinin MQL5 ile yazılmış yüksek seviyeli bir paketleyiciye sarılabileceği ve bu sayede alt seviye MT5 fonksiyonlarının kullanılabileceğidir. Benim paketimde, Mikhail'in kârı hesaplama görevi sadece şöyle görünmekle kalmayacak:

 for ( int i = 0 ; i < TransactionsTotal(); i++)
{
     if (TransactionSelect(i, SELECT_BY_POS, MODE_TRADES))
    {
         ENUM_TRANS_TYPE trans_type = TransactionType();
         if (trans_type == TRANS_HEDGE_POSITION)
         {
               if (HedgePositionGetInteger(HEDGE_POSITION_MAGIC) != myMagic) continue ;   // Работаем только со своими позициями.
               if (HedgePositionGetString(HEDGE_POSITION_SYMBOL) != Symbol ()) continue ; // Работаем только с позициями на своем инструменте.
               double profit = HedgePositionGetDouble(HEDGE_POSITION_PROFIT_POINTS); //Профит в пунктах
               double currency = HedgePositionGetDouble(HEDGE_POSITION_PROFIT_CURRENCY); //Профит в валюте депозита.
               double price_open = HedgePositionGetDouble(HEDGE_POSITION_PRICE_OPEN); //Фактическая цена открытия позиции без клирингов и пр. изменений.
               double sl = HedgePositionGetDouble(HEDGE_POSITION_SL); //Узнаем уровень стоп-лосса позиции, если он есть, если нет - вернет нормализованный 0.0.
               if (HedgeOrderSelect(ORDER_SELECTED_INIT)) //Выбираем ордер, открывающий текущую позицию.
              {
                 int deals = HedgeOrderGetInteger(HEDGE_ORDER_DEALS_TOTAL); //Получаем количество сделок, открывающего ордера.
              }
               // Ну и так далее...
         }   
    }
}
 
Mikalas :

Hayır, yapamazsınız, çünkü takasta işlemler var, ancak biletleri yok (veya daha doğrusu, bilet = 0 ),

ama bir fiyatı ve türü var (AL ve SAT) ve tabii ki GİRİŞ ve ÇIKIŞ :(

Haklısın

O zaman senin için hüzün.

 
Mikalas :
Vasily, her şeyi uyguladım (senin gibi değil ama fena da değil), sadece arama süresini kısaltmak istedim...
Bu arada robotlarınızın çok yönlü girdileriyle nasıl başa çıkıyorsunuz? Sonuçta , bir uzmanın pazara girişi , başka bir robotun konumundan çıkış olabilir.
 
Mikalas :

İyi soru!

Sipariş geçerliyse, tarihte yoktur (bu kesin olarak doğrulanır),

ve geçerli bir emir elbette başka bir pozisyon açabilir, ancak

Kısmen tekrar çalıştırılırsa, ORDER_POSITION_ID ona atanmaz.

Yani ORDER_POSITION_ID sadece geçmişte görülebilir.

İşte başka bir pusu. Bu emrin gerçekleştirilen işlemlerinin bir kısmı bir pozisyona, diğer kısmı ise başka bir yeni pozisyona ait olacaktır. O zaman soru şu ki, er ya da geç tarihe geçtiğinde ona hangi konum tanımlayıcısı atanacak?
 
C-4 :
Bu arada robotlarınızın çok yönlü girdileriyle nasıl başa çıkıyorsunuz? Sonuçta , bir uzmanın pazara girişi , başka bir robotun konumundan çıkış olabilir.
Kavşaklarım yok.
 
C-4 :
İşte başka bir pusu. Bu emrin gerçekleştirilen işlemlerinin bir kısmı bir pozisyona, diğer kısmı ise başka bir yeni pozisyona ait olacaktır. O zaman soru şu ki, er ya da geç tarihe geçtiğinde ona hangi konum tanımlayıcısı atanacak?

Tamamen doldurulmuş bir emir, açtığı veya değiştirdiği pozisyonun kimliğini alacaktır.

Ama sadece tarihte mevcut olacak ( ID ).

1...1415161718192021
Yeni yorum
Neden: