اشكالية في .. اكسبيرت تنفيذ بحسب خط على الشارت

[وضاح عطار]

قرأت الموضوع وأحببت أن أشارك بهذه الملاحظات البرمجية :

- عندما نريد عمل شرط مساواة بين رقمين من النوع دبل فإنه لا ينصح أبدا باستخدام المعامل == ... لأنه نتيجة التدوير الداخلي للقيم في المتحولات قد تنتج حالات عدم تساوي .. مع أن الرقمين متساويين أو الفرق ضئيل جدا جدا .

ومعظم لغات البرمجة وليس فقط MQL تنصح بالاستعاضة عنه بالتالي :

if(MathAbs(A-B)<رقم الحساسية المطلوب)

وفي مثالنا عن الأسعار يصبح الكود

if(MathAbs(A-B)<Point)

- يصبح استخدام NormalizeDouble مطلوبا عند إرسال سعر إلى OrderSend ويكون عبارة عن حسابات قد ينتج عنها أرقاما بعد الفاصلة أكثر من عدد الخانات الخاصة بالزوج .

لذلك نستخدم :

NormalizeDouble(Price,Digits);

[أبو نـاصر]

لم افهم يا اخي هذه الجزئية



ولله يا اخي ايضاً لم افهم جيداً من الصورة .. الصورة لزوج الدولار/ ين ولكن بسعر قديم جداً .. اظنه 2012 ؟ هل يا اخي قمت بتحميل وتحديث الاسعار لكل هذه الفترة؟ لا اظن في هذه الحالة ان الباك تسيت سيعمل بشكل سليم لان الاسعار ستكون وهمية ..

قد يكون ايضاً بسبب الفيفو FIFO فإن لم اكن مخطئاً، فهذا الحساب من شركة forex.com ؟

ما شاء الله تبارك الله

كنز معرفي

---

الشق الأول انتهت حاجته بعد رد الاستاذ وضاح


أما الباك تيست فعلا لنفس الشركة المذكورة

ولم أحدث البيانات والأسعار ابدا

لم أهتم لكون الأسعار سليمة أم لا .. لكن لماذا نفذ البيع على سعر وأغلق على سعر أقل ونتيجة الربح بالسالب

اتوقع وجود معامل آخر في المعادلة لديهم .. وليس (سعر البيع - سعر الخروج ضرب اللوت)

[أبو نـاصر]

قرأت الموضوع وأحببت أن أشارك بهذه الملاحظات البرمجية :

- عندما نريد عمل شرط مساواة بين رقمين من النوع دبل فإنه لا ينصح أبدا باستخدام المعامل == ... لأنه نتيجة التدوير الداخلي للقيم في المتحولات قد تنتج حالات عدم تساوي .. مع أن الرقمين متساويين أو الفرق ضئيل جدا جدا .

ومعظم لغات البرمجة وليس فقط MQL تنصح بالاستعاضة عنه بالتالي :

if(MathAbs(A-B)<رقم الحساسية المطلوب)

وفي مثالنا عن الأسعار يصبح الكود

if(MathAbs(A-B)<Point)

- يصبح استخدام NormalizeDouble مطلوبا عند إرسال سعر إلى OrderSend ويكون عبارة عن حسابات قد ينتج عنها أرقاما بعد الفاصلة أكثر من عدد الخانات الخاصة بالزوج .

لذلك نستخدم :

NormalizeDouble(Price,Digits);

الله عليك ما اجملك

شكرا لتشريفك


جواب بسيط أدخلنا في حلقة جديدة وهي الحساسية المناسبة

واخترت هذا

طبعا الغيت MathAbs لأني اريد البيد هو الأكبر أو يساوي .. في الشراء
فلا اريد التنفيذ تحت الخط

فما رأيك بها هل ستتناسب مع الاسعار

      if(Bid-B_Line>0.00002)

حصلنا على ناتج 0000
لأني وضعت الخط على رأس الشمعة (رقم خماسي مضبوط)

طبعا يوجد فارق بين سعر الشموع وسعر البيد

[أبو نـاصر]

بغض النظر عن السبريد العالي وشارت الدقيقة في المثال التالي

افترضت اني وضعت الخط على القمة

فبعد حدث الاختراق مباشرة

ينشئ لي باي لميت

سيكون الأمر المعلق بفارق السبريد فقط عن نقطة الاختراق


أقرب ما يكون من التنفيذ
ولا ينفذ الا بعد تحقق الحدث

اغلب من يشتري على الاختراق يضع امر معلق باي ستوب فوق القمة بفارق السبريد ( وكثيرا ما يتوسع السبريد قبل القمة بجزء من نقطة)<< مما قد يعني تنفيذ بدون اختراق فعلي

         if(Bid-B_Line>0.00002)
           {
            int ticket=OrderSend(Symbol(),OP_BUYLIMIT,Lots,B_Line,3*pips2points,0,0,Oo,Magicnumber,0,clrBlue);
                 }

[أبو نـاصر]

اسف المعادلة اصغر من وليس أكبرمن

if(Bid-B_Line<0.00002)

[أبو نـاصر]

 if(Bid-B_Line<0.00002 &&Bid-B_Line>0 )
 if(T_Line-Bid>0.00002 &&T_Line-Bid>0)

[أبو نـاصر]

طيب اساتذتي


كيف اثبت تاريخ الشمعة التي نفذ عليها الامر.. بأسهل طريقة


لأني احتاج ايجاد اي قاع ينشأ حديثا بعد الدخول .. ليتم وضع ستوب لوس تحته

[awran5]

قرأت الموضوع وأحببت أن أشارك بهذه الملاحظات البرمجية :

- عندما نريد عمل شرط مساواة بين رقمين من النوع دبل فإنه لا ينصح أبدا باستخدام المعامل == ... لأنه نتيجة التدوير الداخلي للقيم في المتحولات قد تنتج حالات عدم تساوي .. مع أن الرقمين متساويين أو الفرق ضئيل جدا جدا .

شرفنا حضورك يا استاذ وضاح .. بالفعل نقطة دقيقة وصحيحة .. بالفعل قد لا تتساوى قيم الدبل ابداً (إلا في حالات نادرة) ولكني اضيف انه يمكن استخدام المعامل == في حالة واحدة فقط هى اذا تمت المقارنة بالصفر

- يصبح استخدام NormalizeDouble مطلوبا عند إرسال سعر إلى OrderSend ويكون عبارة عن حسابات قد ينتج عنها أرقاما بعد الفاصلة أكثر من عدد الخانات الخاصة بالزوج .

اسمح لي استاذي الكريم ان اختلف مع في هذه النقطة، وأن تصححني ان كنت مخطئاً .. حتى في حالة MathAbs يمكننا تجنب استخدام NormalizeDouble وسيكون الاصح اضافة عامل قسمة .2 الى عملية المقارنة.

if(MathAbs(A-B) < Point / 2. )

حسبما اعلم، في الاساس السعر يمشي بمضاعفات النقطة وان قيمة الدبل من البروكر تقرأ على هيئة : 1.2345xxxxxxxxxxxxxx وكمثال، فإن اي مضاعفات للسعر بين 1.234575000000000000 و 1.23458499999999999 ستحدث تحت القيمة 1.23458 .. فاذا استخدمنا وظيفة NormalizeDouble فستقرب هذه الوظيفة الرقم النهائي متجاوزة بذلك عدد x من القيم مما يجعلها غير دقيقة ..

مثال:

 High[1] = 1.10289;
Low[1] = 1.10114;
 
double A = fabs(High[1] - Low[1])/2.;
 
Comment(A,"\n", NormalizeDouble(A,Digits)); 
  

سيكون الناتج :

0.0008749999999999591

والثاني بعد استخدام NormalizeDouble :

0.00088

نعم الفارق ليس كبيرا في النهاية ولكنه يبقى فارق واحياناً قد يسبب مشكلة

هذه الفكرة شرحت بالتفصيل في هذا الموضوع :

Can price != price ?

[awran5]

اخي ابو ناصر .. لما لا تضيف قيمة السبريد الى قيمة الخطوط قبل الرسم وبذلك تتجنب مشاكله؟

مثال

 Spread=MarketInfo(Symbol(),MODE_SPREAD)*pips2double;
SellWhen   = Bid-(50*pips2double)-Spread;
BuyWhen    = Ask+(50*pips2double)+Spread; 
  

لاحظ هنا ان قيمة السبريد مضروبة في معامل pips2double

مثلاً في هذه الصورة، ستجد الخطوط رسمت بدون قيمة السبريد ثم قمت باضافة القيمة الفعلية للسبريد في الخطوط الممتدة .. لاحظ الفارق ..



ويكون شرط الاختراق كالتالي ..

 if(Bid<T_Line && Ask > T_Line) 
  

لم أهتم لكون الأسعار سليمة أم لا .. لكن لماذا نفذ البيع على سعر وأغلق على سعر أقل ونتيجة الربح بالسالب

اتوقع وجود معامل آخر في المعادلة لديهم .. وليس (سعر البيع - سعر الخروج ضرب اللوت)

عموماً وعن تجربة شخصية (مازالت مستمرة) هذه الشركة من افضل شركات الفوركس حقيقية ولا يعيبها هي - وكل الشركات التي تعمل داخل امريكا - سوى موضوع FiFO واجبارك على اغلاق الصفقات بالترتيب التنازلي .. واحياناً الارتفاع الكبير في السبريد على العملات غير الرئيسية ..

وبالفعل لديهم معامل اخر هو اغلاق الصفقة اجبارياً عند الوصول الى المارجن .. اقصد هنا مارجن الصفقة وليس المارجن الكلي للحساب .. في البداية كان هذا الامر مزعجاً للغاية ولكن وجدت مع الممارسة انه على العكس، امر جيد .. فاحيانا تدخل صفقة خاسرة وقد تتركها ايام على امل الارتداد لتمتد الخسارة اكثر فأكثر وفي النهاية لا يرتد السعر فتكون الخسارة كبيرة وقد يضيع فيها الحساب كله .. ولكن اذا كانت الخسارة محددة بالمارجن فانك ستعلم - مبدئياً - اقصى حجم للخسارة وستغلق العملية تلقائياً مما يسمح لك بالدخول مجدداً في صفقات اخرى .. المهم انك ستبقى في السوق وسيبقى الحساب.

نعود للمشكلة، اعتقد ان السبب هو ال FIFO .. ولكن لابد يا اخي من عمل باك تسيت سليم اولاً لنعلم سبب المشكلة بدقة ( شهرين مثلاً)

[أبو نـاصر]

شرفنا حضورك يا استاذ وضاح .. بالفعل نقطة دقيقة وصحيحة .. بالفعل قد لا تتساوى قيم الدبل ابداً (إلا في حالات نادرة) ولكني اضيف انه يمكن استخدام المعامل == في حالة واحدة فقط هى اذا تمت المقارنة بالصفر

ايضا استاذي

قد تتساوى في حالات اخذ الرقم من المصدر كما هو وليس اثر عملية حسابية

وهو ما سبب لي الارباك

فقد سبق وأخذت الكثير من النتائج السليمة بالقارنات بين رقمين (خماسيين من المنصة)

   double A = High[1] ; 
   double B = High[2] ; 
     if (A==B)Do.....

[أبو نـاصر]

اخي ابو ناصر .. لما لا تضيف قيمة السبريد الى قيمة الخطوط قبل الرسم وبذلك تتجنب مشاكله؟

مثال

 Spread=MarketInfo(Symbol(),MODE_SPREAD)*pips2double;
SellWhen   = Bid-(50*pips2double)-Spread;
BuyWhen    = Ask+(50*pips2double)+Spread; 
  

لاحظ هنا ان قيمة السبريد مضروبة في معامل pips2double

مثلاً في هذه الصورة، ستجد الخطوط رسمت بدون قيمة السبريد ثم قمت باضافة القيمة الفعلية للسبريد في الخطوط الممتدة .. لاحظ الفارق ..



ويكون شرط الاختراق كالتالي ..

 if(Bid<T_Line && Ask > T_Line) 
  

وكما تعلم..
للاختراق لا بد من تجاوز السعر للقمة ولو بجزء من نقطة

همسة : كثيرا على الفريمات الصغيرة يتجاوز برقم خامس فقط 0.00005 للقمة ثم يضغط فيكون فرصة رائعة لي .... الشراء من اسفل

-- ان كان السبريد متغير في كل تكة فلا يمكن اضافته مع الخط .. خاصة انه يتوسع أيضا عند القمم في شركة فوركس قد يصل الى نقطة كاملة لليورو دولار (حسب اهمية القمة + الحركة القادمة)

اضفت السبريد فعليا الى الخط >>> في هدف صفقات البيع فقط (الخروج أخف خطرا من الدخول)


يبقى اخر جزئية :

وهي عندما يحدث اختراق مع انطلاقه سريعة بدون التفات للوراء .. وتكون النتيجة الغاء الأمر المعلق .. وفرصة طارت .. بمقابل ان تفعل صفقتنا فهي تفعلت على اختراق حقيقي يقينا

عموماً وعن تجربة شخصية (مازالت مستمرة) هذه الشركة من افضل شركات الفوركس حقيقية ولا يعيبها هي - وكل الشركات التي تعمل داخل امريكا - سوى موضوع FiFO واجبارك على اغلاق الصفقات بالترتيب التنازلي .. واحياناً الارتفاع الكبير في السبريد على العملات غير الرئيسية ..

وبالفعل لديهم معامل اخر هو اغلاق الصفقة اجبارياً عند الوصول الى المارجن .. اقصد هنا مارجن الصفقة وليس المارجن الكلي للحساب .. في البداية كان هذا الامر مزعجاً للغاية ولكن وجدت مع الممارسة انه على العكس، امر جيد .. فاحيانا تدخل صفقة خاسرة وقد تتركها ايام على امل الارتداد لتمتد الخسارة اكثر فأكثر وفي النهاية لا يرتد السعر فتكون الخسارة كبيرة وقد يضيع فيها الحساب كله .. ولكن اذا كانت الخسارة محددة بالمارجن فانك ستعلم - مبدئياً - اقصى حجم للخسارة وستغلق العملية تلقائياً مما يسمح لك بالدخول مجدداً في صفقات اخرى .. المهم انك ستبقى في السوق وسيبقى الحساب.

نعود للمشكلة، اعتقد ان السبب هو ال FIFO .. ولكن لابد يا اخي من عمل باك تسيت سليم اولاً لنعلم سبب المشكلة بدقة ( شهرين مثلاً)

مارجين خاص بكل صفقة .. اتمنى ان تزيدني معلومات عنها فلم اسمع بها

--

حدثت معي كثيرا ووضعت سؤالا سابقا هنا في المنتدى (الصفقة رابحة .. والربح سالب)<< ولم اجد جواب


كنت اشك بوجود معامل انعكاس الصفقة في هذا الموضوع
عموما هو ليس ذو اهمية كبيرة عندي حاليا وإنما لمجرد استئناس



------

درست كثيرا ولا زلت ادرس اتخاذ المارجين صديق

(بنسبة تسييل 100%) سيحافظ على راس المال لصفقات الفل مارجين على 15-20 نقطة تصبح رائعة (لمن هو مغامر - أو ممتلك لأدواته )

يذهب من الحساب 10% في صفقة مقابل ارباح جيدة


مثال صفقة الباوند أعلاه المارجين على بعد 70 ن من اخر عقد .. وحققت 50% من الحساب ... ديمو
هدف الموجة اختراق القمة .. والهدف الأولي اختراق أعلى شمعة الديلي

الخلاصة استخدام التسييل بديلا عن وقف الخسارة .. يمكنني من رفع اللوت لأقصى حد ممكن

لكنه سيدخلنا في حسابات معقدة أولها أن لا احد يعرف نقطة الماجين بالضبط حتى تأتي

[أبو نـاصر]

عزيزي

يتكرر الخطا هذا كل تكة

2016.02.23 02:50:57.904 AboNaser_v2 GBPUSDpro,H4: Error modifing SELL order #102785929 Error: no error, trade conditions not changed

[awran5]

كما اسلفت يا صديقى .. عندما ترسل أمر الصفقة يقوم سيرفر الشركة بحساب قيمة اجمالي الحساب وقيمة لوت الصفقة ثم يضع مارجن لهذه الصفقة بناء على نسب محددة مسبقاً وتختلف من زوج لآخر .. ستجد النسب في هذا الرابط بالاسفل .. وللعلم هذا يحدث في اي بروكر ولكن الاختلاف في الشركات الامريكية هو تفعيل الاغلاق الاجباري ..

http://www.forex.com/faqs-margin.html

على سبيل المثال، فتحت صفقة على اليورو دولار بقيمة 0.10 لوت .. على حساب ديمو برصيد 9,350 قام بحساب مارجن الصفقة بقيمة 220 دولار .. اي انه عند يصل الى 220 سيقوم بغلق الصفقة اجبارياً .. لا اعلم الحقيقة ان كانت تطبق على حسابات الديمو ولكنها تطبق على الحسابات الحقيقية ..

عزيزي

يتكرر الخطا هذا كل تكة

2016.02.23 02:50:57.904 AboNaser_v2 GBPUSDpro,H4: Error modifing SELL order #102785929 Error: no error, trade conditions not changed

عذراً يا اخي .. الخطأ خطئي، بعض شروط التحقق في وظيفتي التعديل والبريك ايفن مرتبة بشكل خاطئ ..

مرفق التعديلات

[أبو نـاصر]

كما اسلفت يا صديقى .. عندما ترسل أمر الصفقة يقوم سيرفر الشركة بحساب قيمة اجمالي الحساب وقيمة لوت الصفقة ثم يضع مارجن لهذه الصفقة بناء على نسب محددة مسبقاً وتختلف من زوج لآخر .. ستجد النسب في هذا الرابط بالاسفل .. وللعلم هذا يحدث في اي بروكر ولكن الاختلاف في الشركات الامريكية هو تفعيل الاغلاق الاجباري ..

http://www.forex.com/faqs-margin.html

على سبيل المثال، فتحت صفقة على اليورو دولار بقيمة 0.10 لوت .. على حساب ديمو برصيد 9,350 قام بحساب مارجن الصفقة بقيمة 220 دولار .. اي انه عند يصل الى 220 سيقوم بغلق الصفقة اجبارياً .. لا اعلم الحقيقة ان كانت تطبق على حسابات الديمو ولكنها تطبق على الحسابات الحقيقية ..





عذراً يا اخي .. الخطأ خطئي، بعض شروط التحقق في وظيفتي التعديل والبريك ايفن مرتبة بشكل خاطئ ..

مرفق التعديلات

اي اعتذار .. فضلك سابق


حبيبي

لم يسبق ان رأيت في الحقيقي أو الديمو
أنه يغلق الصفقة اذا نزلت عن قيمة الهامش المحجوز لها
مادام المارجين ليفيل فوق 100% لا يغلق شي <<< هذا المفترض

طيب ماذا لو دخلت مع اليورو .. بصفقة أخرى على الباوند وكسبت 1000$ ولا زالت مفتوحة
في حين اليورو خسرت 220$ هل يغلق اليورو اجباريا ؟؟
ربما هي السياسة الأمريكية لمن يعيش داخل امريكا

[أبو نـاصر]

قرأت الموضوع وأحببت أن أشارك بهذه الملاحظات البرمجية :

- عندما نريد عمل شرط مساواة بين رقمين من النوع دبل فإنه لا ينصح أبدا باستخدام المعامل == ... لأنه نتيجة التدوير الداخلي للقيم في المتحولات قد تنتج حالات عدم تساوي .. مع أن الرقمين متساويين أو الفرق ضئيل جدا جدا .

ومعظم لغات البرمجة وليس فقط MQL تنصح بالاستعاضة عنه بالتالي :

if(MathAbs(A-B)<رقم الحساسية المطلوب)

وفي مثالنا عن الأسعار يصبح الكود

if(MathAbs(A-B)<Point)

[/CODE]

للأسف استاذي لازالت الاشكالية قائمة

احيانا ينفذ وأحيانا لا ينفذ

مع اني رفعت الحساسية الى نقطة كاملة

هل من خطأ في هذا السطر

                if(T_Line-Bid<0.0001 &&T_Line-Bid>=0)