Şampiyona Katılımcıları için faydalı ipuçları - sayfa 11

Yeni yorum
 
VNIK писал (а):

Şampiyonanın organizatörlerine sorumsuz soru için özür dilerim:

Ödülün vergilendirilmesi sorunu nasıl çözülecek (sonuçta her ödülün miktarı çok büyük):

her kazanan kendisi ödeyecek? (ve hangi oranda?) yoksa merkezi olarak mı kararlaştırılacak? (yani vergiler zaten hesaba katılmış mı?).

Vergiler için ödülün yarısını vermek yazık olur!

Sana katılıyorum, vergilerimi ödemek için ödülünün yarısını verdiğime de üzüleceğim...
Genel olarak, hiç kazanmamak daha iyidir, bu yüzden üzücü değil ...
 
VNIK :

Şampiyonanın organizatörlerine sorumsuz soru için özür dilerim:

Ödülün vergilendirilmesi sorunu nasıl çözülecek (sonuçta her ödülün miktarı çok büyük):

her kazanan kendisi ödeyecek? (ve hangi oranda?) yoksa merkezi olarak mı kararlaştırılacak? (yani vergiler zaten hesaba katılmış mı?).

Vergiler için ödülün yarısını vermek yazık olur!


Evet, ödül kazananlar tüm vergileri kendileri öder - bu, dünya çapındaki ödüller için standart bir uygulamadır.
 
Bu tür siparişlerin kapatılmasının her zaman doğru çalışıp çalışmayacağını hiçbir şekilde test edemiyorum:
 while ( OrdersTotal () > 0 )
   {
      OrderSelect ( 0 , SELECT_BY_POS ) ;
      if ( OrderType () == OP_BUY )       OrderClose ( OrderTicket () , OrderLots () , Bid , 3 , Green ) ;
      else if ( OrderType () == OP_SELL ) OrderClose ( OrderTicket () , OrderLots () , Ask , 3 , Red ) ;
      
      err = GetLastError () ;
      if ( err == 135 || err == 138 ) RefreshRates () ;
   }
Soru şudur: hata kodu 135 veya 138'e eşit değilse bir döngü oluşur mu? Eğer öyleyse, siparişlerin kapatılacağını garanti ederken bundan nasıl kaçınılır?
 
MAEstro :
Bu tür siparişlerin kapatılmasının her zaman doğru çalışıp çalışmayacağını hiçbir şekilde test edemiyorum:
Hata üstüne hata var. 4 hata saydım ve hepsi felaket.
Tavsiye makalesini tekrar okuyun, lütfen.
 
Bu ipuçlarını ezbere hatırlıyorum, ama pek faydası yok gibi görünüyor :(

Döngü hatası kontrolünün büyük ihmali
(Hatalara karşı kontrolüm var, bekleyen siparişler kullanılmıyor veya döngüden çıkmak için hala bir koşul oluşturmam gerekiyor mu? O zaman siparişlerin kapalı olduğu nasıl garanti altına alınabilir? Veya tüm hata kodlarını çözmedim mi?)

OrderSelect üzerinde kontrol eksikliği - eylemde süreç uyumsuzluğu
(evet, Order_Select'in ne döndürdüğünü kontrol etmiyorum! Peki, diyelim ki bu özel durumda false döndürüyorsa, döngü içinde ne değişecek veya ne yanlış olacak? Sıralamayı değiştirmem ama kapatın! )

RefreshRates() yoluyla piyasa ortamını güncelleme işlevini atlama
(Sanırım yenileyeceğim, burada her şey yolunda olmalı)

Belki TÜM siparişleri kapatmak için hazır bir kod parçasına sahipsin? Yayınlarsanız minnettar olurum!

PS, Rosh'un sunduğu http://www.alpari-idc.ru/ru/experts/articles/9.html siparişlerin kapanmasını garanti etmez!
 
Hatta 5 hata:
  1. orderselect sonucu kontrol edilmedi
  2. OrderClose() sonucu açıkça kontrol edilmez
  3. GetLastError(), alım satım işlemleri olmadan çağrılabilir (örneğin, bekleyen bir emirle karşılaştıysanız)
  4. RefreshRates() her zaman çağrılmaz, ancak yalnızca başarısızlıklarda çağrılır - büyük bir hata
  5. listede bekleyen siparişler varsa, %100 döngü
Sonuç olarak: 9 satırda 5 hata var - sadece kodu atın.
 
Renat :
Hatta 5 hata:
  1. orderselect sonucu kontrol edilmedi
  2. OrderClose() sonucu açıkça kontrol edilmez
  3. GetLastError(), alım satım işlemleri olmadan çağrılabilir (örneğin, bekleyen bir emirle karşılaştıysanız)
  4. ...
Sonuç olarak: 9 satırda 5 hata var - sadece kodu atın.
Ve neden tüm bunları rekabet için bir Uzman Danışmana yükleyesiniz? Magazin okumak?
OrderSelect seçmeli ve OrderClose gerekli siparişleri kapatmalıdır.
Ve hiçbir hata olmamalı :-)
Veya müşterinin pahasına :-)
 
Renat писал (а):
Hatta 5 hata:
  1. orderselect sonucu kontrol edilmedi
  2. OrderClose() sonucu açıkça kontrol edilmez
  3. GetLastError(), alım satım işlemleri olmadan çağrılabilir (örneğin, bekleyen bir emirle karşılaştıysanız)
  4. RefreshRates() her zaman çağrılmaz, ancak yalnızca başarısızlıklarda çağrılır - büyük bir hata
  5. listede bekleyen siparişler varsa, %100 döngü
Sonuç olarak: 9 satırda 5 hata var - sadece kodu atın.

Görev: tüm siparişleri %100 garantiyle kapatın
Kısıtlamalar: bekleyen siparişler kullanılmaz

1. Siparişi kapatmanız gerekiyorsa neden sonucu kontrol etmelisiniz? Eğer false döndürürse, while döngüsü kullanıldığı için bir sonraki geçişte kendisine dönecektir.
2. Madde 1'e bakın.
3. Bunun için hata kodları için bir kontrol var
4. Her zaman güncelleme yapıyorsanız, hataları kontrol etmenin bir anlamı yoktur :(
5. Bekleyen sipariş yok

Aramada bulduğum tüm kapanış emirleri örnekleri tek geçişlidir ve yalnızca sunucuda her şey yolundaysa, yeniden fiyat teklifi vb. yoksa çalışır. Ve hepsi, güzel bir anda, herhangi bir siparişi kapatmayacağımız ve iyi uçacağımız gerçeğine yol açıyor ... Yanılıyorsam, düzeltin veya emin olabileceğim bir bağlantı verin. yanlış.

Elbette, kodumun bir döngüye yol açabileceğinin farkındayım, ancak bence bu, ciddi mali kayıplara yol açabilecek siparişi kapatmama riskinden daha iyidir.
Tüm siparişlerin %100 garanti ile kapanması ve döngüye girme ihtimali olmaması daha iyi olsa da sizden almak istediğim kod bu =)

Bekleyen siparişleri bile hesaba katması gereken biraz değiştirilmiş bir kod:
 while ( OrdersTotal () > 0 )
   {
      OrderSelect ( 0 , SELECT_BY_POS ) ;
      if ( OrderType () == OP_BUY )       OrderClose ( OrderTicket () , OrderLots () , Bid , 3 , Green ) ;
      else if ( OrderType () == OP_SELL ) OrderClose ( OrderTicket () , OrderLots () , Ask , 3 , Red ) ;
      else OrderDelete ( OrderTicket ()) ;
      
      RefreshRates () ;
      err = GetLastError () ;
      if ( err != 135 && err != 138 && err != 0 ) break ;
   }

Bir önceki kadar "çılgın" değil mi?
Bu durumda OrderSelect ve OrderClose'u neden kontrol ettiğini hala anlamıyorum?
 
Ne yazık ki, hiç kimse ticaret işlemleri konusunda herhangi bir garanti vermeyecektir. Bu kod öncekinden çok daha iyi.

OrderSelect her zaman kontrol edilmelidir, bu açıkça Faydalı İpuçları'nda belirtilmiştir:
  • OrderSelect üzerinde kontrol eksikliği - eylemde süreç uyumsuzluğu


    Genellikle bir tüccar, programını tek görevli ve benzersiz olarak algılar. Ancak gerçekte, Uzman Danışmanın çalışması sırasında ticaret hesabında birçok eşzamansız değişiklik meydana gelir. Pozisyonlar değiştirilir, eklenir ve kaldırılır. OrderSelect()'e yapılan her çağrının sonucunu kontrol etmezseniz, belirli bir anda Expert Advisor'ın yanlış (sıfır) verilerle çalışması ve yanlış bir hareket yapması söz konusu olabilir.

 
Renat :
Ne yazık ki, hiç kimse ticaret işlemleri konusunda herhangi bir garanti vermeyecektir. Bu kod öncekinden çok daha iyi.

OrderSelect her zaman kontrol edilmelidir, bu açıkça Faydalı İpuçları'nda belirtilmiştir:
  • OrderSelect üzerinde kontrol eksikliği - eylemde süreç uyumsuzluğu

    ... Pozisyonlar değiştirilir, eklenir ve çıkarılır. ...

Diyelim ki pozisyon değiştiriliyor. Bazı koşullara göre, bir sipariş seçme talebi gerçekleşir. Bir hata oluşur. Ne değiştirilebilir? Bir sonraki kene başlangıç koşullarına sahip olmayabilir, neden önceki hataya ihtiyacım var?
Yorumsuz "eklendi ve kaldırıldı" hakkında :-(
Lütfen bana bir OrderCloseTime almak için OrderSelect kullanarak çalışan bir kod örneği verin.
1...45678910111213141516
Yeni yorum