On Becoming A Quant

دانستن best practices در هر زبان یا فریمورکی کمک می‌کنه بتونیم کدهای بهتری بزنیم و بدون هزینه زمانی، تجربه کسب کنیم. تو مخزن زیر راجع به best practices در fastAPI نکات خوبی گفته شده. از ساختار کلی پروژه گرفته تا جزئیات مختلفی که می‌تونه یک پروژه fastAPI داشته باشه. 👇👇 https://github.com/zhanymkanov/fastapi-best-practices @quant_fin

تجربه‌های کاری به عنوان نمونه می‌تونید تجربه‌های کاری که آدم‌ها (غالبا به صورت ناشناس) راجع به کاریزما (احتمالا بخش پردازش اطلاعات مالی‌شون) نوشتن رو هم بخونید؛ بامزه‌ و تعجب برانگیزه :))) https://tajrobe.github.io/%DA%A9%D8%A7%D8%B1%DB%8C%D8%B2%D9%85%D8%A7/

#آگهی_شغلی برای یک موقعیت شغلی quantitative analyst نیاز به توسعه‌دهنده پایتونی هست که تجربه توسعه API و کار با داده‌های مالی رو داشته باشه. کار به صورت تمام وقت و حضوری (در تهران) است و رنج حقوقی از ۲۰ به بالاست. اگر علاقه‌مند بودید، رزومتون رو هرچه سریعتر و نهایتا طی چند روز آتی به p.masoud.ghahremani@gmail.com ارسال کنید.

🅾 مرور بر چند تجربه فنی در توسعه یک سامانه اجرای سفارشات الگوریتمی (داده‌ها) در این سلسله متن که احتمالا شامل چند قسمت خواهد بود و در آینده هم تکمیل میشه؛ قصد دارم تجربیاتی که طی توسعه یک سامانه اجرای سفارشات الگوریتمی کسب کردم رو بازگو کنم. به این امید که هم انتقال تجربه باشه و هم اگر دوستان نظری داشته باشند ازشون یاد بگیرم. چیستی و نیازمندی‌ها بحث اجرای سفارشات (order execution) کلا از جهات زیادی با تصور رایجی که راجع به معاملات الگوریتمی وجود داره، متفاوته. لزوما خبری از اون استراتژی‌های میانگین متحرک، مک دی و چیزهایی که معمولا تو کتاب‌ها می‌نویسند؛ نیست. معمولا ما در این حوزه دنبال پیدا کردن دارایی خوب از بین چند دارایی موجود نیستیم بلکه فرض بر اینه که ما دارایی مورد نظر رو انتخاب کردیم و صرفا هدفمون چیزهایی مانند خرید/فروش بهینه، نوسان‌گیری درون‌روزی، بازارگردانی و ... است. پس شاید خیلی اوقات این سوال که «این الگوریتمی که نوشتی چقدر سود میده؟!» تو این حوزه آنچنان سوال مرتبطی نباشه (مگر اینکه واقعا هدفمون کسب سود باشه) چون خیلی اوقات هدف بیشتر مدیریت زمان معامله‌گران است. پس همین اول راه، نیازمندی‌ها و انتظارات ما از سایر شاخه‌های این حوزه مانند انتخاب سبد بهینه و ... جدا میشه. این جدایی بحث جدی هست چون تاثیر زیادی تو سطح داده‌های مورد استفاده، مدل‌سازی و حتی ابزار های فنی که قراره ازشون استفاده کنیم میذاره. فرقی نمی کنه بازار بورس خودمون باشه یا رمز ارز یا فارکس یا مشتقه یا ...؛ چیزهایی که اینجا راجعشون قراره بنویسم قابل تعمیم به همه بازارها هستند. داده‌ها داده‌هایی که معمولاً برای بحث اجرای سفارشات با آنها روبرو هستیم داده‌های درون روزی و آنی (real time) هستند. فراوانی زیاد و تغییرات سریع، مشخصه اصلی این نوع داده‌ها است. فرض کنید الگوریتم ما نیاز داره در هر لحظه، دفتر سفارشات (limit order book) یا قیمت ۵ معامله اخیر بیت کوین رو داشته باشه؛ آیا باید روی endpintی که این سرویس رو میده، متد GET رو تو یک حلقه بی‌نهایت مدام صدا بزنیم تا دیتامون در هر لحظه به‌روز باشه؟ خب قطعا پاسخ خیر هست و همه میدونیم که HTTP یک پروتکل بی‌حافظه(stateless) هست که برای هر بار ایجادش سربار برقراری ارتباط وجود داره که این برای کاربرد مورد نظر ما که نسبت به تاخیر (latency) حساس هستیم مناسب نیست. معمولا برای کاربردهای real time ی مانند همینجا یا برنامه‌هایی مثل چت یا بازی‌ از پروتکل ارتباطی websocket استفاده میشه و شما خواهید دید که صرافی‌ها یا OMS ها معمولا برای ارسال داده هایی مثل معاملات لحظه‌ای و دفتر سفارشات از همین پروتکل استفاده می‌کنند.(همچنین ببینید signalR) بعد از برقراری ارتباط و دریافت سریع و بهینه داده‌ها، بحث پردازش و استفاده از اون‌هاست. اما قبل از استفاده دیتاها توسط الگوریتم، لازمه اونهارو در جایی ذخیره کنیم. قبلا تو مطلبی نوشتم که چون ذخیره دائمی این دیتاها برامون اهمیت نداره و بیشتر خوندن/نوشتن سریع اونها برامون مهمه؛ ردیس (Redis) می‌تونه کمکمون کنه. چون دیتا هارو تو مموری نگه می‌داره. هر چند که دیدم خیلی از شرکت‌های غالبا غیر ایرانی از kdb+ هم استفاده می‌کنند که چیز جالبی به نظر میرسه اما فکر میکنم اوپن سورس نیست و من ازش استفاده نکردم. تا اینجای کار ما خوراک اولیه الگوریتم رو تامین کردیم :) بقیه داستان شامل چیزهای دیگه میشه که در قسمت های بعدی راجعشون خواهم نوشت. بیست و پنجم تیر دو مسعود قهرمانی @quant_fin

آپدیت جدید سایت tse.ir انقدر خوبه که من دیگه nmt 😂 بهتره: ۱. رابط کاربریش رو بهتر کنن. کسی که اولین بار وارد سایت میشه و مثلا میخواد وضعیت نماد های بازار مشتقه رو ببینه یه دور باید کل گزینه های موجود رو بچرخه. ۲. تو ورژن قبلی برای چند endpoint پرکاربرد response time بالایی وجود داشت و کماکان هم وجود داره. ۳. ظاهر کاربریش هم چنگی به دل نمیزنه. مثلا https://newsite.tse.ir/instrument/view?cat=cash&id=IRO9TAMN2611 انگار pure html ده سال پیشه. البته با گوشی که کلا داغون نشون میده :)

#مروری_بر_ادبیات_معاملات_الگوریتمی مخزن زیر شامل توضیحات خوب و همراه با کد پایتون راجع به مدل های market impact و همچنین هزینه معاملات (transaction costs) است. https://github.com/quantopian/research_public/blob/master/notebooks/lectures/Market_Impact_Model/notebook.ipynb

پاندرا (pandera) کتابخانه ای برای صحت سنجی محتوای dataframe ها. خیلی وقتا لازمه که ما برای فرمت یک ستون از دیتافریم یا حتی برای مقادیرش محدودیت قرار بدیم. مخصوصا به صورت خودکار و برای جاهایی که ماجرا حساس و حیاتی است. pandera دقیقا این کار رو انجام میده. اطلاعات بیشتر: https://pandera.readthedocs.io/en/stable/

🅾 کد نویسی تمیز (اصل تک مسئولیتی) ✅ یکی از بدترین کارهایی که ما معمولا موقع نوشتن یک تابع یا کلاس انجام میدیم؛ نقض Single Responsibility Principle (SRP) یا همون اصل تک مسئولیتی است. این اصل میگه که هر کلاس یا تابع شما باید مسئول انجام یک و فقط یک کار باشه و اون رو به بهترین شکل انجام بده. اما به دلایل زیادی ما معمولا ترجیحمون اینه که این قانون رو ناخواسته نقض کنیم. ✅ مثلا فرض کنید من یک تابعی به اسم fetch_lob دارم که دفتر سفارشات لحظه ای یک نماد رو به صورت دیتا فریم برمی گردونه. حالا اگر بخوام یه تابع جدید بنویسم که قیمت یک سفارش رو با توجه به این دفتر سفارشات انتخاب می کنه؛ احتمالا یه همچین چیزی مینویسم که تابع، اول بره دفتر سفارشات رو بگیره بعد با توجه به اون، قیمت رو انتخاب کنه: def first_function() -> int:     lob = fetch_lob()     # select price logic     ... ✅ خب این تابع داره دو کار رو انجام میده: ۱. گرفتن دفتر سفارشات ۲. پیاده سازی منطق انتخاب قیمت این درست نیست. چون این تابع فقط باید کار دوم رو انجام بده و دفتر سفارشات رو خودمون به این تابع بدیم. یعنی def second_function(lob: pd.DataFrame) -> int:     # select price logic     ... اینطوری این تابع تمرکزش فقط روی پیاده سازی منطق انتخاب قیمت خواهد بود. حالا چرا ما باید SRP رو رعایت کنیم؟ دلایل زیادی هست: 1⃣ تست و نگهداری: عیار یک کد خوب زمانی مشخص میشه که شما دارید براش تست خودکار مینویسید. به تابع first_function نگاه کنید، انگار این تابع به هیچ ورودی نیاز نداره تا درست کار کنه. در صورتی که اینطور نیست و ما میدونیم که داده های دفتر سفارشات ورودیش هستند. حالا فرض کنید شما میخواید ببینید برای Lob های مختلف آیا این تابع منطق درستی داره یا نه. میبینید؟ شما نمیتونید منطق تابعی که نوشتید رو تست کنید. چون اصلا ورودی نمیگیره. پس نگهداری و تست کدهایی که SRP رو رعایت نمیکنند راحت یا اصولی نیست. 2⃣ میدونیم که تغییر جز ذات دنیای نرم افزاره و یک کد خوب کدیه که قابل تغییر در سریعترین زمان و با کمترین هزینه باشه. اگر من بخوام بعد از مدتی در تابع fetch_lob تغییری ایجاد کنم (مثلا اینکه خروجیش دیگه دیتا فریم نباشه و دیکشنری باشه) این تغییر ناخواسته باعث خراب شدن عملکرد تابع  first_function میشه یعنی تغییر همچین کدهایی سخت و هزینه بر هستش. 3⃣ انجام چند کار توسط یک تابع یا کلاس باعث میشه پیچدگی اون تابع یا کلاس بیشتر بشه و درک و نگهداری اون برای توسعه دهندگان دیگه سخت باشه. 4⃣ رعایت این اصل باعث میشه ساختار کد ما انسجام بهتری داشته باشه و هر قسمت به طور منظم، مستقل از بقیه قسمت ها باشه.

⭕️ انواع آرگومان های توابع در پایتون ✅ اگر شما تابعی مانند def f(a, b):     print(f"a={a}, b={b}") تعریف کنید برای فراخوانی همچین تابعی سه راه وجود داره: 1⃣ f(1, 2) 2⃣ f(b=2, a=1) 3⃣ f(1, b=2) تو حالت 1⃣ ما آرگومان هارو به صورت Positional به تابع معرفی کردیم و این یعنی فقط ترتیب معرفی آرگومان ها اهمیت داره. تو حالت 2⃣ آرگومان ها به صورت Keyword معرفی شده اند و همینطور که می بینید ترتیب تو چنین حالتی اهمیت نداره و فقط باید اسم آرگومان ها با اسم پارامترهایی که تو تعریف تابع نوشتیم مچ باشه. در نهایت حالت 3⃣ ترکیبی از دو حالت قبلیه که آرگومان ها به تابع پاس داده شده اند. ✅ ویژگی جالبی که تو پایتون 3.8 به بعد قابل استفاده است اینه که ما می تونیم به کاربر اجبار کنیم که یک تابع رو چطوری بتونه فراخوانی کنه. مثلا اینکه به صورت Positional-only یا تو حالت جالبترش بصورت Keyword-only آرگومان هارو به تابع پاس بده. چطوری؟! مطابق عکس بالا موقع تعریف تابع هر پارامتری که قبل از کاراکتر Forward-Slash یا همون / بنویسم Positional-Only و هر پارامتری که بعد از کاراکتر Asterisk یا همون * نوشته میشه Keyword-Only خواهد بود. ✅ مثلا اگر شما تابعی رو به صورت def f(a, b, /):     pass تعریف کنید دیگه نمی تونید این تابع رو به صورت f(a=1, b=2) یا f(1, b=2) فراخوانی کنید. چون قرار بوده آرگومان ها به صورت Positional-Only به تابع پاس داده بشن و به همین خاطر پایتون شمارو یه TypeError مهمون میکنه :) همینطور اگر شما یک تابع رو به صورت def f(*, a, b):     pass تعریف کنید دیگه به صورت های زیر نمیتونید فراخونی کنیدش: f(1, 2) f(1, b=2) ✅ استفاده از این دو ویژگی مخصوصا Keyword-Only arguments باعث میشه کد شما خواناتر و قابل فهم تر باشه و همچنین از پذیرش ورودی های ناخواسته جلوگیری بشه. @Quant_Fin

انواع آرگومان های توابع در پایتون @Quant_Fin

آیا می‌شه با ترید اتوماتیک و پیش بینی رمزارز با هوش مصنوعی و سیگنال اتوماتیک و یادگیری ماشین روی دیتای سهام و این چیزها پولدار شد؟ هم آره و هم نه (: کاپیتان توی شش دقیقه نظرش و یکی از لم‌های زندگیش رو براتون می‌گه (: https://youtu.be/AvmtkwxW7zQ

#مروری_بر_ادبیات_معاملات_الگوریتمی ⭕️ Implicit costs (delay cost) هزینه های پنهان معاملاتی (هزینه تاخیر) ✅ هزینه تاخیر، میزان تغییر نامطلوب قیمت از لحظه تصمیم‌ سرمایه‌گذاری (خرید/فروش) تا لحظه‌ای که عملا سفارش خرید/فروش به کارگزاری می‌رسد، می باشد. این تاخیر می‌تواند به‌خاطر عواملی مانند موارد زیر باشد: ▪️پیدا کردن بهترین راه برای اجرای سفارش، ▪️تردید یا تعلل معامله گران برای نحوه ی اجرای سفارش (عدم توانایی معامله گر در اجرای کامل یک سفارش در بازه زمانی مورد نظر)، ▪️بسته بودن بازار ▪️صف خرید/فروش شدن و ... ✅ هزینه تاخیر می‌تواند نسبت قابل توجهی از کل هزینه معاملاتی را تشکیل دهد، مخصوصا برای سهامی که دارای نوسان زیاد یا روند قیمتی نامطلوب هستند و همچنین زمانی که حجم سفارش ما زیاد است (با توجه به فرمول زیر). یکی از راه های محاسبه میزان هزینه تاخیر؛ ضرب کردن حجم کل سفارش مورد نظر در اختلاف بین قیمت میانی لحظه تصمیم گیری به سرمایه گذاری با لحظه ارسال سفارش است. (قیمت میانی = میانگین بهترین مظنه خرید و بهترین مظنه فروش دفتر سفارشات) @Quant_Fin

تو این روزا اگر حوصلتون گرفت فیلم سینمایی Her رو ببینید. قشنگ و محصول سال ۲۰۱۳عه. فیلم دنیایی رو به تصویر می کشه که حالا با اومدن این مدل های جدید هوش مصنوعی، دیگه پذیرشش برای ما خیلی سخت نیست.

⭕️ پایتون و وب فریمورک های آن ✅ احتمالا تو این روزها در کنار نام پایتون کلماتی مانند جنگو (Django)، فلسک (Flask) و FastAPI زیاد به چشم شما میخوره و براتون سوال می شه که واقعا این ها چی هستند و کاربردشون چیه؟ ✅ جنگو (Django)، فلسک (Flask)، FastAPI و Tornado و ... در واقع یک سری فریمورک (یا میکروفریمورک) هایی هستند که چارچوبی رو ایجاد می کنند تا شما بتونید با استفاده از زبان برنامه نویسی پایتون، برنامه های تحت وب یا Web application توسعه بدید. ✅ احتمالا اگر شما یک تحلیلگر داده یا پژوهشگر هوش مصنوعی یا توسعه دهنده الگوریتم معاملاتی باشید؛ تا زمانی که درگیر پژوهش یا توسعه مدلتون و کار با دیتا فریم ها هستید؛ نیازی  حس نخواهید کرد که با یک وب فریمورک کار کنید. اما ... ✅ به محض تکمیل مدلتون و زمانی که قرار باشه این مدل رو به صورت یک سرویس در اختیار بقیه قرار بدید یا اگر حجم کارتون فراتر از دیتافریم ها بره و نیاز داشته باشید که با دیتابیس ها و سایر سرویس ها کار کنید؛ اینجاست که گذرتون به دنیای وب باز میشه و مجبور خواهید بود که یک وب اپلیکیشن توسعه بدید. ✅ هر چقدر که در توسعه و پژوهش پیرامون یک مدل، دغدغه های شما از جنس تئوری است؛ در بحث توسعه وب شما با دنیایی گسترده از ابزارها، تکنولوژی ها و پروتکل ها روبرو می شوید و اساسا مفاهیمی که قبلا باهاشون درگیر نبودید ممکنه شما رو به چالش بکشه. از مفاهیمی مثل سیستم عامل(مخصوصا لینوکس)، معماری نرم افزار، Clean code، پارادیم های برنامه نویسی (مثل OOP و Functional programming) گرفته تا چیزی مثل امنیت در وب. هرچقدر هم که ایده های شما عمیق تر باشه احتمالا نیازه که بیشتر تجربه کسب کنید یا حداقل با ادم های حرفه ای تری که قالبا عنوان شغلی Backend developer دارند تعاملتون بیشتر باشه. ✅ از بین این وب فریمورک ها، فلسک و جنگو خیلی پرکاربرد هستند و چیزی مثل جنگو واقعا امکانات خوبی در اختیار توسعه دهنده ها قرار میده (پنل ادمین، ملاحظات امنیتی، یک ORM قوی برای تعامل ساده تر با دیتابیس و ...) جدیدا هم fastAPI خیلی سر و صدا کرده و معمولا برای دیپلوی کردن (استقرار روی سرور جهت سرویس دهی) مدل های ماشین لرنینگی ازش استفاده می شه. @Quant_Fin

عید همگی مبارک ☘ Listen to نوروز تو راهه - با گلنار by Ali Azimi on #SoundCloud https://soundcloud.com/aazimi/iwzmg2pnwjnw?ref=clipboard&p=a&c=0&si=d3d55a05adbf4c519123cdb781c2832e&utm_source=clipboard&utm_medium=text&utm_campaign=social_sharing

✅ همونطور که در این نمودار قابل مشاهده است، ارزش معاملات ماهانه این بازار در شش ماهه نخست امسال، برای هر ماه کمتر از 200 میلیارد تومان بوده. ✅ ولی درست از مهر ماه به بعد ارزش معاملات ماهانه به بالای این رقم رسیده و طی یک روند صعودی در ماه‌های دی و اسفند به بیشترین رقم خودش یعنی 1323 میلیارد تومان رسیده. (البته دو روز معاملاتی از ماه اسفند هنوز باقی مونده ) ✅ بیشترین ارزش معاملات روزانه مربوط به تاریخ 7 اسفنده که رقم 142 میلیارد تومان برای ارزش معاملات اون روز ثبت شده. جالبه این رقم از ارزش معاملات ماهانه‌ی ماه های خرداد و تیر و مرداد بیشتره! ✅ بیشترین میانگین ارزش هر معامله (کل ارزش معاملات روز تقسیم بر تعداد معاملات) هم برای روز 24 اسفند ماه و برابر با 7 میلیون تومان بوده. 🅾 داده های خام این مطلب از لینک زیر برداشته شده: https://tse.ir/archive.html#/tradeOption این نمودار و اطلاعات، حاصل کنجکاوی اولیه من نسبت به این داده ها بود. برای بدست آوردن اطلاعات بیشتر می تونید به کد پایتون این مطلب که رو گیت هاب قرار دادم سر بزنید: https://github.com/masoudghah/tse-options-market-trading-statistics/blob/main/trades-info.ipynb @Quant_Fin

نگاهی به آمار بازار اختیار معامله بورس تهران در سالی که گذشت ... @Quant_Fin

#مروری_بر_ادبیات_معاملات_الگوریتمی ⭕️ Implicit costs (bid-ask spread) هزینه های پنهان معاملاتی (شکاف قیمتی) ✅ در پست قبلی راجع به هزینه معاملات و انواعش که مستقیم و ضمنی بود صحبت کردیم. حقیقت اینه که هزینه های مستقیم همونطور که مثال زدم چیزهای واضح و ثابتی هستند که نیاز به توضیح و تفسیر ندارند. پس بحثمون رو میبریم سمت هزینه های پنهان و اولین موردش یعنی : شکاف قیمتی یا همون Bid-ask spread که معمولا بهش spread میگن. ✅ شما وقتی قصد خرید یا فروش یک دارایی تو بازار الکترونیکی رو دارید معمولا سفارشات رو تو قالبی به اسم دفتر ثبت سفارشات (limit order book) میتونید مشاهده کنید. اگر این دفتر یا تابلو رو به دو سمت تقسیم کنیم؛ سفارشات فروش به صورت صعودی یه سمت و سفارشات خرید به صورت نزولی در سمت دیگه مرتب شده اند. ✅ تو این تابلو، همیشه اولین قیمت فروش (کمترین قیمت فروش) از اولین قیمت خرید (بیشترین قیمت خرید) بزرگتره که اگر اینطوری نباشه؛ سفارشات مچ میشن و معامله انجام میشه. شکاف قیمتی در واقع اختلاف همین دو کمیت یعنی کمترین قیمت فروش و بیشترین قیمت خریده. این شکل نشون دهنده خوبی از این موضوعه. مطلب زیر همین شکل هم ادامه توضیحات راجع به شکاف قیمتی و ارتباطش با بحث هزینه معاملات هستش. @Quant_Fin

#مروری_بر_ادبیات_معاملات_الگوریتمی Transaction cost هزینه معامله منظور از هزینه معامله، هزینه‌های مربوط به انجام یک معامله در بورس مانند:  کمیسیون، مالیات، کارمزد کارگزار، هزینه شکاف قیمتی، هزینه تاخیر، تاثیر بازار، ریسک زمان‌بندی و هزینه فرصت می باشد.   برخی از این هزینه‌ها مستقیما (Explicit) و برخی به صورت پنهان یا ضمنی (Implicit) بر معامله‌گر تحمیل می‌شوند. از هزینه های مستقیم می توان به: کمیسیون، مالیات، کارمزد کارگزار و از هزینه های پنهان می توان به: هزینه شکاف قیمتی، هزینه تاخیر، تاثیر بازار، ریسک زمان‌بندی و هزینه فرصت اشاره کرد. الگوریتم های معاملاتی برای کاهش هزینه های معاملاتی معمولا سعی در کاهش هزینه های پنهان دارند. @Quant_Fin