Test cihazı düzgün çalışıyor mu? - sayfa 5

Yeni yorum
 
Integer :
Şey... Acelem vardı... Açılış fiyatı bir öncekinin kapanış fiyatına eşit olan barlar varmış. O zaman MT çubukları çekmek için hangi sistemi kullanıyor? Muhtemelen sadece geliştiriciler açıklayabilir. anlamayı çok isterim.

Yalnızca, kota dışı bir dönem varsa, teklifler göründüğünde, komisyoncunun aynı fiyatla bir onay verebileceğini varsayabilirim. Ama bu sadece tahmin.

Yalnızca gerçek zamanlı verilerimiz kullanılırsa ve oturumlar arası kesinti veya sunucu yeniden başlatılmazsa, bir çubuğun Kapanışı bir sonrakinin Açık değerine eşit olamaz. İçe aktarılan veriler kullanılıyorsa, bu olabilir.
 
Renat :
tamsayı :
Şey... Acelem vardı... Açılış fiyatı bir öncekinin kapanış fiyatına eşit olan barlar varmış. O zaman MT çubukları çekmek için hangi sistemi kullanıyor? Muhtemelen sadece geliştiriciler açıklayabilir. anlamayı çok isterim.

Yalnızca, kota dışı bir dönem varsa, teklifler göründüğünde, komisyoncunun aynı fiyatla bir onay verebileceğini varsayabilirim. Ama bu sadece tahmin.

Yalnızca gerçek zamanlı verilerimiz kullanılırsa ve oturumlar arası kesinti veya sunucu yeniden başlatılmazsa, bir çubuğun Kapanışı bir sonrakinin Açık değerine eşit olamaz. İçe aktarılan veriler kullanılıyorsa, bu olabilir.
Bu, bir dakikalık TF'nin herhangi bir verisindedir - Alpari'den indirdiğim alıntılarda kendiniz de görebilirsiniz, öyle görünüyor.



İşte bir örnek: gerçek zamanlı alıntılar, demo sunucunuz. Vurgulanan çubuğa ve yukarıdaki iki çubuğa bakın. Seçilen çubukta, tık hacmi değeri 0'a eşit olmalıdır. Bu seviyeye gelen fiyat değişikliği bir önceki çubuğun hareket hacminde dikkate alındığından.
1'in üzerindeki iki çubuk doğrudur.

Ve bu izole bir durum değil. Geçmişi görüntüleyin. Bunun alıntılarla ilgili olduğunu düşünmüyorum.

Bu yüzden soru ortaya çıktı.

İyi şanlar. Saygılarımla, Vladislav.

ZY Üzgünüm - bu örnek doğru değil - Yanlış yöne baktım. Şimdi başka bir yere bakacağım.
ZZY Verilerinizi bir script ile çalıştırdım - tekrar gözlerimle hata yapmaktan korktum - sunucunuzdan gerçek zamanlı olarak aldıklarımda gerçekten böyle bir şey yok. O yüzden soruyu kaldırıyorum.

İyi şanlar. Saygılarımla, Vladislav.
 
VladislavVG :
Renat :
tamsayı :
Şey... Acelem vardı... Açılış fiyatı bir öncekinin kapanış fiyatına eşit olan barlar varmış. O zaman MT çubukları çekmek için hangi sistemi kullanıyor? Muhtemelen sadece geliştiriciler açıklayabilir. anlamayı çok isterim.

Yalnızca, kota dışı bir dönem varsa, teklifler göründüğünde, komisyoncunun aynı fiyatla bir onay verebileceğini varsayabilirim. Ama bu sadece tahmin.

Yalnızca gerçek zamanlı verilerimiz kullanılırsa ve oturumlar arası kesinti veya sunucu yeniden başlatılmazsa, bir çubuğun Kapanışı bir sonrakinin Açık değerine eşit olamaz. İçe aktarılan veriler kullanılıyorsa, bu olabilir.
Bu, herhangi bir dakikadaki TF verilerindedir - Alpari'den indirdiğim alıntılarda da kendiniz görebilirsiniz.

İşte bir örnek: gerçek zamanlı alıntılar, demo sunucunuz. Vurgulanan çubuğa ve yukarıdaki iki çubuğa bakın. Seçilen çubukta, tık hacmi değeri 0'a eşit olmalıdır. Bu seviyeye gelen fiyat değişikliği bir önceki çubuğun hareket hacminde dikkate alındığından.
1'in üzerindeki iki çubuk doğrudur.

Ve bu izole bir durum değil - her zaman olur. Yani daha doğru konuşursam, seçilen durumda sıfırın olacağı tek bir çubuk bulamadım. Geçmişi görüntüleyin. Bunun alıntılarla ilgili olduğunu düşünmüyorum.

Bu yüzden soru ortaya çıktı.

İyi şanlar. Saygılarımla, Vladislav.


Bu örnekle neyi göstermek istiyorsunuz? Bir tekliften bar-kaçınma (OHLC = tek fiyat)?
Yani bu tamamen normal bir durum. Herhangi bir hata veya tutarsızlık yoktur.
 
Renat :
VladislavVG :
Renat :
tamsayı :
Şey... Acelem vardı... Açılış fiyatı bir öncekinin kapanış fiyatına eşit olan barlar varmış. O zaman MT çubukları çekmek için hangi sistemi kullanıyor? Muhtemelen sadece geliştiriciler açıklayabilir. anlamayı çok isterim.

Yalnızca, kota dışı bir dönem varsa, teklifler göründüğünde, komisyoncunun aynı fiyatla bir onay verebileceğini varsayabilirim. Ama bu sadece tahmin.

Yalnızca gerçek zamanlı verilerimiz kullanılırsa ve oturumlar arası kesinti veya sunucu yeniden başlatılmazsa, bir çubuğun Kapanışı bir sonrakinin Açık değerine eşit olamaz. İçe aktarılan veriler kullanılıyorsa, bu olabilir.
Bu, herhangi bir dakikadaki TF verilerindedir - Alpari'den indirdiğim alıntılarda da kendiniz görebilirsiniz.

İşte bir örnek: gerçek zamanlı alıntılar, demo sunucunuz. Vurgulanan çubuğa ve yukarıdaki iki çubuğa bakın. Seçilen çubukta, tık hacmi değeri 0'a eşit olmalıdır. Bu seviyeye gelen fiyat değişikliği bir önceki çubuğun hareket hacminde dikkate alındığından.
1'in üzerindeki iki çubuk doğrudur.

Ve bu izole bir durum değil - her zaman olur. Yani daha doğru konuşursam, seçilen durumda sıfırın olacağı tek bir çubuk bulamadım. Geçmişi görüntüleyin. Bunun alıntılarla ilgili olduğunu düşünmüyorum.

Bu yüzden soru ortaya çıktı.

İyi şanlar. Saygılarımla, Vladislav.


Bu örnekle neyi göstermek istiyorsunuz? Bir tekliften bar-kaçınma (OHLC = tek fiyat)?
Yani bu tamamen normal bir durum. Herhangi bir hata veya tutarsızlık yoktur.
Evet, bir önceki gönderiyi zaten gördüm ve düzelttim.

İyi şanlar. Saygılarımla, Vladislav.
 
VladislavVG :

Not Üzgünüm - bu örnek doğru değil - Yanlış yöne baktım. Şimdi başka bir yere bakacağım.
ZZY Verilerinizi bir script ile çalıştırdım - tekrar gözümle hata yapmaktan korktum - sunucunuzdan gerçek zamanlı olarak aldıklarımda gerçekten öyle bir şey yok. O yüzden soruyu kaldırıyorum.


Evet, ayrıca if(Close[previous]==Open[current]) koşulunu kontrol etmek için bir komut dosyası yazdım ve bunu yalnızca içe aktarılan verilerde buldum. Gerçek zamanlı verilerimiz için durum böyle değil.
 
Renat :
VladislavVG :

ZY Üzgünüm - bu örnek doğru değil - Yanlış yöne baktım. Şimdi başka bir yere bakacağım.
ZZY Verilerinizi bir script ile çalıştırdım - tekrar gözlerimle hata yapmaktan korktum - sunucunuzdan gerçek zamanlı olarak aldıklarımda gerçekten böyle bir şey yok. O yüzden soruyu kaldırıyorum.


Evet, ayrıca if(Close[previous]==Open[current]) koşulunu kontrol etmek için bir komut dosyası yazdım ve bunu yalnızca içe aktarılan verilerde buldum. Gerçek zamanlı verilerimiz için durum böyle değil.
Böyle bir durumda testçinin testleri büyük ölçüde çarpıtması gerektiğini doğru anlıyor muyum? Belki de standart komut dosyasına böyle bir çek eklemeye değer? Testler için doğrulanmış verileri kullanmanın daha iyi olduğu açıktır. Ancak birçok tüccar, sistemleri komisyoncularının verileriyle test eder - yanlış anlamalar mümkündür.

İyi şanlar. Saygılarımla, Vladislav.
 
VladislavVG :

Evet, ayrıca if(Close[previous]==Open[current]) koşulunu kontrol etmek için bir komut dosyası yazdım ve bunu yalnızca içe aktarılan verilerde buldum. Gerçek zamanlı verilerimiz için durum böyle değil.
Böyle bir durumda testçinin testleri büyük ölçüde çarpıtması gerektiğini doğru anlıyor muyum? Belki de standart komut dosyasına böyle bir çek eklemeye değer mi? Testler için doğrulanmış verileri kullanmanın daha iyi olduğu açıktır. Ancak birçok tüccar, sistemleri komisyoncularının verileriyle test eder - yanlış anlamalar mümkündür.

İyi şanlar. Saygılarımla, Vladislav.
Kesinlikle yanlış. Tüccarların kafasında bir pip hakkında yanlış yönlendirilmiş düşüncelerden başka bir yanlış beyan yoktur.

Test ederken asla kenelere güvenmemeniz gerektiğini anlayın. Aksine, yarı yayılma içindeki gürültü hareketlerine dikkat etmemelisiniz. Hemen hemen her tüccar, fazladan bir pip kapabilme umuduyla banal bir düşüş yaşar. Ayrıca çoğu tüccar "hayır, ben bir pipser değilim, doğru uygulamayı temsil ediyorum!" :)

İnsanlar kesinlikle doğru ve garantili bir uygulama umuduyla kendilerini kandırıyorlar ve sonra gerçekte kendilerine yeniden fiyat verildiğine ve hızlı bir piyasada anlaşma yapmanın imkansız olduğuna şaşırıyorlar. Ayrıca, birçoğu yeniden teklifleri ve diğer ticari sunucu yanıtlarını hiç işlemez.
 
Renat :
VladislavVG :

Evet, ayrıca if(Close[previous]==Open[current]) koşulunu kontrol etmek için bir komut dosyası yazdım ve bunu yalnızca içe aktarılan verilerde buldum. Gerçek zamanlı verilerimiz için durum böyle değil.
Böyle bir durumda testçinin testleri büyük ölçüde çarpıtması gerektiğini doğru anlıyor muyum? Belki de standart komut dosyasına böyle bir çek eklemeye değer? Testler için doğrulanmış verileri kullanmanın daha iyi olduğu açıktır. Ancak birçok tüccar, sistemleri komisyoncularının verileriyle test eder - yanlış anlamalar mümkündür.

İyi şanlar. Saygılarımla, Vladislav.
Kesinlikle yanlış. Tüccarların kafasında bir pip hakkında yanlış yönlendirilmiş düşüncelerden başka bir yanlış beyan yoktur.

Test ederken asla kenelere güvenmemeniz gerektiğini anlayın. Aksine, yarı yayılma içindeki gürültü hareketlerine dikkat etmemelisiniz. Hemen hemen her tüccar, fazladan bir pip kapabilme umuduyla banal bir düşüş yaşar. Ayrıca çoğu tüccar "hayır, ben bir pipser değilim, doğru uygulamayı savunuyorum!" :)

İnsanlar kesinlikle doğru ve garantili bir uygulama umuduyla kendilerini kandırıyorlar ve sonra gerçekte kendilerine yeniden fiyat verildiğine ve hızlı bir piyasada anlaşma yapmanın imkansız olduğuna şaşırıyorlar. Ayrıca, birçoğu yeniden teklifleri ve diğer ticari sunucu yanıtlarını hiç işlemez.
Evet, genel olarak hiçbir zaman doğru bir performans ummadım. Ve keneleri tamamen anlıyorum. Genel olarak, tüm duraklarım istatistiksel olarak anlamlı geri dönüş bölgelerinin dışına çıkıyor ve önceki çubuğun ekstremumunun 2.5 ATP'sinden daha yakın değil :). Yani, bir "piping" algoritması ipucu bile yok. Yayılma-yarı yayılma ile ilgili olarak, daha doğru bir tahminin ATP'de ifade edilen değer olduğunu bile söyleyebilirim (uygulamayla test edilmiştir).

Bu tür "girişimlerin" (bunlara şöyle diyelim) test cihazının kalitesini ne kadar etkileyebileceğini bilmek istedim. Stratejinin kendisini düşünmediğimi yukarıda yazdım.
Cevabınızdan, yapamayacakları sonucuna varıyorum. Bu cesaret verici.

İyi şanlar. Saygılarımla, Vladislav.
 
Renat писал (а):

Yalnızca gerçek zamanlı verilerimiz kullanılırsa ve oturumlar arası kesinti veya sunucu yeniden başlatılmazsa, bir çubuğun Kapanışı bir sonrakinin Açık değerine eşit olamaz. İçe aktarılan veriler kullanılıyorsa, bu olabilir.

İçe aktarılan verilerim yok, ancak DC'den "yasal olarak" MT'ye yükledim.
 
Integer :
Renat yazdı:

Yalnızca gerçek zamanlı verilerimiz kullanılırsa ve oturumlar arası kesinti veya sunucu yeniden başlatılmazsa, bir çubuğun Kapanışı bir sonrakinin Açık değerine eşit olamaz. İçe aktarılan veriler kullanılıyorsa, bu olabilir.

İçe aktarılan verilerim yok, ancak DC'den "yasal olarak" MT'ye yükledim.
Bu, ticaret sunucusuna aktarıldıkları anlamına gelir - bu genellikle erken dönemlerin geçmiş verileri için bulunur.
1234567
Yeni yorum
Neden: