【บันทึกการพัฒนา】เหตุใดตรรกะที่สร้างด้วย Python จึง “ถดถอย” เมื่อต้องใช้งานบน MT4

ในสถานที่พัฒนาระบบลอจิกอาจมีแรงเสียดทานเชิงโครงสร้างที่ไม่ถูกพูดถึงมากนัก นั่นคือปัญหาที่สภาพแวดล้อมการพัฒนาและสภาพแวดล้อมการส่งมอบไม่ตรงกัน ผลลัพธ์การตรวจสอบที่เห็นบนหน้าเปล่าหรือกราฟทรัพย์สินมักถูกพูดถึงมากกว่า ในทางกระบวนการพัฒนาจริงๆแล้ว “ความไม่สอดคล้องของสภาพแวดล้อม” คือส่วนที่กินเวลามากที่สุด

การตรวจสอบและใช้งานจริงในห้องทดลองส่วนใหญ่เสร็จสิ้นในสภาพแวดล้อม Python หากพิจารณาความยืดหยุ่นของการประมวลผลข้อมูล ความเร็วของการทดสอบย้อนหลัง และความสะดวกในการตรวจสอบทางสถิติ การพัฒนาทั้งหมดด้วย Python เพียงอย่างเดียวก็ถือว่าเหตุผลที่สมเหตุสมผล นอกจากนี้การค้าของห้องทดลองเองก็เรียกใช้ด้วยวิธี Drive ที่สั่งซื้อไปยังโบรกเกอร์โดยตรงจาก Python

อย่างไรก็ตามเมื่อจะส่งมอบโลจิกเป็นสินค้า กรณีนี้แตกต่างออกไป ผู้ใช้งานอัตโนมัติที่มีอยู่ในตลาดส่วนใหญ่ใช้งาน EA ในสภาพแวดล้อม MT4 หรือ MT5 นั่นหมายถึงเพื่อให้โลจิกที่พัฒนามาแล้วเสร็จสมบูรณ์จะต้องถูกถ่ายทอดไปยังภาษา/สภาพแวดล้อมการใช้งานที่แตกต่างอย่างสิ้นเชิงอย่าง MQL4/MQL5

1. สภาพแวดล้อม Python และ MT4 มีปรัชญาการออกแบบที่ต่างกันตั้งแต่ต้น

การพัฒนาใน Python ตั้งอยู่บนแนวคิดการดำเนินการเวกเตอร์ด้วยไลบรารีอย่าง pandas หรือ numpy และกรอบการทดสอบย้อนหลังทางสถิติ ในทางกลับกัน MT4/MT5 เป็นสถาปัตยกรรมแบบเหตุการณ์ขับเคลื่อนที่เรียงตาม tick และแบบจำลองการคำนวณพื้นฐานก็แตกต่างกัน

ความแตกต่างนี้ทำให้โลจิกเดียวกันที่ถูกถ่ายโอนมา มีความไม่สอดคล้องเล็กน้อยในความสามารถในการทำซ้ำของอินดิเคเตอร์ วิธีการปัดเศษค่าทศนิยมในการคำนวณ การประมวลผลคำสั่ง ฯลฯ ซึ่งเป็นข้อผิดพลาดเล็กๆ แต่มักจะเกิดจากโครงสร้างของสภาพแวดล้อมเอง ไม่ใช่จากฝีมือผู้ถ่ายถิ่น

2. ความเป็นจริงที่ว่า “สามารถเปลี่ยนถอดได้ค่อนข้างแม่นยำ แต่ยังมีบางส่วนที่ขาดหายไป”

สิ่งที่ทำให้ยุ่งยากคือการย้ายถิ่นนี้สามารถทำให้ความแม่นยำสูงพอประมาณในระดับหนึ่ง ผู้ที่ตรวจทานย้อนหลังที่ผลลัพธ์อาจดูคล้ายกันมากก็พบได้บ่อย

อย่างไรก็ดีเมื่อเจาะลึกในรายละเอียด บางส่วนของความได้เปรียบที่ตรวจสอบบนฝั่ง Python ไม่ได้ถูกจำลองอย่างแม่นยำในสภาพแวดล้อม MT4 มีกรณีที่เกิดขึ้น ซึ่งไม่ใช่การล้มละลายของโลจิกหลัก แต่เป็นการลดความบริสุทธิ์ของส่วน edge ลงเล็กน้อย ด้วยเหตุนี้ดูไม่เห็นชัดแต่หากตรวจสอบไม่ถี่ถ้วนก็อาจนำไปสู่การทำสินค้าออกมากลายเป็นจริง

3. กรณีที่การถ่ายถิ่นล้มเหลวเองและความต้องการแรงงานที่เพิ่มขึ้น

ยิ่งกว่านั้น สภาพโครงสร้างโลจิกในบางกรณีอาจทำให้การถ่ายถิ่นล้มเหลวตั้งแต่ต้น ในเงื่อนไขที่ที่การตัดสินใจเชิงเงื่อนไขและการประมวลผลทางสถิติที่สามารถแสดงออกใน Python ได้ ปรากฏในรูปแบบที่ไม่สามารถทำซ้ำใน MQL4/MQL5 ได้

กรณีเช่นนี้ไม่ใช่แค่การเขียนใหม่แบบง่ายๆ แต่ต้องออกแบบโลจิกส่วนหนึ่งใหม่ด้วยแนวทางที่ต่างออกไป ซึ่งอาจทำให้ต้องใช้งานทรัพยากรมากกว่าคาดไว้ และไม่ใช่เรื่องแปลกที่ต้องใช้เวลามากขึ้นในการพัฒนา ความหรูหราที่ปรากฏในบันทึกการพัฒนาเบื้องหน้าอบอุ่นในจริงมักซ่อนอยู่เบื้องหลังด้วยความพยายามและการลองผิดลองถูกอย่างสม่ำเสมอ

4. แม้กระท่านี้ก็ยังไม่อาจละเว้นกระบวนการนี้ได้

ดังนั้นหากมีความเสียดทานเช่นนี้ การคิดว่าจะทำให้ Python เพียงอย่างเดียวก็พอหรือไม่จึงเกิดขึ้น แน่นอนว่าการใช้งานในห้องทดลองของเราก็เป็นเช่นนั้น

แต่ผู้ที่ได้สินค้าโลจิกเข้าถึงยังมีผู้ใช้งานที่ทำการซื้อขายทุกวันใน MT4/MT5 ด้วยดังนั้นเป้าหมายที่จะแปลโลจิกเป็นสินค้าและส่งมอบให้ถึงผู้ใช้นั้นจึงไม่สามารถลดขั้นตอนการถ่ายถิ่นออกไปได้

นั่นคือกระบวนการถ่ายถิ่นไม่ใช่แค่การทำงานทั่วไป แต่เป็นขั้นตอนที่ทำให้โลจิกที่พัฒนาขึ้นนั้นสามารถใช้งานจริงได้ และความแม่นยำที่เกิดขึ้นในขั้นตอนนี้จะส่งผลต่อคุณค่าของสินค้า

ด้านหลังการพัฒนาที่ Semura Lab. กำลังเผชิญ

สำหรับ Semura Lab. การพัฒนาโลจิกด้วย Python ถือเป็นกระบวนการที่ควบคุมได้ค่อนข้างง่าย ความท้าทายที่แท้จริงคือการถ่ายถิ่นผลงานไปยังสภาพแวดล้อมที่ต่างกันอย่าง MT4/MT5 โดยไม่สูญเสียความได้เปรียบ ดังนั้นสำหรับ EA ที่ถ่ายถิ่นแล้ว เราจะทำการตรวจสอบใหม่ภายใต้เงื่อนไขเดียวกับเวอร์ชัน Python ก่อนหน้า เพื่อเปรียบเทียบความแตกต่างในการเคลื่อนไหวระหว่างทั้งสองระบบจึงขาดไม่ได้

เบื้องหลังคำว่า “การพัฒนาโลจิก” ที่ดูหรูหรานั้นยังมีความท้าทายเชิงเทคนิคที่เรียกว่ากระบวนการแปลระหว่างสภาพแวดล้อม ซึ่งเป็นเรื่องที่ดูเป็นงานธรรมดาแต่ไม่อาจหลีกเลี่ยนได้ ในบันทึกการพัฒนานี้เราจะบันทึกอย่างตรงไปตรงมาเกี่ยวกับขั้นตอนที่มักถูกมองข้ามในอนาคตด้วย