Hatalar, hatalar, sorular - sayfa 433
Ticaret fırsatlarını kaçırıyorsunuz:
- Ücretsiz ticaret uygulamaları
- İşlem kopyalama için 8.000'den fazla sinyal
- Finansal piyasaları keşfetmek için ekonomik haberler
Kayıt
Giriş yap
Gizlilik ve Veri Koruma Politikasını ve MQL5.com Kullanım Şartlarını kabul edersiniz
Hesabınız yoksa, lütfen kaydolun
Renat , mümkünse lütfen SD'deki 124661 numaralı uygulamaya dikkat edin.
13 Haziran'dan beri cevap bekliyorum.
Renat , mümkünse lütfen SD'deki 124661 numaralı uygulamaya dikkat edin.
13 Haziran'dan beri cevap bekliyorum.
Demek defalarca doğru cevabı verdin. Sana tekrar cevap verdi.
Demek defalarca doğru cevabı verdin. Sana tekrar cevap verdi.
Bu uygulamada bir cevap göremiyorum. İçindeki son yorum 2011.06.21 09:25'e aittir (konunun alaka düzeyinin tekrar tekrar hatırlatılması).
Her ihtimale karşı burada çoğaltın:
Bir anlaşma/siparişin minimum hacmi/lotu üzerindeki kısıtlamanın sadece bir pozisyon açmak için geçerli olduğunu doğru anlıyor muyum?
Bu gereklilik , bir pozisyonun kapatılması, arttırılması, azaltılması veya tersine çevrilmesi ile sonuçlanacak işlemler /siparişler için geçerli değil mi?
Minimum işlem adımındaki kısıtlama, yukarıdaki senaryoların 5 (beş) tümü için geçerlidir.
Tüm olası senaryolar açıklanmış gibi görünüyor. Yoksa bu 5'ten (beş) başka var mı?
İki kez cevap verdin, sonra ben cevapladım.
Tekrar cevap vereceğim - evet, hacim limitleri kuralı tam bir kapatma için geçerli değildir.
MQL5'in hızını artırmaktan mı bahsediyorsunuz?
Sana iki kez cevap verildi, sonra ben cevapladım.
Tekrar cevap vereceğim - evet, hacim limitleri kuralı tam bir kapatma için geçerli değildir.
Renat , beni yanlış anlama. Sorumu şımartmak için değil, açıklığa kavuşturmak için tekrar ediyorum.
Şimdiye kadar, cevabınız ve meslektaşlarınız (SD'de) 2 (iki) senaryo ile ilgilidir: 1) bir pozisyon açmak , 2) bir pozisyonu tamamen kapatmak (muhtemelen ORDER_FILLING_AON 'un zorunlu kullanımı ile).
Bir emrin (işlem) yürütülmesinin sonucu , en az 3 (üç) senaryo daha olabilir: artış , azalma veya pozisyonun tersine çevrilmesi .
Ne yazık ki, MQ'dan gelen cevaplarda bu üç senaryo hakkında açık bir açıklama bulamıyorum. :(
Netlik için birkaç örnek vereceğim (sunucuda her durumda minimum lot = 1.0 ; minimum adım = 0.1):
Örnek No. 1 (konum azaltma).
1.0 hacimli uzun bir pozisyon var. Pozisyonu tamamen kapatmaya çalışıyoruz ( ORDER_FILLING_CANCEL kullanarak). 1.0 lot hacimli bir satış emri gönderiyoruz. Emir kısmen gerçekleştirilir (0,9 lot).
Enstrüman için sonuç, 0,1 lotluk kapatılmamış uzun bir pozisyondur. Böylece, pozisyon azaltma senaryosu için minimum parti büyüklüğü şartının geçerli olmadığı sonucuna varıyoruz.
Örnek No. 2 (konumun tersine çevrilmesi).
0.1 lotluk uzun bir pozisyon var. Sunucuya 0,2 lot hacimli satış emri gönderiyorum. Sunucu böyle bir düzene örnek midir? (minimum parti gereksinimleri yine karşılanmaz).
Örnek No. 3 (bir pozisyon oluşturma).
0.1 lotluk uzun bir pozisyon var. Sunucuya 0.1 lotluk bir satın alma emri gönderiyorum. Sunucu böyle bir düzene örnek midir?
Netlik için birkaç örnek vereceğim (sunucuda her durumda minimum lot = 1.0 ; minimum adım = 0.1):
Örnek No. 1 (konum azaltma).
1.0 hacimli uzun bir pozisyon var. Pozisyonu tamamen kapatmaya çalışıyoruz ( ORDER_FILLING_CANCEL kullanarak). 1.0 lot hacimli bir satış emri gönderiyoruz. Emir kısmen gerçekleştirilir (0,9 lot).
Enstrüman için sonuç, 0,1 lotluk kapatılmamış uzun bir pozisyondur. Böylece, pozisyon azaltma senaryosu için minimum parti büyüklüğü şartının geçerli olmadığı sonucuna varıyoruz.
Pozisyon 0.9'da kısmen kapalıysa (ve emir 1.0'daysa), bakiyeyi tekrar 0.1'de kapatmak için bir emir göndermeniz gerekecektir.
Ayrıca, yürütme harici bir ağ geçidinde gerçekleşirse, bölmenize izin vermeden yalnızca tüm birimi 1.0'da kapatmanıza izin vermeleri yüksek bir olasılıktır.
Örnek No. 2 (konumun tersine çevrilmesi).
0.1 lotluk uzun bir pozisyon var. Sunucuya 0,2 lot hacimli satış emri gönderiyorum. Sunucu böyle bir düzene örnek midir? (minimum parti gereksinimleri yine karşılanmaz).
Örnek No. 3 (bir pozisyon oluşturma).
0.1 lotluk uzun bir pozisyon var. Sunucuya 0,1 lot hacimli satın alma emri gönderiyorum. Sunucu böyle bir düzene örnek midir?
Tabii ki değil.
Lütfen kuralları harfi harfine okuyun ve kendi koşullarınızı oluşturmaya çalışmayın. Kural basittir "SIFIR'da bir pozu tasfiye ederken, hacim sınırları kuralı geçerli olmayabilir." Bu kural defalarca dile getirildi.
Ayrıca, herhangi bir komisyoncu veya herhangi bir değişim ağ geçidinin kendi, daha katı hacim kontrol kurallarını kullanabileceği de dikkate alınmalıdır.
Açma/kapama ayracı vurgulamanın çalışacağı maksimum satır sayısı 128'dir. Bu sınır, bir ekrana sığmayan açma ve kapama ayraçlarını vurgulamanın bir anlamı olmadığı için getirilmiştir. Ayrıca bu kısıtlamanın getirilmesinden sonra MetaEditor'un performansı önemli ölçüde arttı.
Temel bir soru değil, ama yine de. Dize birleştirme. Belgeler, StringAdd ve StringConcatenate adlı iki işlevi açıklar .
...
Sonuç:
2011.06.26 19:10:55 testi (EURUSD,H1) №1 2012 milisaniye, i = 10000000
2011.06.26 19:11:04 testi (EURUSD,H1) №2 8269 milisaniye, i = 10000000
2011.06.26 19:11:10 testi (EURUSD,H1) №3 6661 milisaniye, i = 10000000
Ancak sıradan eklemenin daha hızlı olduğu ortaya çıktı.
Örnek yanlış.
İlk yöntemde "sonuç = sonuç + dize1 + dize2 + dize3;" olmalıdır.
Ve 3 testin tümü için farklı sonuçlar verirdim, aksi takdirde eşit olmayan koşullarda başlarlar (bir miktar bellek zaten tahsis edilmiştir).
Daha da iyisi, testleri farklı komut dosyalarına ayırmak ve bunları sırayla çalıştırmaktır.
Ben böyle aldım:
1. uzunluk = 10.000
2011.06.27 02:43:05 sStingTest (EURUSD,M1) №2 0 milisaniye, i = 10000
2011.06.27 02:43:05 sStingTest (EURUSD,M1) #3 0 milisaniye, i = 10000
2. uzunluk = 100.000
2011.06.27 02:37:39 sStingTest (EURUSD,M1) #3 15 milisaniye, i = 1000000
1 Numaralı Bitiş - beklemedi
3. uzunluk = 1`000`000
2011.06.27 02:37:39 sStingTest (EURUSD,M1) #3 187 milisaniye, i = 1000000
1 Numaralı Bitiş - beklemedi
4. uzunluk = 10.000'000
2. testte, günlükte "MemoryException: 602492946 bayt kullanılamıyor" hatası görünmeye başlar, komut dosyası manuel olarak silinir.
Sonuç: StringConcatenate en hızlısıdır.
Bu arada StringAdd işlevine yapılan referansta da çok doğru bir karşılaştırma örneği yok.
Doğrulama kodum fragmanda.