Uzman Danışman yazma süresi - sayfa 5
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
Kaynağın ondan yaptığı bir emri atabilirim, kimin nitel olarak yapıp yapmadığını anlayana bakabilirsin, nitelik olarak olup olmadığını anlamıyorum, asıl mesele algoritmaya göre çalışması, ama içeride nasıl bilmiyorum)0
Kodun çoğu, size gönderdiğine inandığım Trades.mqh kitaplığında. Kaliteyi değerlendirmek için ekleyin.
Bu dosyadan söylenecek pek bir şey yok. Görünen o ki, olması gereken yerde kontroller ve normalleştirmeler yok, ancak bunlar dahil edilen Trades.mqh dosyasında da olabilir.
Evet ve kodun çoğu aynı yerde.
Ancak sinyal bloğu hakkında söylenecek bir şey var.
1) Herhangi bir normalleştirme olmaksızın birbirleriyle ikili karşılaştırma.
2) MA fiyatının , mumun kapanış fiyatının MA fiyatına eşit olduğu durumlar dikkate alınmadan geçilmesi. Nadirdir, ancak mümkündür.
Zor olduğunu iddia etmiyorum ve evet orada çok fazla hata çıktı ama 2 ay önce onlara hataların bilindiği, ortadan kaldırıldığı ve en zor şeylerin geride kaldığı söylendi, ne yazık ki bunu yapmıyorum, ama stratejinin tüm ayrıntılarını ayrıntılı olarak bilen ve saat ücretini ve iş hakkında sadece bir raporu kabul eden ve ona bunun kötü ve yanlış olduğunu kanıtlayamadım.
Serbest meslekte saatlik ücret var mı?
tahkim yoluyla sorunları çözmek mümkün olduğu gerçeği, böyle bir şey var, orada yargılayacaklar.
Böyle bir içki gittiği için tartışmaya katılmama izin verin)))
Her şeyden önce, elbette, geliştirmedeki böyle bir gecikme için 82Dmitry82 ve ekibinin geri kalanından özür dilerim. Ben de temsilcilerine daha önce belirttiğim gibi, geliştirmeyi üstlendiğime pişman oldum, bunun benim için zor bir görev olduğunu kabul ediyorum. Görev parçalara ayrıldı, ancak ikinci aşamada TOR'un güçlü bir komplikasyonu ortaya çıktı ve aslında bir kez başladığında tamamlamaya karar verdim, ancak o kadar basit olmadığı ortaya çıktı.
Şimdi, stratejiyi açıklamadan, TK'nin karmaşıklığı gerçeğini belirtmeye çalışacağım, böylece programcı arkadaşlarım bu gerçeğin geliştirmeyi ne kadar karmaşık hale getirdiğini gerçekten takdir edebilirler.
Siparişlerin açılması gereken seviyelerin grafik yapısına dayanır. Grafiğin kenarında, tarihe atıfta bulunmadan hareket halindeyken, bu seviyeler oluşturulamaz, geçmiş birikene kadar beklemeniz veya danışmanın geçmişe dönmesini ve zaten ile grafiğin kenarına gelmesini sağlamanız gerekir. birkaç veri. Bu yüzden böyle yapılmasına karar verildi.
İlk başta şamdanlar üzerinde hareket ediyor, 4 parametreyi (Açık,Kapat,Yüksek,Düşük) değerlendiriyor ve şartlara göre inşaatlar yapıyor gibi görünüyorduk. Kıdemli TF'de ilk bölüm bu şekilde yapıldı (TOR, her biri farklı konstrüksiyon ve bu konstrüksiyonlar için koşullar olan 3 TF'ye bölünmüştür). İkinci TF'ye geçip aslında hazır olan ikinci bölümü test etmeye başladığımızda, hatalar ortaya çıktı ve bunların genel bir tartışması sırasında, tarihteki mumun çevrimiçi olarak izlenmesi gerektiği ortaya çıktı (yani, grafiğin kenarında sıfır gibi) ve mum hala kapalı değilken yeniden oluşturma, bu geçmişe doğru ilerlerken gerçekçi değil, çünkü aslında 4 parametre Açık, Kapat, Düşük, Yüksek.
Genel görüşme sırasında, mumun yapımını mümkün olduğunca çevrimiçi takip edebilmek için mumun derinleştirilmesi ve m1'e bölünmesi gerektiğine karar verildi (sanki grafiğin kenarında sıfır gibi). Geçmişin yapısını 4 puan olduğu gibi bırakma önerisi ve grafiğin kenarında zaten izlenecek doğru mantık (Kapat[0] kayarken) reddedildi. Müşteriler, geliştirme sürecinde ortaya çıkan bu gerçeğin TOR'u önemli ölçüde karmaşıklaştırdığını anladılar. Zaten o aşamada geliştirmeyi bırakmak istedim ama ilk aşama bittiği için ve geliştirmeyi merkezde bırakmak tamamen ilkelerimde olmadığı için devam etmeye karar verdim. Mevcut bir algoritmayı M1 boyunca koşmanız ve daha eski TF'leri izlemeniz gerektiği gerçeğine uyarlama sürecinde, bu süreçte bunun için çok fazla zaman öldürdüğüm gerçeğinden psikoz bana gelmeye başladı. Başarısız olduğum için, ayrıldım ve müşterilere geliştirme fiyatını yükseltmenin gerekli olduğunu yazdım, ancak bilgisayarı terk edip çalışmadığı gerçeğinden biraz soğuduğunda, düzenlemeye devam etti.
Projeyi kararlaştırılan miktar için çekecek gücü kalmadığı için zamana dayalı bir ödeme teklif etti. Kaynak vermeyi teklif etmesine rağmen, akıllarına getirecek birini bulsunlar.
Aslında, başlangıçta eski TF içinde m1'i izlemem gerektiğini bilseydim, EA mantığını farklı şekilde kurardım.
Şimdi bana yapım hatası olan bir ekran göndermeleri prensibine göre çalışıyoruz, düzeltiyorum. Stratejide aslında hatırlamıyorum bile çok sayıda koşul olduğundan, tüm olasılıkları kendiniz kontrol etmenin gerçekten bir yolu yok. Hepsini birbiriyle çelişmemeleri için koordine etmek, asıl sorun budur. Her şey yavaş yavaş yapıldı ve müşterilerin kendileri stratejinin anlaşılmasının zor olduğunu kabul ediyorlar, ancak genel olarak, şimdi hemen hemen her şey zaten dile getirildi, ancak nasıl çalıştığını gördükten sonra doğru ya da yanlış anlayamıyorum)))
En son durduğumuz durum (müşteri temsilcisine göre bile) dikkate alınmayan bir durumdu ve şimdi bir düzine şartla daha yazmamız, araya girmemiz ve anlaşmamız gerekiyor. Bu nedenle saatlik ödemeye geçişi haklı buluyorum.
82Dmitry82, istersen seninle danışman konusunda bizzat konuşabiliriz, bağlantılarım sende. Sizin için başka bir danışman yaptım, verimliliği ve desteği takdir ettiklerini düşünüyorum, ancak bununla sabır isteyeceğim, bazen üzerinde çalışmayı erteliyorum, çünkü başka bir şeyi düzeltmeye başlamak için hangi tarafa yaklaşılacağına dair bir anlayış yok. yanlış seviye bina.
Şu anda, danışmanın 1000 satırdan fazla kodu var ve bu sadece güzel bir karmaşa ve hatta henüz ulaşılmamış siparişler olmadan bina seviyeleri.
Böyle bir içki gittiği için tartışmaya katılmama izin verin)))
Her şeyden önce, elbette, geliştirmedeki böyle bir gecikme için 82Dmitry82 ve ekibinin geri kalanından özür dilerim. Ben de temsilcilerine daha önce belirttiğim gibi, geliştirmeyi üstlendiğime pişman oldum, bunun benim için zor bir görev olduğunu kabul ediyorum. Görev parçalara ayrıldı, ancak ikinci aşamada TOR'un güçlü bir komplikasyonu ortaya çıktı ve aslında bir kez başladığında tamamlamaya karar verdim, ancak o kadar basit olmadığı ortaya çıktı.
Şimdi, stratejiyi açıklamadan, TK'nin karmaşıklığı gerçeğini belirtmeye çalışacağım, böylece programcı arkadaşlarım bu gerçeğin geliştirmeyi ne kadar karmaşık hale getirdiğini gerçekten takdir edebilirler.
Siparişlerin açılması gereken seviyelerin grafik yapısına dayanır. Grafiğin kenarında, tarihe atıfta bulunmadan hareket halindeyken, bu seviyeler oluşturulamaz, geçmiş birikene kadar beklemeniz veya danışmanın geçmişe dönmesini ve zaten ile grafiğin kenarına gelmesini sağlamanız gerekir. birkaç veri. Bu yüzden böyle yapılmasına karar verildi.
İlk başta şamdanlar üzerinde hareket ediyor, 4 parametreyi (Açık,Kapat,Yüksek,Düşük) değerlendiriyor ve şartlara göre inşaatlar yapıyor gibi görünüyorduk. Kıdemli TF'de ilk bölüm bu şekilde yapıldı (TOR, her biri farklı konstrüksiyon ve bu konstrüksiyonlar için koşullar olan 3 TF'ye bölünmüştür). İkinci TF'ye geçip aslında hazır olan ikinci bölümü test etmeye başladığımızda, hatalar ortaya çıktı ve bunların genel bir tartışması sırasında, tarihteki mumun çevrimiçi olarak izlenmesi gerektiği ortaya çıktı (yani, grafiğin kenarında sıfır gibi) ve mum hala kapalı değilken yeniden oluşturma, bu geçmişe doğru ilerlerken gerçekçi değil, çünkü aslında 4 parametre Açık, Kapat, Düşük, Yüksek.
Genel görüşme sırasında, mumun yapımını mümkün olduğunca çevrimiçi takip edebilmek için mumun derinleştirilmesi ve m1'e bölünmesi gerektiğine karar verildi (sanki grafiğin kenarında sıfır gibi). Geçmişin yapısını 4 puan olduğu gibi bırakma önerisi ve grafiğin kenarında zaten izlenecek doğru mantık (Kapat[0] kayarken) reddedildi. Müşteriler, geliştirme sürecinde ortaya çıkan bu gerçeğin TOR'u önemli ölçüde karmaşıklaştırdığını anladılar. Zaten o aşamada geliştirmeyi bırakmak istedim ama ilk aşama bittiği için ve geliştirmeyi merkezde bırakmak tamamen ilkelerimde olmadığı için devam etmeye karar verdim. Mevcut bir algoritmayı M1 boyunca koşmanız ve daha eski TF'leri izlemeniz gerektiği gerçeğine uyarlama sürecinde, bu süreçte bunun için çok fazla zaman öldürdüğüm gerçeğinden psikoz bana gelmeye başladı. çalışmıyor, bozuldum ve müşterilere geliştirmenin fiyatını yükseltmenin gerekli olduğunu yazdım, ancak bilgisayarı bırakıp çalışmadığı gerçeğinden biraz soğuyunca düzenlemeye devam etti.
Projeyi kararlaştırılan miktar için çekecek gücü kalmadığı için zamana dayalı bir ödeme teklif etti. Kaynak vermeyi teklif etmesine rağmen, akıllarına getirecek birini bulsunlar.
Aslında, başlangıçta eski TF içinde m1'i izlemem gerektiğini bilseydim, EA mantığını farklı şekilde kurardım.
Şimdi bana yapım hatası olan bir ekran göndermeleri prensibine göre çalışıyoruz, düzeltiyorum. Stratejide aslında hatırlamıyorum bile çok sayıda koşul olduğundan, tüm olasılıkları kendiniz kontrol etmenin gerçekten bir yolu yok. Hepsini birbiriyle çelişmemeleri için koordine etmek, işte asıl sorun burada. Her şey yavaş yavaş yapıldı ve müşterilerin kendileri stratejinin anlaşılmasının zor olduğunu kabul ediyorlar, ancak genel olarak, şimdi hemen hemen her şey zaten dile getirildi, ancak nasıl çalıştığını gördükten sonra doğru ya da yanlış anlayamıyorum)))
En son durduğumuz durum (müşteri temsilcisine göre bile) dikkate alınmayan bir durumdu ve şimdi bir düzine şartla daha yazmamız, araya girmemiz ve anlaşmamız gerekiyor. Bu nedenle saatlik ödemeye geçişi haklı buluyorum.
82Dmitry82, istersen seninle danışman konusunda bizzat konuşabiliriz, bağlantılarım sende. Sizin için başka bir danışman yaptım, verimliliği ve desteği takdir ettiklerini düşünüyorum, ancak bununla sabır isteyeceğim, bazen üzerinde çalışmayı erteliyorum, çünkü başka bir şeyi düzeltmeye başlamak için hangi tarafa yaklaşılacağına dair bir anlayış yok. yanlış seviye bina.
Şu anda, danışmanın 1000 satırdan fazla kodu var ve bu sadece güzel bir karmaşa ve hatta henüz ulaşılmamış siparişler olmadan bina seviyeleri.
Genel olarak, olduğundan daha da kafa karıştırıcı hale geldi.
Anladığım kadarıyla, üst yarıdaki koşulların tesadüfünü kontrol etmek gerekiyor ve eğer uyuşmuyorsa, o zaman ...
Algoritmayı doğru anladıysam, o kadar zor değil, maksimum 2-3 gün.
Şu anda, danışmanın 1000 satırdan fazla kodu var ve bu sadece güzel bir karmaşa ve hatta henüz ulaşılmamış siparişler olmadan bina seviyeleri.
1000 satır, bu arada, herhangi bir Uzman Danışmanın basit bir satırın üzerindeki ortalama boyutudur.Sanırım sorun şu ki, ortaya çıkan sorunları nasıl aşacağınızı düşünürken yanlış yöne gittiniz. Başarının %90'ı, görevi doğru formüle etmektir ve uygulanması zaten onuncu şeydir.
.
.
Aslında, başlangıçta eski TF içinde m1'i izlemem gerektiğini bilseydim, EA mantığını farklı şekilde kurardım.
.
Şu anda, danışmanın 1000 satırdan fazla kodu var ve bu sadece güzel bir karmaşa ve hatta henüz ulaşılmamış siparişler olmadan bina seviyeleri.
Sana destek olayım.
Tam olarak aynısına sahip değilim, ancak benzer bir stratejim var. Destek/direnç seviyelerini, trendi, geri dönüşleri, geri çekilmeleri ve diğer birçok şeyi harici (özel) göstergeler kullanmadan hesaba katar.
3 yıl boyunca bu stratejiyi kullanarak el değiştirdim. Bunca zaman nasıl uygulayacağımı düşündüm ve bir yıl boyunca programladım. 2000 satırdan az çıktı.
El ticareti yapmayı bilen tüm geliştiriciler, analiz için bazı çubukları temel aldıklarında daha kolay bulurlar.
Ama bar, M1 olsa bile, o zaman bu zaten geçmişte kaldı . Barlarda (özellikle eskilerde) bir tür strateji oluşturmak anlamsızdır.
Her kene işlenirken her şey yapılmalıdır.
Burada programımda (mutlak anlamda) tek bir dizi yok ve geçmişte olanları analiz etmiyorum. Ama tabii ki gerekli kontrol noktalarını gerçek zamanlı olarak hatırlıyorum (dizilerde değil).
Kısacası: Elle yapılan ve çizelgede bu kadar kolay ve güzel çizilmiş bir şeyi programlamak her zaman mümkün değildir.
Böyle bir içki gittiği için tartışmaya katılmama izin verin)))
Her şeyden önce, elbette, geliştirmedeki böyle bir gecikme için 82Dmitry82 ve ekibinin geri kalanından özür dilerim. Ben de temsilcilerine daha önce belirttiğim gibi, geliştirmeyi üstlendiğime pişman oldum, bunun benim için zor bir görev olduğunu kabul ediyorum. Görev parçalara ayrıldı, ancak ikinci aşamada TOR'un güçlü bir komplikasyonu ortaya çıktı ve aslında bir kez başladığında tamamlamaya karar verdim, ancak o kadar basit olmadığı ortaya çıktı.
Şimdi, stratejiyi açıklamadan, TK'nin karmaşıklığı gerçeğini belirtmeye çalışacağım, böylece programcı arkadaşlarım bu gerçeğin geliştirmeyi ne kadar karmaşık hale getirdiğini gerçekten takdir edebilirler.
Siparişlerin açılması gereken seviyelerin grafik yapısına dayanır. Grafiğin kenarında, tarihe atıfta bulunmadan hareket halindeyken, bu seviyeler oluşturulamaz, geçmiş birikene kadar beklemeniz veya danışmanın geçmişe dönmesini ve biraz ile grafiğin kenarına gelmesini sağlamanız gerekir. veri zaten Bu yüzden böyle yapılmasına karar verildi.
İlk başta şamdanlar üzerinde hareket ediyor, 4 parametreyi (Açık,Kapat,Yüksek,Düşük) değerlendiriyor ve şartlara göre inşaatlar yapıyor gibi görünüyorduk. Kıdemli TF'de ilk bölüm bu şekilde yapıldı (TOR, her biri farklı konstrüksiyon ve bu konstrüksiyonlar için koşullar olan 3 TF'ye bölünmüştür). İkinci TF'ye geçip aslında hazır olan ikinci bölümü test etmeye başladığımızda, hatalar ortaya çıktı ve bunların genel bir tartışması sırasında, tarihteki mumun çevrimiçi olarak izlenmesi gerektiği ortaya çıktı (yani, grafiğin kenarında sıfır gibi) ve mum hala kapalı değilken yeniden oluşturma, bu geçmişe doğru ilerlerken gerçekçi değil, çünkü aslında 4 parametre Açık, Kapat, Düşük, Yüksek.
Genel görüşme sırasında, mumun yapımını mümkün olduğunca çevrimiçi takip edebilmek için mumun derinleştirilmesi ve m1'e bölünmesi gerektiğine karar verildi (sanki grafiğin kenarında sıfır gibi). Geçmişin yapısını 4 puan olduğu gibi bırakma önerisi ve grafiğin kenarında zaten izlenecek doğru mantık (Kapat[0] kayarken) reddedildi. Müşteriler, geliştirme sürecinde ortaya çıkan bu gerçeğin TOR'u önemli ölçüde karmaşıklaştırdığını anladılar. Zaten o aşamada geliştirmeyi bırakmak istedim ama ilk aşama bittiği için ve geliştirmeyi merkezde bırakmak tamamen ilkelerimde olmadığı için devam etmeye karar verdim. Mevcut bir algoritmayı M1 boyunca koşmanız ve daha eski TF'leri izlemeniz gerektiği gerçeğine uyarlama sürecinde, bu süreçte bunun için çok fazla zaman öldürdüğüm gerçeğinden psikoz bana gelmeye başladı. Başarısız olduğum için, ayrıldım ve müşterilere geliştirme fiyatını yükseltmenin gerekli olduğunu yazdım, ancak bilgisayarı terk edip çalışmadığı gerçeğinden biraz soğuduğunda, düzenlemeye devam etti.
Projeyi kararlaştırılan miktar için çekecek gücü kalmadığı için zamana dayalı bir ödeme teklif etti. Kaynak vermeyi teklif etmesine rağmen, akıllarına getirecek birini bulsunlar.
Aslında, başlangıçta eski TF içinde m1'i izlemem gerektiğini bilseydim, EA mantığını farklı şekilde kurardım.
Şimdi bana yapım hatası olan bir ekran göndermeleri prensibiyle çalışıyoruz, düzeltiyorum. Stratejide aslında hatırlamıyorum bile çok sayıda koşul olduğundan, tüm olasılıkları kendiniz kontrol etmenin gerçekten bir yolu yok. Hepsini birbiriyle çelişmemeleri için koordine etmek, asıl sorun burada. Her şey yavaş yavaş yapıldı ve müşterilerin kendileri stratejinin anlaşılmasının zor olduğunu kabul ediyorlar, ancak genel olarak, şimdi hemen hemen her şey zaten dile getirildi, ancak nasıl çalıştığını gördükten sonra doğru ya da yanlış anlayamıyorum)))
En son durduğumuz durum (müşteri temsilcisine göre bile) dikkate alınmayan bir durumdu ve şimdi bir düzine şartla daha yazmamız, araya girmemiz ve anlaşmamız gerekiyor. Bu nedenle saatlik ödemeye geçişi haklı buluyorum.
82Dmitry82, istersen seninle danışman konusunda bizzat konuşabiliriz, bağlantılarım sende. Sizin için başka bir danışman yaptım, verimliliği ve desteği takdir ettiklerini düşünüyorum, ancak bununla sabır isteyeceğim, bazen üzerinde çalışmayı erteliyorum, çünkü başka bir şeyi düzeltmeye başlamak için hangi tarafa yaklaşılacağına dair bir anlayış yok. yanlış seviye bina.
Şu anda, danışmanın 1000 satırdan fazla kodu var ve bu sadece güzel bir karmaşa ve hatta henüz ulaşılmamış siparişler olmadan bina seviyeleri.
Açıklamadan, iyi geliştirilmiş bir teknik şartnamenin olmadığı ve görevin şuna benzediği açıktır: bana bu stratejiyi yap ve bu şekilde çalışmalı, yol boyunca tüm bunların nasıl uygulanacağını bul, böyle bir algoritma yok .
Bu durumda, bu emek yoğun bir iştir, yukarıda yazdığım gibi, programcı düşünmeye başlar ve herkesin düşünmenin kendi bedeli vardır. Bu nedenle, fiyat haklı olabilir.
işbölümü boşuna icat edilmemiştir. Müşterinin anlayışında programcı, herhangi bir fikri koda aktarabilen bir sihirbazdır. Aslında, insan nitelikleri ve yetkinlikleri her zaman sınırlıdır ve büyük şirketlerde algoritmalar oluşturan bir kişi, bir mimar ve zaten bir programcı olarak bir bölünme vardır, herkesin kendi uzmanlığı vardır. Durum bu şekilde ortaya çıktı.
Sana destek olayım.
Tam olarak aynısına sahip değilim, ancak benzer bir stratejim var. Destek/direnç seviyelerini, trendi, geri dönüşleri, geri çekilmeleri ve diğer birçok şeyi harici (özel) göstergeler kullanmadan hesaba katar.
3 yıl boyunca bu stratejiyi kullanarak el değiştirdim. Bunca zaman nasıl uygulayacağımı düşündüm ve bir yıl boyunca programladım. 2000 satırdan az çıktı.
El ticareti yapmayı bilen tüm geliştiriciler, analiz için bazı çubukları temel aldıklarında daha kolay bulurlar.
Ama bar, M1 olsa bile, o zaman bu zaten geçmişte kaldı . Barlarda (özellikle eskilerde) bir tür strateji oluşturmak anlamsızdır.
Her kene işlenirken her şey yapılmalıdır.
Burada programımda (mutlak anlamda) tek bir dizi yok ve geçmişte olanları analiz etmiyorum. Ama tabii ki gerekli kontrol noktalarını gerçek zamanlı olarak hatırlıyorum (dizilerde değil).
Kısacası: Elle yapılan ve çizelgede bu kadar kolay ve güzel çizilmiş bir şeyi programlamak her zaman mümkün değildir.
her şeyi programlayabilirsiniz ama bunun için önce bir algoritma geliştirmeniz gerekiyor ve bu işin büyük bir kısmı. Aslında gördüklerinizi önce formüllere ve mantığa çevirmeniz, sonra programlamanız gerekiyor. Ve ilki genellikle hafife alınır.
Böyle bir içki gittiği için tartışmaya katılmama izin verin)))
....
Aslında, bunu başlangıçta bilseydim ....., danışmanın mantığını farklı şekilde kurardım.
....
Tanıdık durum. Kod yazmaya başlamadan önce yapısını ve mantığını önceden planlıyorsunuz, ancak algoritma hazır ve tam olarak çalıştıktan sonra, ona başka koşullar ve yeni işlevler eklemeye başladıklarında, sonunda bir durum ortaya çıkıyor. tüm yapıyı gözden geçirmek ve tüm mantığı tamamen yeniden yazmak daha kolay, eski algoritmaya yeni bir kavram sıkıştırmaya çalışmaya devam edersiniz. Yeni işlevleri ve koşulları dikkate alarak her şeyi yeniden düşünmenin ve algoritmayı yeniden yazmanın daha kolay olduğu ortaya çıktı, ancak bu çok zaman alıyor.
" projesiz çalışmanın sonucu" için iyi bir örnek
herkes birbirinden memnun, sıfır egzoz..