মেই ভাষার সীমাবদ্ধতার কারণে, কৌশলটি JS-এ পুনরায় বাস্তবায়ন করতে হবে।
JS এর মাধ্যমে ম্যাক ভাষার কৌশল পুনরায় বাস্তবায়িত হওয়ার পর থেকে অনেক সমস্যা দেখা গেছে, বাস্তব মডেল চালানোর সময়, একই K-লাইনে, উদ্বায়ীতার কারণে, 1-2 বার কেনা-বিক্রয় ফিরে আসবে। ক্ষতির ফলে। এবং ম্যাক ভাষায় একটি AUTOFILTER বাক্য; ঠিক আছে। সম্পূর্ণরূপে নল ব্যবহার না করে, রিয়েল-টাইম মডেলগুলিতে, একই K-লাইনে ফিরে আসবে না।
প্রশ্ন হচ্ছে, মায়ের ভাষায় কীভাবে এই পরিস্থিতি এড়ানোর জন্য ডিজাইন করা হয়েছে, সাধারণ যুক্তি কী?
অথবাঃ আমি কি জেএস ব্যবহার করে একই কে-লাইনে দ্বিতীয়বার কেনা বেচা না করার কোন উপায় আছে? আপনি কি টাইমপ্যাক ব্যবহার করে সমাধান করতে চান, এবং দেখা যাচ্ছে যে অর্ডারে টাইমপ্যাক নেই, তাহলে JS এর সাথে ডেট.পার্স (new Date) ব্যবহার করে অর্ডার করার সময়, যদি অর্ডারটি সফল হয় না, বা অর্ডারটি সফল হয় না, তাহলে কীভাবে সমাধান করবেন? লজিক্যাল চিন্তাভাবনা কী?
সিয়ংলংহুইআরেকটি সমস্যা হল, নিচের কোডটি ব্যবহার করে, একই K-লাইনে একটি বিট ওঠানামা করার কারণে ক্রমাগত ট্রেডিংয়ের কারণে ক্ষতি হতে পারে তা প্রতিরোধ করা যায়। কিন্তু আরেকটি নতুন সমস্যা হল যে, একই K-লাইনে অনেকটা সমতল হওয়ার পরে, অবিলম্বে বিপরীত হাতটি খালি করতে চাইলে, এটি সীমাবদ্ধ থাকে এবং পরবর্তী K-লাইনে খালি হওয়ার জন্য অপেক্ষা করতে হয়। অথবা, একই K-লাইনে আরও বেশি হাতটি খালি হওয়ার পরে, এটিও সীমাবদ্ধ থাকে, পরবর্তী K-লাইনে খালি হওয়ার জন্য অপেক্ষা করতে হয়, যা প্রায়শই সেরা কেনার পয়েন্টটি মিস করে।
কোডটি হলঃ if (before_record_time!= now_records.Time) // পূর্ববর্তী K-রেখার সময়টি এই K-রেখার সময় ভুলের সমান নয়, তবে বিভিন্ন K-রেখার জন্য
{
//এখানে আমরা ব্রেকিং এর ব্যবসায়িক যুক্তি লিখব, তাই আমরা একই K-লাইনে বারে বারে ব্রেকিং করতে পারি না।
}
আমার সমাধান হলঃ K-রেখা টাইমলাইনে যা আগে ছিল একটি ভেরিয়েবল স্টোরেজ, এখন এটিকে দুইটি ভেরিয়েবল স্টোরেজ করা হয়েছে।
একটি মাল্টি-ডিরেকশনাল টাইমব্রেক duo_before_record_time
একটি শূন্য দিকের সময়
ঘাসচাকরির রিটার্ন।
শীতল মনK-রেখার অনুভূমিক অক্ষ হল সময়, সময় দিয়ে সমাধান করা উচিত।
সিয়ংলংহুইকোডটি হলঃ if (before_record_time!= now_records.Time) // পূর্ববর্তী K-রেখার সময়টি এই K-রেখার সময় ভুলের সমান নয়। { //এখানে আমরা ব্রেকিং এর ব্যবসায়িক যুক্তি লিখব, তাই আমরা একই K-লাইনে বারে বারে ব্রেকিং করতে পারি না। }
সিয়ংলংহুইএকটি ভাল সমাধান পাওয়া গেছে, প্রথমে একটি ভেরিয়েবল ঘোষণা করা, যা প্রতিটি অর্ডার দেওয়ার সময় বর্তমান সর্বশেষতম K লাইনটির সময়সীমা সংরক্ষণ করতে ব্যবহৃত হয় (কোনও ক্ষেত্রে খালি খোলার স্থিতিশীলতা, যতক্ষণ না অর্ডারটি এই ভেরিয়েবলটি আচ্ছাদিত করে) এবং তারপরে সিদ্ধান্ত নেওয়া হয় যে শেষবারের মতো স্থিতিশীলতার সময়সীমাটি এখনকার সর্বশেষতম K লাইনের সময়সীমার সমান নয়, যা নিখুঁতভাবে সমাধান করা যেতে পারে। পূর্ববর্তী পদ্ধতিতে বাগ রয়েছে, যেমন প্রথম K লাইনটি খোলা আছে, দ্বিতীয় K লাইনটি ভেঙে গেছে, তবে স্থিতিশীল হবে না, তৃতীয় K লাইনটি স্থিতিশীল হওয়ার আগে অপেক্ষা করতে হবে। সর্বশেষতম তুলনা ব্যবহার করে শেষবারের মতো স্থিতিশীলতার K লাইনটির সময়সীমা এবং এখনকার সর্বশেষতম K লাইনের সময়সীমার সাথে নিখুঁতভাবে সমাধান করা যেতে পারে।
সিয়ংলংহুইযাইহোক, exchange.GetOrders (().length>0 এর সাহায্যে, কোন অর্ডার নেই তা নিশ্চিত করা হয় এবং অর্ডার সময় সংরক্ষণ করা হয়।
সিয়ংলংহুইআমি কিছুক্ষণের জন্য খোঁজখবর নিয়েছিলাম, অবশেষে সমাধান পেলাম, কোডটি ছিলঃ if (Math.abs ((before_order_time - now_records.Time)/1000 > now_period)) // শেষবারের সময়সীমার সময়সীমা বিয়োগ করা হয় বর্তমান K-লাইনের সময়সীমা বিয়োগ করা হয়, 1000 দ্বারা বিভাজন করা হয় সেকেন্ডের সংখ্যা পেতে, এবং উভয়টির বিপরীতের নিখুঁত মান নেওয়া হয়, যদি সেকেন্ডের সংখ্যার চেয়ে বেশি হয় তবে একই K-লাইনে নয়। // আপনার নিজের দ্বারা ভেরিয়েবল before_order_time সেট করতে হবে, প্রতিবারের জন্য কেবলমাত্র আপনার আদেশের সময়টি সংরক্ষণ করুন। before_order_time = Date.parse ((new Date)))); // বর্তমান সময়টি রেকর্ড করুন // পিরিয়ডের সেকেন্ডের সংখ্যা, যা var now_period = _C ((exchange.GetPeriod) দ্বারা হয়); // বর্তমান পিরিয়ড, যেমন 5 মিনিট, 15 মিনিট, 1 দিন পায়, এবং ফলাফলের সংখ্যাটি সেকেন্ডে ফিরে আসে।
গ্রীষ্ম তোমাকে আঘাত করবে নাK-রেখা ডেটাতে টাইম ট্যাগ ব্যবহার করে ইন্টারসেপশন করা উচিত। একই টাইম ট্যাগ কিনা তা নির্ধারণ করা যায়।