Hatalar, hatalar, sorular - sayfa 686

 
abolk :
Diğer bir seçenek ise açılış fiyatını bir önceki fiyat aralığında oluşan fiyat olarak değerlendirmektir . Marketlerin açılması örneğinde bunun doğru olmadığı gösterildi.

Bu saçmalığı bana atfetmiyorsun. Tekrarlıyorum:

Teklif basitçe şuna benziyor: açılış fiyatı, dakikanın oluşturulduğu anda MEVCUT fiyata eşit olduğunda, bir zaman modeline göre çubuklar oluşturmak. GERÇEK (aslında mevcut teklif fiyatı) ve önceki çubuğun kapanış fiyatı değil!

Her bir FI için piyasa, bu FI için teklif fiyatı göründüğü anda açılır. Aynı FOREX'te, piyasa aynı anda tüm FI'lar için aynı anda açılmaz.

 
abolk :

Burada kuralı kendiniz çıkardınız: "Fiyat yok - çubuk yok."

Piyasa açıksa, ancak likidite (satıcılar veya alıcılar) yoksa, fiyat da yoktu. Ya bir "teklif fiyatı" ya da bir "talep fiyatı" vardı, ancak işlemin taraflarından birinin yokluğunda fiyat mevcut değildi, sadece önceki dönemin fiyatı mevcuttu.

Ve çoklu para birimi senkronizasyonu durumunda fiyat kararının terminal tarafından değil, TS'nin kendisi tarafından alınması doğrudur. Çünkü fiyatın yokluğunda fiyatın ne olduğu sorusu muğlak bir sorudur.

Pekala Andrew, beni neredeyse ikna ettin.

Ardından terminalin kükreme tarafından kaçırılan çubukları NAN değeriyle doldurmasına izin verin - Katılıyorum! Ama onları geri dönülmez bir şekilde (düzenli yollarla) zaman serilerinden çıkarmaz. Tek ihtiyacım olan düzenli bir senkronizasyon aracı. "Belirsiz" çubukları nasıl dolduracağıma kendim karar vereceğim. Hatta (en kötü ihtimalle) kaçırılan çubukların gösterilmediğini kabul etmeye hazırım, ancak bu beni çeşitli enstrümanların tablolarını görsel olarak karşılaştırma fırsatından mahrum ediyor. Ancak hesaplamalar için senkronize (çubuk numarasına göre) alıntılara ihtiyacım var. Öyleyse soru şu - bu kadar orijinal olan tek ben miyim, yoksa başka birinin onlara ihtiyacı var mı? İhtiyacı olanların oranı nedir? Bu oran artıyor mu azalıyor mu? Ve son olarak, hangi derleyici daha hızlı kod üretir - MQL5 veya C++?

 
Görev basittir, test cihazının mümkün olduğunca az yanlışlık vermesini sağlamak. Şu anda, testçi neredeyse her zaman yalan söylüyor ve bir dakikanın oluşumu sırasında fiyatın barın açılış fiyatına eşit olduğunu söylüyor. Bu nedenle testçide sürekli olarak açılış fiyatlarında arbitraj oluşurken kapanış fiyatlarında gerçekleşmez. Ve çubuk oluşturmanın tık tık modelini kullanmanın bir sonucu olarak, TS bar kapanış fiyatlarında birkaç FI'yi senkronize etmek için hesaplama kaynaklarının harcamasını üstlenir. Geliştiriciler, kullanıcıların test cihazındaki her çalıştırmada aptal senkronizasyona her seferinde çok fazla bilgi işlem kaynağı harcaması için eşleşmelerden tasarruf sağlar. Optimizasyona başlamadan önce bu senkronizasyonun yapılmasına izin vermezler.
 
hrenfx :

Her bir FI için piyasa, bu FI için teklif fiyatı göründüğü anda açılır. Aynı FOREX'te, piyasa aynı anda tüm FI'lar için aynı anda açılmaz.

Eh, o zaman sadece tüm piyasa katılımcılarını yalnızca aynı anda hareket etmeye zorlamak kalır.

Çoklu para birimi stratejilerinin sorularından biri, çok uzun zaman önce gerçekleşen son fiyatın belirli bir zamanda yeterli olduğunu düşünmenin doğru olup olmadığıdır.

 
abolk :

Çoklu para birimi stratejilerinin sorularından biri, çok uzun zaman önce gerçekleşen son fiyatın belirli bir zamanda yeterli olduğunu düşünmenin doğru olup olmadığıdır.

Geçmiş fiyatın mevcut işlem seansına atıfta bulunması kesinlikle doğrudur. Yine, patateslerin fiyatını alın.
Документация по MQL5: Получение рыночной информации / SymbolInfoSessionQuote
Документация по MQL5: Получение рыночной информации / SymbolInfoSessionQuote
  • www.mql5.com
Получение рыночной информации / SymbolInfoSessionQuote - Документация по MQL5
 
hrenfx :
Geçmiş fiyatın mevcut işlem seansına atıfta bulunması kesinlikle doğrudur. Yine, patateslerin fiyatını alın.
Mevcut seansta karar verirken geçmiş fiyatı dikkate aldığınızda doğrudur ancak son seans fiyatını cari seansa yönlendirmek yanlıştır. Fiyatın tanımını yukarıda verdim. "Alım/satım fiilinin fiyatı", "talep fiyatı", "teklif fiyatı" arasında ayrım yapmak gerekir. "Talebin fiyatını bilmiyoruz." İşlem seansı, "satın alma/satış fiyatlarına" göre oluşturulur. Bir önceki dönemin "satın alma / satış eylemi fiyatları" üzerinden bir işlem seansı oluşturmayı teklif ediyorsunuz. Bu fiyatlar önceki dönemde oluşmuşsa ve zaten biliniyorsa ve elde edilebiliyorsa bu fiyatlar neden cari döneme aktarılsın ki?
 
abolk :
Mevcut seansta karar verirken geçmiş fiyatı dikkate aldığınızda doğrudur ancak son seans fiyatını cari seansa yönlendirmek yanlıştır.

Ve burada yazan da bu değil mi:

hrenfx :
Geçmiş fiyatın mevcut işlem seansına atıfta bulunması kesinlikle doğrudur. Yine, patateslerin fiyatını alın.

Bu çubuk oluşum modelinde bana en az bir kusur söyle:

Yeni bir dakika gelir - açılış fiyatı yeni dakikanın teklif fiyatı olan bir çubuk oluşur. Aynı zamanda, dakika anında (işlem seansının açılışı) teklif fiyatı yoksa, çubuk oluşmaz veya NAN değeri ile oluşturulur (açılış fiyatı için, Yüksek, Düşük ve Kapat zaten olabilir). Kapalı bir işlem seansı sırasında çubuklar oluşmaz.

 
hrenfx :

Bu çubuk oluşum modelinde bana en az bir kusur söyle:

Yeni bir dakika gelir - açılış fiyatı yeni dakikanın teklif fiyatı olan bir çubuk oluşur. Aynı zamanda, dakika (işlem seansının açılışı) anında herhangi bir teklif fiyatı yoksa, çubuk oluşmaz veya NAN değeri ile oluşturulur. Kapalı bir işlem seansı sırasında çubuklar oluşmaz.

Fiyat tanımına göre yanlış seçilmiş. Sürekli olarak " son ticaretin fiyatını" "henüz gerçekleşmemiş ticaretin fiyatı" ile eşitliyorsunuz. Ayrıca, "son anlaşma fiyatını" "teklif fiyatı" ile eşitlediğimizde zaten şüpheli bir varsayımda bulunduk. Sürekli olarak "teklif fiyatlarında" bir bar oluşturmaya mı başlıyorsunuz? Bu fiyatlar nedir? Onları nasıl tanıyoruz?
 
abolk :
Fiyat tanımına göre yanlış seçilmiş. Sürekli olarak " son ticaretin fiyatını" "henüz gerçekleşmemiş ticaretin fiyatı" ile eşitliyorsunuz. Ayrıca, "son anlaşma fiyatını" "teklif fiyatı" ile eşitlediğimizde zaten şüpheli bir varsayımda bulunduk. Sürekli olarak "teklif fiyatlarında" bir bar oluşturmaya mı başlıyorsunuz? Bu fiyatlar nedir? Onları nasıl tanıyoruz?

Satır aralarını okuduğun saçmalıkları sürekli bana atfediyorsun. İşte teklifimin uygulanmasının özel bir örneği

  1. 00:59:58 - 1.2301 EURUSD fiyatı geldi.
  2. 00:01:00 - 1.2301 fiyatı zaten 2 saniye için geçerli, bu nedenle barın 00:01'deki açılış fiyatı buna eşittir - 1.2301.

Başka bir örnek:

  1. İşlem seansının açılışı 00:00:00.
  2. İlk fiyat 00:02:34 - 1.2301'de görünür. Ardından bir dakika içinde fiyat 1.2290 - 1.2310 aralığında değişir. 00:02 dakika sonunda ise 1,2305 olur.

Bu örnek için üç çubuğumuz var:

  • 00:00 - {NAN, NAN, NAN, NAN} (OHLC);
  • 00:01 - {NAN, NAN, NAN, NAN} (OHLC);
  • 00:02 - {NAN, 1.2310, 1.2290, 1.2305} (OHLC);

Kusur nerede?

 
MetaDriver :

Pekala Andrew, beni neredeyse ikna ettin.

Ardından terminalin kükreme tarafından kaçırılan çubukları NAN değeriyle doldurmasına izin verin - Katılıyorum! Ama onları geri dönülmez bir şekilde (düzenli yollarla) zaman serilerinden çıkarmaz. Tek ihtiyacım olan düzenli bir senkronizasyon aracı. "Belirsiz" çubukları nasıl dolduracağıma kendim karar vereceğim. Hatta (en kötü ihtimalle) kaçırılan çubukların gösterilmediğini kabul etmeye hazırım, ancak bu beni çeşitli enstrümanların tablolarını görsel olarak karşılaştırma fırsatından mahrum ediyor. Ancak hesaplamalar için senkronize (çubuk numarasına göre) alıntılara ihtiyacım var.

"Başarısız" çubukların varlığı/yokluğu hakkında hiçbir şey söyleyemem - bu benim için kritik değil. Uygulama sorunları da bilinmiyor. Belki de önemliler ve şu ana kadar mevcut çözümden ödün veriyorlar. Çok önemliyse ve terminalde yoksa, "başarısız" çubukların "çizimi" bağımsız olarak uygulanabilir.
Neden: