"MetaTrader 5 ve MQL5 Ekonomik Takvim: Haberler Nasıl Tekrarlanabilir Bir Alım-Satım Sistemine Dönüştürülür?" makalesi için tartışma

 

Yeni makaleye göz atın: MetaTrader 5 ve MQL5 Ekonomik Takvim: Haberler Nasıl Tekrarlanabilir Bir Alım-Satım Sistemine Dönüştürülür?.

Makale, yerleşik ekonomik takvimi kullanarak MetaTrader 5'te haberlere dayalı alım-satıma sistematik bir yaklaşım sunmaktadır: veri yapısı, API fonksiyonları, zaman senkronizasyon kuralları ve olay filtreleme. Sunucuya aşırı yük bindirmeden önbelleğe alma ve aşamalı güncelleme yöntemleri açıklanmaktadır. Makale ayrıca, aynı algoritmayı kullanarak deterministik testler için geçmişi bir .EX5 kaynağına aktarmaya yönelik çalışan bir mekanizma sağlamaktadır.

Haberlere dayalı işlem yapan yatırımcıların temel sorunları, dağınık araç seti ve sistematik, algoritmik bir alım-satım iş akışının olmamasıdır. İşlem yaparken dikkatinizi internet tarayıcınız (haber sitelerinde gezinmek) ve işlem terminaliniz arasında bölmek oldukça zordur.

Haber tabanlı işlem yapan bir yatırımcının iş akışı şuna benzer: Web tarayıcınızda haber takvimini hızlıca açma ve olaylardaki değişiklikleri kontrol etme → Yaklaşan olayları hızlıca değerlendirme ve ne ve nasıl işlem yapacağınıza karar verme → MetaTrader 5 terminaline gitme - bekleyen emirler yerleştirme veya terminal başında oturup karar vermek için haberlerin yayınlanmasını bekleme. Bu senaryoda, yatırımcı genellikle bağlam kaybı yaşar, bu da haberlere tepki vermede gecikmelere yol açar ve bu da kayıplara neden olur.

Haberlere dayalı alım-satımın net kurallar, tekrarlanabilir sonuçlar ve otomatik testlerle bir mühendislik problemi gibi çalışmasını ister misiniz? Bu makalenin amacı, MetaTrader 5 için bir haber katmanının çalışma mimarisini göstermektir: tek bir veri kaynağı, takvim API'sinin uygun kullanımı, bir filtreleme ve önbelleğe alma mekanizması, geçmiş olayların sınayıcı için bir kaynağa aktarılması ve Canlı ve Sınayıcı arasında otomatik geçiş - böylece aynı kod hem gerçek zamanlı hem de geçmiş verilerde deterministik sonuçlar üretir.


Yazar: MetaQuotes

 

Makale için teşekkürler – çok ilginç – bunun nasıl çalıştığını inceleyeceğim... Ben de Vibe kodları ve AI ajanlarını haberler ve Twitter ayrıştırıcısı aracılığıyla bağlamak istiyordum – bunu gerçekleştirmek için... MQL5 ile AI ajanlarını birleştiren bir hibrit sistem de kurabiliriz...

 
Roman Shiredchenko #:

Makale için teşekkürler — çok ilginç — nasıl çalıştığını araştıracağım... Ben de Vibe kodları ve AI ajanlarını haberler ve Twitter parseri aracılığıyla bağlamak istiyordum — bunu gerçekleştirmek için... MQL5 ile AI ajanlarını birleştiren bir hibrit sistem de kurabiliriz....

Tüm ayrıntılarla birlikte tüm veriler zaten terminalde mevcutken neden bir şeyleri ayrıştırmaya gerek olsun ki? Üstelik AI da var zaten)
 
Dmitriy Skub #:
Terminalde tüm ayrıntılarla birlikte tüm girişler zaten mevcutken neden bir şeyi ayrıştırmaya gerek olsun ki? Üstelik AI da var)

Harika, bir bakmak lazım... ve kod yazmak da... )

 

Yazılan:

Если брокер учитывает переход на летнее/зимнее время — календарь автоматически подстраивается под этот переход

MQL5 API'sinde bir değişiklik olduysa beni düzeltin, ancak eskiden takvim, yaz saati uygulamasını (DST) dikkate alarak GEÇERLİ saat dilimine göre ayarlanıyordu; yani yaz aylarında işlev sorguları, örneğin UTC+3 saat diliminde zaman damgaları döndürürken, kışın aynı tarih aralığı için yapılan sorgu, sunucu yaz saati uygulamasına (DST) geçiş yapıp geri dönüyorsa, UTC+2 saat diliminde zaman damgalarına sahip olayları döndürürdü. Bu nedenle, yarım yıl veya daha uzun bir süreye ait takvim geçmişini doğru bir şekilde yüklemek için, brokerın saat dilimi geçiş geçmişini analiz etmek gerekir. Ayrıntılar kod tabanında yer almaktadır.

Ayrıca, takvim önbelleğini bir kaynak olarak bağlantı yoluyla kullanma yaklaşımı pek pratik görünmüyor ve özellikle makalede bahsedilen hatalara yol açıyor (örneğin, uzmanı yeniden derlemeyi unutmayın gibi). Takvim önbelleğini, tüm ajanlar tarafından erişilebilen Common klasöründeki bir dosya olarak giriş parametresinde neden belirtmiyoruz?

Economic Calendar Monitor and Cache for Backtesting on History
Economic Calendar Monitor and Cache for Backtesting on History
  • 2024.11.10
  • www.mql5.com
This indicator displays current events on the chart and allows you to export the calendar to archives for backtesting, automatically fixing time discrepancies between the history of bars and the history of events. This is an improved version of CalendarMonitorCached indicator from the algotrading book.
 
MQL5 API’sinde bir değişiklik olduysa lütfen beni düzeltin, ancak eskiden takvim, yaz saati uygulamasını (DST) dikkate alarak GEÇERLİ saat dilimine göre ayarlanıyordu; yani yaz aylarında işlev çağrıları, örneğin UTC+3 saat diliminde zaman damgaları döndürürken, kışın aynı tarih aralığı için yapılan sorgu, sunucu yaz saati uygulamasına geçiş yapıyorsa ve geri dönüyorsa, UTC+2 saat diliminde zaman damgalarına sahip olayları alırdı. Bu nedenle, yarım yıl veya daha uzun bir süreye ait takvim geçmişini doğru bir şekilde yüklemek için, часового пояса ayrıntılar kod tabanında yer almaktadır.

Peki neden fiyatlar (genel olarak tüm zaman damgaları) örneğin UTC'de tutulmuyor?

Neden dealerların tikleri, aynı zaman sayımını farklı sayısal biçimlerde gösteriyor?

Felsefi bir soru :-) Gelenek böyle, ancak bu yanlış ve yok yere sorunlara yol açıyor.


Not: Bu nedenle "geçmiş haberleri" diğer kaynaklardan almak daha iyidir.

Ve asla "saat çevrim geçmişini" kendiniz "analiz etmemelisiniz" — bunların hepsi zaten mevcuttur; bu, işletim sisteminin bir işlevi ya da en azından sistem kütüphanelerinin bir parçasıdır. Google'da tzdata'yı arayın

Bisiklet ne kadar yapılabilir ki, üstelik de çarpık olanlardan

 
Stanislav Korotky #:

Eskiden takvim, yaz saati uygulamasını (DST) dikkate alarak GEÇERLİ saat dilimine göre ayarlanırdı; yani yaz aylarında işlev çağrıları, örneğin UTC+3 saat diliminde zaman damgaları döndürürken, kışın aynı tarih aralığı için yapılan bir sorgu, sunucu yaz saati uygulamasına (DST) geçiş yapıp geri dönüyorsa, UTC+2 saat diliminde zaman damgalarına sahip olayları döndürür.

Ben de aynı kanıya vardım.
 
Maxim Kuznetsov #:


Not: Bu nedenle "tarihsel haberler"i başka kaynaklardan almak daha iyidir.

Ve asla "saat çevirilerinin tarihçesini" kendiniz "analiz etmeye" kalkışmayın — bunların hepsi zaten mevcut, bu bir işletim sistemi işlevi ya da en azından sistem kütüphanelerinin bir parçasıdır. Google'da "tzdata" araması yapın.

Bisikletler ne kadar yapılabilir ki, üstelik de çarpık olanlar


Diğer kaynaklar sorunu çözmez, çünkü sorun MT5'te fiyatların saklanma biçiminde yatıyor.

Öncelikle kendi düz bisikletinizi gösterin, sonra da tavsiyelerde bulunun.

 
MetaQuotes:

Günümüz haber tabanlı yatırımcılarının başlıca sorunları, dağınık araç seti ve sistematik, algoritmik bir işlem akışının olmamasıdır. İşlem yaparken dikkatinizi internet tarayıcınız (haber sitelerini gezmek) ile işlem terminaliniz arasında bölmek oldukça zordur.

Bir haber tabanlı yatırımcının iş akışı şu şekildedir: Web tarayıcınızda haber takvimini hızlıca açıp olaylarda herhangi bir değişiklik olup olmadığını kontrol edin → Yaklaşan olayları hızlıca değerlendirin ve neyi nasıl işlem yapacağınıza karar verin → MetaTrader 5 terminaline gidin – ya bekleyen emirler verin ya da terminal başında oturup haberin yayınlanmasını bekleyerek karar verin. Bu senaryoda, yatırımcı genellikle bağlamı kaçırır; bu da haberlere tepki vermede gecikmelere yol açar ve sonuçta zarara neden olur.

Haber ticareti, net kurallar, tekrarlanabilir sonuçlar ve otomatik testler içeren bir mühendislik problemi gibi çalışsın ister misiniz? Bu makalenin amacı, MetaTrader 5 için bir haber katmanının çalışma mimarisini göstermektir: tek bir veri kaynağı, takvim API’sinin doğru kullanımı, filtreleme ve önbellekleme mekanizması, geçmiş olayların test cihazı için bir kaynağa aktarılması ve Canlı ile Test Cihazı arasında otomatik geçiş — böylece aynı kod hem gerçek zamanlı hem de geçmiş verilerde belirleyici sonuçlar üretir.

Evet, bu haber ticareti için gerçek bir sorun noktasıdır.

Tarayıcı, takvim ve terminal arasında geçiş yapmak konsantrasyonu bozar ve tepki süresini önemli ölçüde yavaşlatır. Haberleri doğrudan işlem ortamına çeken birleşik bir iş akışı veya sisteme sahip olmak, işlemlerin gerçekleştirilmesini kesinlikle daha hızlı ve tutarlı hale getirecektir.

Bunu, test ve otomasyon içeren yapılandırılmış, tekrarlanabilir bir “mühendislik tarzı” kurulum haline getirme fikri, duygusal veya gecikmeli kararları önlemek açısından aslında çok mantıklıdır.