
پچھلے مضمون میں، ہم نے پروگرامیٹک ٹریڈنگ اسکرپٹس کے بارے میں بات کی تھی۔ درحقیقت، تجارتی حکمت عملی ایک ٹریڈنگ اسکرپٹ پروگرام ہے مضمون بنیادی طور پر ٹریڈنگ اسکرپٹ پروگرام (جہاں پروگرام چلتا ہے) کے لیے ہارڈویئر کیریئر کی ضرورت کے بارے میں بات کرتا ہے، اس اسکرپٹ ٹریڈنگ پروگرام کو لکھنے کے لیے کون سی کمپیوٹر پروگرامنگ زبان استعمال کی جا سکتی ہے۔ موجد مقداری تجارتی پلیٹ فارم کا استعمال یقیناً تین پروگرامنگ زبانیں ہیں، آپ پروگرامی ٹریڈنگ کے لیے حکمت عملیوں کو نافذ کرنے کے لیے کوئی بھی پروگرامنگ زبان استعمال کر سکتے ہیں)۔ اس مضمون میں، ہم cryptocurrency کے دائرے کے مقداری تجزیہ پر بحث جاری رکھیں گے اور cryptocurrency کے دائرے کے مقداری تجزیہ کے علم کو سمجھتے ہیں۔
تجارتی حکمت عملیوں کی اقسام نئے آنے والے جو پروگرامیٹک ٹریڈنگ اور مقداری تجارت میں نئے ہیں وہ مختلف اصطلاحات جیسے رجحان کی حکمت عملیوں، ثالثی کی حکمت عملیوں، اعلی تعدد کی حکمت عملیوں، گرڈ کی حکمت عملیوں وغیرہ سے الجھ سکتے ہیں۔ مندرجہ ذیل کے طور پر بیان کیا گیا ہے: کئی سمتوں.
مندرجہ بالا کو تجارتی حکمت عملیوں کے نقطہ نظر سے تقسیم کیا گیا ہے موجد مقداری تجارتی پلیٹ فارم پر حکمت عملی کے ڈیزائن کے نقطہ نظر سے، حکمت عملیوں کو بھی تقسیم کیا جا سکتا ہے:
سنگل پروڈکٹ کی حکمت عملی کہنے کا مطلب یہ ہے کہ یہ حکمت عملی صرف ایک پروڈکٹ چلاتی ہے، جیسے BTC ٹریڈنگ یا ETH ٹریڈنگ۔
کثیر مصنوعات کی حکمت عملی سیدھے الفاظ میں، یہ حکمت عملی کی منطق کے مطابق متعدد اقسام کو چلانا ہے۔
ملٹی اکاؤنٹ کی حکمت عملی سیدھے الفاظ میں، یہ ایک حقیقی ڈسک پر متعدد ایکسچینج آبجیکٹ کو ترتیب دینا ہے (تبادلے کا تصور پچھلے مضمون میں پیش کیا جا چکا ہے، اور API KEY کنفیگر کردہ ایکسچینج آبجیکٹ ایکسچینج اکاؤنٹ کی نمائندگی کرتا ہے)۔ مثال کے طور پر، کچھ کاپی ٹریڈنگ کی حکمت عملیوں میں آپریشن کے بعد متعدد اکاؤنٹس شامل ہوتے ہیں (یہ ایک ہی ایکسچینج یا مختلف ایکسچینجز ہو سکتے ہیں) ایک حقیقی اکاؤنٹ پر متعدد ایکسچینج اشیاء (اکاؤنٹس) کا انتظام کیا جاتا ہے۔
متعدد منطقی حکمت عملی مثال کے طور پر، ایک حقیقی مارکیٹ میں، MACD حکمت عملی، متحرک اوسط حکمت عملی، گرڈ حکمت عملی، وغیرہ کو ایک ہی وقت میں ڈیزائن کیا گیا ہے (یقیناً، وہ مختلف ایکسچینج اشیاء پر کام کرتے ہیں۔ اگر آپ ایک ہی ایکسچینج آبجیکٹ کو چلاتے ہیں، تو آپ کو یہ دیکھنا ہوگا کہ آیا مخصوص حکمت عملیوں میں منطقی تنازعات ہوتے ہیں)
ایکسچینج API پروگرام شدہ ٹریڈنگ سکرپٹ ایکسچینج اکاؤنٹس کو کیسے چلاتے ہیں؟ جواب ایکسچینج کے ذریعہ کھولے گئے API انٹرفیس کے ذریعے ہے۔ تو کس قسم کے انٹرفیس تبادلے کے لیے کھلے ہیں؟ پچھلے مضمون میں، ہم نے “ایکسچینج” سیکشن کے بارے میں بات کی تھی، جس میں کہا گیا تھا کہ عام طور پر ایکسچینج میں REST اور Websocket انٹرفیس ہوتے ہیں۔ یہاں ہم اسٹریٹجک پروگرام کی سطح سے کچھ تصورات شامل کرتے ہیں۔ ایکسچینج انٹرفیس کو دو قسموں میں تقسیم کیا گیا ہے: تصدیق شدہ اور غیر تصدیق شدہ، اس بات پر منحصر ہے کہ آیا وہ تصدیق شدہ ہیں یا نہیں (ریسٹ اور ویب ساکٹ دونوں)۔
ایسے انٹرفیس جن کی تصدیق کی ضرورت نہیں ہے۔
عام طور پر “عوامی انٹرفیس” کہا جاتا ہے، اس قسم کے انٹرفیس کو تصدیق کی ضرورت نہیں ہوتی ہے۔API KEY(اگر آپ بھول جاتے ہیں کہ API KEY کیا ہے، تو آپ پچھلے مضمون کا حوالہ دے سکتے ہیں)۔ اس قسم کا انٹرفیس عام طور پر مارکیٹ کا انٹرفیس ہوتا ہے، جیسے کہ مارکیٹ کی گہری معلومات کے بارے میں استفسار کرنا، K-line ڈیٹا سے استفسار کرنا، فنڈنگ کی شرحوں کے بارے میں استفسار کرنا، لین دین سے متعلق مصنوعات سے متعلق معلومات کے بارے میں استفسار کرنا، ایکسچینج سرور کے ٹائم اسٹیمپ سے استفسار کرنا وغیرہ۔
سیدھے الفاظ میں، ایک انٹرفیس جس کا آپ کے اکاؤنٹ سے کوئی تعلق نہیں ہے تقریباً ایک عوامی انٹرفیس ہونے کا تعین کیا جا سکتا ہے (کوئی تصدیق کی ضرورت نہیں)
موجد کوانٹیٹیو ٹریڈنگ پلیٹ فارم پر، غیر تصدیق شدہ API فنکشن کو کال کرتے وقت (ایکسچینج کے غیر تصدیق شدہ انٹرفیس، پبلک انٹرفیس کو شامل کرتے ہوئے)، یہاں تک کہ اگر API KEY کو غلط طریقے سے کنفیگر کیا گیا ہو، انٹرفیس کے ذریعے واپس کیا گیا ڈیٹا عام طور پر حاصل کیا جا سکتا ہے۔ (کیونکہ یہ تصدیق شدہ نہیں ہے)
انٹرفیس جن کی تصدیق کی ضرورت ہے۔ سیدھے الفاظ میں، یہ ایک انٹرفیس ہے جس کی تصدیق کی ضرورت ہے (اس قسم کے انٹرفیس کو نجی انٹرفیس کہا جاتا ہے)۔ اس قسم کا انٹرفیس عام طور پر آپ کے اکاؤنٹ کے کچھ آپریشنز یا معلومات سے متعلق ہوتا ہے، جیسے اکاؤنٹ کے اثاثوں کے بارے میں استفسار کرنا، اکاؤنٹ کی پوزیشنوں کے بارے میں استفسار کرنا، زیر التواء آرڈرز کے بارے میں استفسار کرنا، ٹرانسفر کے لیے سوال کرنا، سکے کی منتقلی، لیوریج کو ایڈجسٹ کرنا، پوزیشن کے طریقوں کو ترتیب دینا وغیرہ۔ ان کارروائیوں کی تصدیق ہونی چاہیے۔ انوینٹر کوانٹیٹیو ٹریڈنگ پلیٹ فارم پر، کسی ایسے API فنکشن کو کال کرتے وقت جس کے لیے تصدیق کی ضرورت ہوتی ہے (انٹرفیس جس کی انکیپسولیٹڈ ایکسچینج کو تصدیق کرنے کی ضرورت ہوتی ہے، پرائیویٹ انٹرفیس)، اگر API KEY کو غلط طریقے سے کنفیگر کیا گیا ہے، تو انٹرفیس کو کال کرتے وقت ایک غلطی کی اطلاع دی جائے گی اور ایک null قدر واپس آ جائے گی۔
تو یہ انٹرفیس موجد مقداری تجارتی پلیٹ فارم پر کیسے استعمال ہوتے ہیں؟
موجد مقداری تجارتی پلیٹ فارم تبادلے کے رویے کو سمیٹتا ہے اور مستقل انٹرفیس (جیسے K-line انٹرفیس، ڈیپ مارکیٹ انٹرفیس، استفسار کرنٹ اثاثہ انٹرفیس، آرڈر انٹرفیس، آرڈر واپس لینے کا انٹرفیس، وغیرہ) کی وضاحت کرتا ہے۔ موجد مقداری تجارتی پلیٹ فارم API دستاویزات (https://www.fmz.com/api) سے استفسار کر کے دیکھا جا سکتا ہے۔
تو موجد مقداری تجارتی پلیٹ فارم پر متضاد رویوں اور تعریفوں کے ساتھ کچھ ایکسچینج انٹرفیس کا استعمال کیسے کریں؟
ان ایکسچینج انٹرفیس میں شامل ہیں: اثاثہ کی منتقلی، مشروط تفویض، بیچ آرڈر کی جگہ کا تعین، بیچ آرڈر کی منسوخی، آرڈر میں ترمیم، وغیرہ۔ کچھ ایکسچینجز میں یہ انٹرفیس ہوتے ہیں، جبکہ دیگر میں ان کے افعال اور استعمال کی تفصیلات بہت مختلف ہوتی ہیں، لہذا یہ انٹرفیس انوینٹر کوانٹیٹیو ٹریڈنگ پلیٹ فارم پر دستیاب ہیں۔exchange.IOاس فنکشن کو رسائی کے لیے استعمال کیا جاتا ہے (تفصیلات کے لیے، براہ کرم Inventor Quantitative Trading Platform API دستاویز دیکھیں: https://www.fmz.com/api#exchange.io…)۔ Inventor Quantitative Trading Platform Strategy Square پر کچھ عملی IO مثال کی حکمت عملییں بھی ہیں۔
کیا Inventor Quantitative Trading Platform API دستاویزات میں تمام API افعال نیٹ ورک کی درخواستیں تیار کرتے ہیں؟
سب سے پہلے یہ کہتے ہیں کہ ایکسچینج API انٹرفیس تک رسائی کی فریکوئنسی کی حد ہے (مثال کے طور پر، 5 بار فی سیکنڈ تک رسائی بہت زیادہ نہیں ہوسکتی ہے، بصورت دیگر یہ HTTP 429 کی خرابی کی اطلاع دے گا اور رسائی سے انکار کرے گا (زیادہ تر ایکسچینجز 429 کی غلطی کی اطلاع دیتے ہیں)۔ )۔ یہی حد انوینٹر کوانٹیٹیو ٹریڈنگ پلیٹ فارم پر پیکڈ ایکسچینج انٹرفیس کو کال کرنے پر بھی لاگو ہوتی ہے، موجد کوانٹیٹیو ٹریڈنگ پلیٹ فارم پر ایسی کوئی حد نہیں ہے جو نیٹ ورک کی درخواستیں تیار نہیں کرتے ہیں۔ انوینٹر کوانٹیٹیو ٹریڈنگ پلیٹ فارم کے تمام API فنکشنز نیٹ ورک کی درخواستیں تیار نہیں کریں گے، انوینٹر کے کچھ API فنکشنز صرف کچھ مقامی سیٹنگز میں ترمیم کرتے ہیں، جیسے کہ موجودہ تجارتی جوڑی کو سیٹ کرنا، کنٹریکٹ کوڈ کی ترتیب، اشارے کیلکولیشن فنکشن، ایکسچینج آبجیکٹ کا نام حاصل کرنا، وغیرہ بنیادی طور پر، آپ یہ فیصلہ کر سکتے ہیں کہ آیا نیٹ ورک کی درخواست فنکشن کے مقصد سے ہوتی ہے، جب تک کہ یہ ایکسچینج اکاؤنٹس وغیرہ پر کام کرتی ہے، ان انٹرفیس پر توجہ دینے کی ضرورت ہے۔ کال کرنے کی فریکوئنسی
آئیے انوینٹر کوانٹیٹیو ٹریڈنگ پلیٹ فارم میں API فنکشنز استعمال کرتے وقت کچھ عام مسائل اور تجربات کے بارے میں بات کرتے ہیں۔

حکمت عملی لکھتے وقت، ہمیں انٹرفیس کے ذریعے واپس کیے گئے ڈیٹا کو جانچنے اور اس کی تصدیق کرنے کی ضرورت ہوتی ہے، مثال کے طور پر، کوڈ کی اس لائن کو انوینٹر کوانٹیٹیو ٹریڈنگ پلیٹ فارم پر مارکیٹ کی معلومات حاصل کرنے کے لیے استعمال کیا جاتا ہے۔ انٹرفیس):var ticker = exchange.GetTicker()اگر ہمیں اسے استعمال کرنے کی ضرورت ہے۔tickerمتغیر (GetTicker فنکشن کے ذریعہ واپس کردہ ڈھانچہ دیکھیں)Last(تازہ ترین قیمت) ڈیٹا، ہمیں استعمال کرنے کی ضرورت ہے۔var newPrice = ticker.Lastاس طرح ڈیٹا حاصل کریں (نئی قیمت کیا ہے؟ نئی: تازہ ترین، قیمت: قیمت، جی ہاں! انہیں ایک ساتھ رکھیں!) اس وقت، اگرGetTicker()یہ ٹھیک ہے اگر فنکشن نارمل ڈیٹا لوٹاتا ہے، لیکن اگر درخواست کا وقت ختم ہوجاتا ہے، نیٹ ورک کی خرابیاں ہوتی ہیں، ایکسچینج نیٹ ورک کیبل کو ان پلگ کرتا ہے، کیبل کٹ جاتی ہے، ایک شرارتی بچہ پاور سوئچ کھینچتا ہے، وغیرہGetTicker()فنکشن ریٹرنnull. اس وقتtickerکی قدر ہےnullمیں اس کا دوبارہ دورہ کروں گا۔Lastپروگرام میں استثناء واقع ہو گا، جس کی وجہ سے پالیسی پروگرام رک جائے گا۔
ایسا لگتا ہے کہ انٹرفیس کال کی ناکامی (GetTicker کال ناکام ہوگئی اور null واپس آئی) حکمت عملی کے حقیقی تجارتی بند ہونے کی براہ راست وجہ نہیں ہے (براہ راست وجہ ایک تک رسائی ہےnullمتغیر خصوصیات)، انٹرفیس کال کی ناکامی اور غلطی حقیقی تجارت کو روکنے کا سبب نہیں بنے گی (زور دیا گیا)۔
تو حقیقی تجارت کی غیر معمولی معطلی سے بچنے کے لیے ہم کیا کر سکتے ہیں؟
جواب یہ ہے کہ انٹرفیس کے ذریعے واپس کیے گئے ڈیٹا پر فالٹ ٹولرنس پروسیسنگ کی جائے، یہ صرف یہ طے کرنا ہے کہ آیا واپس کیا گیا ڈیٹا ہے۔null(جاوا اسکرپٹ کو بطور مثال استعمال کیا جاتا ہے، دوسری زبانیں بنیادی طور پر ایک جیسی ہیں)
وضاحت کرنے کے لیے ایک چھوٹا کوڈ کا ٹکڑا لکھیں (یہ صرف ایک وضاحت ہے، اگر آپ اسے براہ راست چلاتے ہیں تو یہ کام نہیں کرے گا!)
var ticker = exchange.GetTicker()
if (ticker) {
var newPrice = ticker.Last
Log("打印最新价格:", newPrice)
} else {
// 数据为null,不做操作就不会出问题
}
نہ صرفGetTickerانٹرفیس کو غلطی برداشت کرنے کی ضرورت ہے نیٹ ورک کی درخواستوں کے ساتھ تمام انٹرفیس کو واپسی کی قدروں کے لیے غلطی برداشت کرنے کی ضرورت ہے (اگر آپ فنکشن کی واپسی کی قدر استعمال کرتے ہیں)۔
غلطیوں کو برداشت کرنے کے بہت سے طریقے ہیں، آپ استعمال کر سکتے ہیں۔_C()فنکشن (FMZ API دستاویزات دیکھیں)، اپنا فالٹ ٹولرنٹ فنکشن لکھیں، اور اپنا فالٹ ٹولرنٹ میکانزم اور منطق ڈیزائن کریں۔
کے بارے میں_C()فنکشنز استعمال کرتے وقت، بہت سے نئے طلباء کے غلط طریقے سے استعمال کرنے کا امکان ہوتا ہے۔_C()فنکشن پیرامیٹرز فنکشن حوالہ جات ہیں، فنکشن کالز نہیں۔ سادہ الفاظ میں:
_C(funcName, param1, param2)، کال درست ہے، funcName میں قوسین نہیں ہیں، param1 اور param2 وہ پیرامیٹرز ہیں جنہیں funcName فنکشن میں منتقل کیا جانا ہے۔
_C(funcName(param1, param2))کال ایرر، عام طور پر نئے آنے والے جو FMZ API دستاویزات کو غور سے نہیں پڑھتے ہیں وہ اسے اس طرح لکھیں گے۔
LTC_USDT function main() {
exchange.IO("simulate", true) // 切换为OKEX交易所的模拟盘
exchange.Buy(-1, 1) // 价格是-1,表示下的订单为市价单,数量为1表示下单量是1USDT
}
چونکہ ایکسچینجز میں عام طور پر آرڈر کی رقم کی حد ہوتی ہے، اس لیے حد سے کم آرڈرز جمع نہیں کیے جائیں گے (مثال کے طور پر، Binance سپاٹ کا تقاضا ہے کہ ہر آرڈر کامیابی کے ساتھ جمع کروانے کے لیے 5 USDT سے زیادہ ہو)۔ لہذا اس طرح کا آرڈر دینے سے ایک خرابی ہو گی:
错误 Buy(-1, 1): map[code:1 data:[map[clOrdId: ordId: sCode:51020 sMsg:Order amount should be greater than the min available amount. tag:]] msg:]

چونکہ آرڈر کی تقریب صرف ہے۔Buy,Sell. تاہم، فیوچرز (یقیناً، اسپاٹ کے ساتھ کوئی مسئلہ نہیں ہے، اسپاٹ میں صرف خرید و فروخت ہوتی ہے) میں لمبا کھلنا، لمبا بند ہونا، مختصر کھولنا، اور مختصر بند ہونا ظاہر ہے، بہت سی سمتوں میں کام کی نمائندگی نہیں کر سکتا اس وقت، اس فنکشن کی ترتیب کو متعارف کرانا ضروری ہے۔exchange.SetDirection()。
ایف ایم زیڈ پر
exchange.SetDirection("buy")(سب سے پہلے سمت متعین کریں) اورexchange.Buyجب ایک ساتھ استعمال کیا جاتا ہے، تو اس کا مطلب ہے کہ دیا گیا آرڈر ایک لمبی پوزیشن کھولنے کا آرڈر ہے۔
اور اسی طرح:
exchange.SetDirection("sell")اورexchange.Sellجب ایک ساتھ استعمال کیا جاتا ہے، تو اس کا مطلب ہے کہ دیا گیا آرڈر ایک مختصر پوزیشن کھولنے کا آرڈر ہے۔
exchange.SetDirection("closebuy")اورexchange.Sellجب ایک ساتھ استعمال کیا جاتا ہے، تو اس کا مطلب ہے کہ دیا گیا آرڈر ایک لمبی پوزیشن کو بند کرنے کا حکم ہے۔
exchange.SetDirection("closesell")اورexchange.Buyجب ایک ساتھ استعمال کیا جائے تو اس کا مطلب ہے کہ دیا گیا آرڈر ایک مختصر پوزیشن کو بند کرنے کا حکم ہے۔
عام طور پر newbies کرے گاexchange.SetDirection("sell")اورexchange.Buyدوسروں کے ساتھ مل کر استعمال کیا جاتا ہے، یا دیگر غلط مجموعہ. پھر اس نے ایک غلطی کی اطلاع دی (بیک ٹیسٹنگ غلطی کی اطلاع نہیں دے سکتی ہے، لیکن یہ ظاہر ہے کہ ایک منطقی غلطی ہے، اور جنونی مجبوری عارضے میں مبتلا افراد اسے برداشت نہیں کر سکتے…)۔
newbies کی طرف سے کی گئی ایک اور عام غلطی
function main() {
exchange.SetContractType("quarter") // 设置当前合约为季度合约
exchange.SetDirection("sell")
var id = exchange.Sell(-1, 1)
Log("看我市价单下单了,成交了,就有持仓了", exchange.GetPosition())
exchange.SetDirection("closebuy") // closebuy 和Sell 搭配使用,嗯没错~
exchange.Sell(-1, 1)
}

اسے دیکھ کر، آپ پوچھ سکتے ہیں: “میرے پاس پوزیشن کیوں ہے اور کلوز بائی اور سیل ایک ساتھ کیوں استعمال کرتا ہوں، لیکن اس سے ایک خرابی ہوتی ہے اور میں پوزیشن کو بند نہیں کر سکتا؟” میں جواب دوں گا: “میں نے غلط سمت بند کردی! میں نے لمبی پوزیشن بند کردی۔”
مندرجہ بالا خرابی کے لیے ایک اور ممکنہ صورت حال یہ ہے کہ: اختتامی سمت درست طریقے سے سیٹ کی گئی ہے، آرڈر فنکشن کو صحیح طریقے سے استعمال کیا گیا ہے، اور پوزیشن اس سمت میں رکھی گئی ہے، لیکن یہ غلطی اب بھی رپورٹ کی جاتی ہے۔
اس کی وجہ یہ ہے کہ آپ کے پروگرام نے متعدد آرڈرز دیے ہوں گے، لیکن ابتدائی آرڈر پر عمل نہیں ہوا تھا، اور اختتامی آرڈر پر عمل درآمد کے انتظار میں تھا، اس وقت، پروگرام پوزیشن کو بند کرنا جاری رکھے گا، اور یہ فوری طور پر ظاہر ہوگا۔ اختتامی پوزیشن سے تجاوز کرنے کی غلطی۔
print。
جاوا اسکرپٹconsole.log。
گولانگfmt.Println()。
C++coutآئیے FMZ پلیٹ فارم پر ظاہر ہونے والی معلومات کے بارے میں بات کرتے ہیں انوینٹر کوانٹیٹیو ٹریڈنگ پلیٹ فارم پر، دو اہم مقامات ہیں جہاں معلومات ظاہر ہوتی ہیں۔
- اسٹیٹس بار
اصلی ڈسک چلنے کے بعد، اصلی ڈسک کا صفحہ جیسا کہ تصویر میں دکھایا گیا ہے۔

ڈسپلے کا حصہ اسٹیٹس بار کی معلومات ہے، اسٹیٹس بار کو بنیادی طور پر کچھ ریئل ٹائم تبدیل کرنے والے ڈیٹا کو ظاہر کرنے کے لیے استعمال کیا جاتا ہے (کیونکہ ریئل ٹائم تبدیلیوں کو ریئل ٹائم میں دیکھا جانا ضروری ہے، اور وہ ہر بار لاگ میں پرنٹ نہیں کیے جا سکتے، اس لیے اس قسم کی اسٹیٹس بار میں اعداد و شمار کو ظاہر کیا جا سکتا ہے اگر ہر ایک کو پرنٹ کیا جائے تو لاگ میں بہت زیادہ بار بار اور بے معنی ڈیٹا ہوگا، جو استفسار کو متاثر کرے گا)۔
اسٹیٹس بار پر ڈیٹا کا استعمال دکھائیں۔`LogStatus`فنکشن، تفصیلات کے لیے براہ کرم FMZ کے API دستاویزات سے رجوع کریں۔
- لاگ کالم
اصلی مارکیٹ پیج پر بھی، جیسا کہ تصویر میں دکھایا گیا ہے:

ڈسپلے کا حصہ لاگ بار ہے، جو بنیادی طور پر کسی خاص لمحے میں مخصوص ڈیٹا کو مستقل طور پر ریکارڈ کرنے کے لیے، یا کسی خاص وقت پر کسی حکمت عملی کے مخصوص آپریشن کو ریکارڈ کرنے کے لیے استعمال ہوتا ہے۔
نوشتہ جات کی کئی قسمیں ہیں:
1. عام لاگ: FMZ حکمت عملی لاگ فنکشن کا استعمال اسٹریٹیجی لاگ میں آؤٹ پٹ اور پرنٹ کرنے کے لیے کرتی ہے۔

2. آرڈر لاگ، FMZ حکمت عملی میں استعمال ہوتا ہے۔`exchange.Sell`/`exchange.Buy`یہ خود بخود لاگ آؤٹ پٹ میں ریکارڈ ہو جائے گا۔

3. آرڈر کینسلیشن لاگ، جو FMZ حکمت عملی میں استعمال ہوتا ہے۔`exchange.CancelOrder`، آرڈر کینسلیشن لاگ خود بخود لاگ میں آؤٹ پٹ ہو جائے گا۔

4. ایرر لاگ جب FMZ حکمت عملی چل رہی ہو، اگر نیٹ ورک کی درخواست کے لیے انٹرفیس میں کال کی خرابی واقع ہو جاتی ہے یا کوئی استثنیٰ پھینک دیا جاتا ہے (جیسے تھرو جیسا بیان)، تو ایک ایرر لاگ خود بخود لاگ میں آ جائے گا۔

FMZ API فنکشنز جو لاگ آؤٹ پٹ جنریٹ کر سکتے ہیں، جیسے Log(…), exchange.Buy(price, Amount), exchange.CancelOrder(Id) وغیرہ، مطلوبہ پیرامیٹرز کے بعد کچھ اضافی آؤٹ پٹ پیرامیٹرز کے ذریعے چل سکتے ہیں، جیسے: کینسل آرڈر (آرڈرز[j].Id, orders[j]) یہ آرڈرز منسوخ کر رہا ہے۔[j] یہ آرڈر دیتے وقت، آرڈر کی معلومات آؤٹ پٹ ہوگی۔
function main() {
Log("数据1", "数据2", "数据3", "...")
var data2 = 200
var id = exchange.Sell(100000, 0.1, "附带数据1", data2, "...")
exchange.CancelOrder(id, "附带数据1", data2, "...")
LogProfit(100, "附带数据1", data2, "...")
}
JavaScriptحسابی اشارے کا ڈیٹا پرنٹ کرتے وقت زبان کی حکمت عملی ظاہر کی جائے گی۔null。اسٹریٹجی اسکوائر پر ایک تدریسی مثال ہے: https://www.fmz.com/strategy/125770 اس ٹیوٹوریل مثال کی حکمت عملی کی بیک ٹیسٹنگ کرتے ہوئے، آپ بیک ٹیسٹنگ سسٹم کے ذریعے تیار کردہ چارٹ اور 10 مدت کی حرکت اوسط دیکھ سکتے ہیں:

حکمت عملی اپنی مرضی کے مطابق ڈرائنگ، تیار کردہ K-لائن اور موونگ ایوریج چارٹ:

سوال: اگر میں 10 گھنٹے کی موونگ ایوریج چاہتا ہوں تو کیا ہوگا؟ جواب: K-line ڈیٹا گھنٹے کی مدت کے K-line ڈیٹا کو استعمال کر سکتا ہے۔
عام آدمی کی اصطلاح میں، K-لائن جو ہم دیکھتے ہیں وہ ایک صف ہے جب ہم اسے ڈیجیٹائز کرتے ہیں (اگر آپ سرنی کے تصور کو نہیں سمجھتے ہیں، تو آپ Baidu پر تلاش کر سکتے ہیں)، جس میں ہر عنصر ایک K-line کالم ہے، جو ترتیب دیا گیا ہے۔ ترتیب میں پہلا عنصر موجودہ وقت سے سب سے دور ہے، اور صف کا آخری عنصر موجودہ وقت کے قریب ترین ہے۔ عام طور پر K-line ڈیٹا کی آخری بار موجودہ مدت کی بار ہوتی ہے، جو حقیقی وقت میں تبدیل ہوتی ہے اور نامکمل رہتی ہے (آپ ایکسچینج کے صفحہ میں لاگ ان کرکے اور اس کی K-لائن کو دیکھ کر تبدیلیوں کا مشاہدہ کر سکتے ہیں)۔ کیلکولیٹڈ انڈیکیٹرز بھی K-لائن بارز سے مطابقت رکھتے ہیں، اوپر کی مثال میں آپ دیکھ سکتے ہیں کہ ایک انڈیکیٹر ویلیو ایک K-لائن بار سے مساوی ہے۔ نوٹ کریں کہ آخری K- لائن کالم حقیقی وقت میں تبدیل ہوتا ہے، اور حسابی اشارے بھی K- لائن کالم میں ہونے والی تبدیلیوں کے ساتھ بدل جائیں گے۔
موجد کوانٹیٹیو ٹریڈنگ پلیٹ فارم پر، آپ TA لائبریری (ایف ایم زیڈ پلیٹ فارم کے ذریعے لاگو کردہ ایک لائبریری، جس کو کسٹوڈین میں مربوط کیا گیا ہے، اور مختلف زبانوں میں براہ راست استعمال کیا جا سکتا ہے) یا طالب لائبریری (طالب ایک اچھی طرح سے قائم انڈیکیٹر لائبریری ہے،) استعمال کر سکتے ہیں۔ JS اور C++ کے ساتھ مربوط ہے، اور ازگر کو خود لکھنے کی ضرورت ہے) انسٹال کریں)۔ مثال کے طور پر، اوپر کی مثال میں، متحرک اوسط کا حساب لگایا جاتا ہے: TA لائبریری کا استعمال:
function main() {
var records = exchange.GetRecords()
var ma = TA.MA(records, 10)
Log(ma) // 打印均线
}
طالب لائبریری کا استعمال:
function main() {
var records = exchange.GetRecords()
var ma = talib.MA(records, 10)
Log(ma) // 打印均线
}
کیلکولیٹڈ انڈیکیٹر ڈیٹا ایم اے ایک سرنی ہے، جس کا ہر عنصر K-line ارے (ریکارڈز) سے مساوی ہے، یعنی،ma[ma.length -1]مطابقتrecords[records.length - 1]، اور اسی طرح.
اسی طرح دوسرے پیچیدہ اشارے پر بھی لاگو ہوتا ہے آپ کو MACD جیسے اشارے پر توجہ دینے کی ضرورت ہے۔
var macd = TA.MACD(records) // 这样只传入K线数据,不传入指标参数,指标参数采用的就是默认值,其它指标函数也是同理
اس وقت، متغیر macd ایک دو جہتی صف ہے (اگر آپ تصور کو نہیں سمجھتے ہیں، تو آپ Baidu پر تلاش کر سکتے ہیں، ایک دو جہتی سرنی ایک صف ہے اور اس کا ہر عنصر بھی ایک سرنی ہے)۔ . سوال: macd انڈیکیٹر ڈیٹا دو جہتی صف کیوں ہے؟ جواب: کیونکہ MACD انڈیکیٹر دو لائنوں (DIF لائن اور DEA لائن) اور والیوم بارز کے ایک سیٹ پر مشتمل ہے (MACD والیوم بار، درحقیقت، اس والیوم بار کے ڈیٹا کو بھی ایک لائن کے طور پر شمار کیا جا سکتا ہے)۔ لہذا macd متغیر کو اس میں تقسیم کیا جاسکتا ہے:
var dif = macd[0]
var dea = macd[1]
var macdColumn = macd[2]
یہاں ایک ریڈی میڈ تدریسی مثال بھی ہے، اگر آپ دلچسپی رکھتے ہیں تو براہ کرم اس کا مطالعہ کریں: https://www.fmz.com/strategy/151972
