برگه تقلب شماره ۱ پایتون ، کتابخانه Numpy

Cheat Sheet 1 : Numpy


#کتابخانه #cheat_sheet #pdf


#python
➖➖➖➖

♦️ لیست توابع و نوع های داخلی پایتون.

🔻A
abs() - aiter() - all() - any() - anext() - ascii()

🔹B
bin() - bool() - breakpoint() - bytearray() - bytes()

🔻C
callable() - chr() - classmethod() - compile() - complex()

🔹D
delattr() - dict() - dir() - divmod()

🔻E
enumerate()- eval() - exec()

🔹F
filter() - float() - format() - frozenset()

🔻G
getattr() - globals()

🔹H
hasattr() - hash() - help() - hex()

🔻I
id() - input() - int() - isinstance() - issubclass() - iter()

🔹L
len() - list() - locals()

🔻M
map()- max()- memoryview() - min()

🔹N
next()

🔻O
object() - oct() - open() - ord()

🔹P
pow() - print() - property()

🔻R
range() - repr() - reversed() - round()

🔹S
set() - setattr() - slice() - sorted() - staticmethod() - str() - sum() - super()

🔻T
tuple() - type()

🔹V
vars()

🔻Z
zip()

🔹_
import()

توی گیت، objectها یک سری موجودیت‌های پایه‌ای هستن که میتونن دیتاهای مختلف رو توی repository ذخیره کنن. مثلا:
blob object, tree object, commit object . . .

برای اینکه بهتر بدونیم گیت چطوری داره اون پشت کار میکنه، توی این مقاله درباره‌ی git objects صحبت میکنیم.

https://medium.com/@AG1380/mastering-git-git-objects-cc4fbf0a9bcd

کتاب هایی برای پایتون:

1. "Python Crash Course" نوشته Eric Matthes: این کتاب برای مبتدیان بسیار مناسب است و به شما اصول پایه و مفاهیم اساسی پایتون را آموزش می‌دهد. همچنین، با استفاده از پروژه‌های عملی، شما را با کاربردهای واقعی زبان آشنا می‌کند.

2. "Python for Data Analysis" نوشته Wes McKinney: اگر به تجزیه و تحلیل داده‌ها علاقه‌مند هستید، این کتاب برای شما مناسب است. در این کتاب، شما را با استفاده از کتابخانه‌های محبوب مانند NumPy و Pandas در پایتون آشنا می‌کند.

3. "Automate the Boring Stuff with Python" نوشته Al Sweigart: این کتاب به شما نشان می‌دهد که چگونه با استفاده از پایتون کارهای روزمره و خسته کننده را به صورت خودکار انجام دهید. این کتاب مفید برای افرادی است که می‌خواهند پایتون را برای اتوماسیون و خودکارسازی استفاده کنند.

4. "Fluent Python" نوشته Luciano Ramalho: این کتاب برای افرادی که قصد تسلط بیشتر بر روی زبان پایتون را دارند مناسب است. در این کتاب، مفاهیم پیشرفته‌تری مانند توابع فراخوانی، توابع مولد، مدیریت استثناها و غیره را مورد بررسی قرار می‌دهد.

5. "Python Cookbook" نوشته David Beazley و Brian K. Jones: این کتاب به شما تکنیک‌ها و الگوهای مختلف برنامه‌نویسی در پایتون را آموزش می‌دهد. با استفاده از مثال‌های عملی، شما را با روش‌های بهینه‌تر برنامه‌نویسی در پایتون آشنا می‌کند.

کتابخانه اوپن‌سورس پایتون برای تولید طرح‌واره‌هایی با هوش مصنوعی و در عین حال نزدیک به  واقعیت که در پروژه های مختلف می‌تونه به کارتون بیاد.

https://github.com/nicolas-hbt/pygraft

#تجربه

فریمورک برای یادگیری core python نیست،
سورس کد خوندن برای بهتر شدن هست نه یادگیری.


چندروز قبل منتظر بودم یکی از بچه‌ها بیاد ازش یک وسیله‌ای رو تحویل بگیرم، دیدم زود رسیدم گفتم بد نیست برم یکجا بشینم ی قهوه بخورم.

نشسته بودم سفارشم آماده بشه (قهوه نخوردم، چون dark roast داشت فقط) دیدم توی فضایی جداگانه کنار من (مثل بخش vip) یکنفر درحال آموزش دادن
generator, yield, yield from
هست، البته برای دیپ‌ لرنینگ و از روی فریمورک، متوجه شدم خیلی داشت اشتباه توضیح می‌داد.

بعد از چند دقیقه که حواسم به کلاس اونها بود و مدرس حواسش به من، کلاس‌ ۵ دقیقه استراحت داد و متوجه شدم از اون ۱۲-۱۵ نفر ۳-۴ نفر عضو همین کانال هستند و مدرس و باقی اعضا همه رفیق هستند که دارند تلاش می‌کنند باهم یاد بگیرند.

خداییش خیلی خیلی لذت بردم (کامیونیتی اینجوری لذت بخش هست) و توی این بحث و اینکه چطوری data loading, batching, ... توی فریمورک‌های هوش مصنوعی کار‌ می‌کنه مونده بودند و اشتباه این بود که بجای درک مطالب اصلی و عملکردشون سعی داشتند از framework این موضوع رو یاد بگیرند.

چندتاشون سوال پرسیدند و براشون توضیح دادم، بعد دعوت کردن این مبحث رو توی کلاس آموزش بدم.
منم که منتظر تماس بودم، شروع کردم با پایتون کد زدن و آموزش دادن و تأکید کردم این چیزا رو نباید با فریمورک یادگرفت هدف هرچی که باشه

ولی واقعاً دیدن همچین کامیونیتی‌هایی لذت بسیار زیادی داره، یادگیری رایگان و دردسترس برای همه.

📕 جزوه آموزشی MLOps
🏛 دانشگاه صنعتی شریف
📑 در 122 صفحه!

👨🏻‍💻 سید عباس حسینی استادیار پژوهشکده AICT دانشگاه شریف، جزوه آموزش MLOps رو در 122 صفحه منتشر کرد.

✅ هدف اصلی MLOps، ایجاد یه جریان کاری یکپارچه و مدیریت مداوم برای مدل‌های یادگیری ماشین در محیط‌های تولیدی است تا عملکرد بهینه و پایداری را به همراه داشته باشیم.💯

با سلام و وقت بخیر با توجه به اینکه بنده برای یک ارائه و سمینار در حوزه تکنولوژی دارم در صورتی که علاقه مند به یادگیری برنامه نویسی هستید یا در حوزه های برنامه نویسی فعالیت دارید در این پرسشنامه برای ارزیابی شرکت کنید موفق باشید https://survey.porsline.ir/s/KW3s395M

نشستم با Rust یک تابع محاسباتی رو که جزو فرمول‌های شرکت بود پیاده‌سازی کردم، و آوردمش توی پایتون؛

زمان بندی‌هاش بسیار جالب شد،
توی پایتون هموار ه حدود ۷ دقیقه زمان می‌بره
از numpy که استفاده می‌کنم، به ۱ دقیقه هم می‌رسید
و پیاده‌سازی توی Rust؛ کمتر از ۵ ثانیه شد.


حتی اگر تفاوت محاسبات بین Rust, Python رو درک کنم موضوع و اختلاف سرعت بالای بین Numpy, Rust هنوز برای خودم عجیب هست.

دلیلش رو نمی‌دونم ولی حتماً دنبالش می‌گردم.

به بهانه معرفی فریمورک <جای‌خالی> با ۳ برابر سرعت در پاسخگویی نسبت به FastAPI و البته باهدف battery included بودن مثل django

وقتی صحبت از بکند توی پایتون میشه تا همین چندسال قبل تنها گزینه خوب فقط و فقط django بود و مرسی دولوپرهاش؛ تو زمانی که همه غر میزدند پایتون کند هست و نباید و ... (تو ایرانم ازین حرفا زیاد بود) قشنگ یادمه ی بنده خدایی اسم نمیبرم ولی معروفم هست توی یکی از دانشگاها پنل سخنرانی داشت.
گفت که پایتون فقط یک جو هست و خیلی زود هم تموم می‌شه؛ بعد هم ادعا کرد به همین دلیل مطالبش رو نیاورده و ترجیح میده راجب مطالب مهمتر صحبت کنه (سخنرانی به شوخی گذشت و تنها کسی که اعتراض کرد توی سالن ۳۰۰-۴۰۰ نفری من بودم) الان شنیدم همون بنده خدا داره از پایتون نون میخوره و دوره هم میذاره.

بگذریم اومد جلوتر و async معرفی شد؛ هوش مصنوعی از فقط ریسرچ بودن داشت خارج میشد و تجریه دپلوی مهم شد.
دپلوی رو django انقدر سخت و غیر بهینه بود که عملا خیلی از تیم‌هایی که پروژه‌هاشون مشتری کافی رو داشت مجبور به توسعه بکند توی زبان‌های برنامه نویسی دیگه بودند؛ خیلی از بچه ها رفتند سراغ C, C++ , Go-lang و ...
حتی جوگیری زیاد شد مدل هارو سمت وب و موبایل و ... هم بردند که صحبتی نیست.

یادی کنم از شب زنده داری‌ها و دپلوی کدها و مدل‌ها با Majid A.M (آیدی نمیزارم ولی احتمالا هرکی django کار می‌کنه میشناسه) عزیز و حجم اپتیمایز‌های بالا جزو اولین نفرات و تیم‌هایی بودیم که کل مدل هوش مصنوعی و اپتیمایز و وب و ... همه روی پایتون بود و البته دسترسی و درخواست رایگان (این برای زمانی بود که همه میرفتن سراغ C, ... برای دپلوی و کسی باورش نمیشد بشه مدل‌های سنگین رو روی سرور بیاری و اون تعداد ریکوست رو با پایتون جواب بده) اون زمان همه فکر میکردند روی سرورهای خفن و ...هستیم ولی این موضوع رو اولین بار هست دارم اعلام می‌کنم؛
۲ نسخه اول مدل‌های پردازش تصویرمون روی کلاستر رزپبری پای و نسخه آخر روی لپ‌تاپ شخصی بنده بود.

ازین دوران گذشتیم flask با ایده‌های جدید اومد و خوبیش این بود که دیگه به اندازه django سنگین نبود (برای تست‌های کوچیک خیلی جواب بود ولی بازم همون مشکلات رو داشت)
البته اضافه کنم سرویس‌هایی مثل Celery, ... خیلی از مشکلات رو توی django حل می‌کردند

بعد از این زمان FastAPI معرفی شد؛ روی همون کامیت‌های اولیه که عمومی شد چون از بچه‌ها و همکارای بکندم توی شرکت‌های سیلیکون‌ولی و ... بسیار راجبش شنیدم به خیلی از دوستان بکند دولوپرم پیشنهاد کردم که وقتش هست یاد بگیرند و بهش کد donate کنند (کاش خودم اینکارو میکردم) خیلی هم مسخره میکردند. همون Majid A.M جزوشون بود.

به لطف همه‌ی دولوپرهای پروژه‌های قبلی django - flask - fastapi حالا خیلی‌ها باور دارند پایتون می‌تونه توی پروداکشن و برای پروژه‌های بزرگ استفاده بشه؛ خیلی‌ها قبول دارند که میشه با پایتون کد زد و از پکیج‌هایی استفاده کرد که سرعت پردازش بسیار بیشتر بشه .
دولوپرهای پروژه‌های قبلی نشون دادند که توسعه پکیج‌هایی با ایده‌هایی حتی کمی بهتر بسیار ارزش داره و جامعه پایتون همیشه قدردان این زحمات خواهد بود.

تا اینجا که حالا community زبانی مثل Rust برای توسعه یک web framework با سرعت بیشتر و البته به راحتی موارد قبلی برای Python وارد شده و پروژه Robyn رو به حد خوبی رسونده بطوری که امروز توی چندین جلسه مختلف با دوستان و همکاران بسیار درمورد این پروژه شنیدم.
توی مطالبی که داشتم میخوندم و بنچمارک‌هایی که از باقی شنیدم اکثرا اشاره می‌کنند که به راحتی سرعتی ۳ برابر fastapi رو ارائه میده.
از نظر کدهم شخصا یک نگاهی انداختم به همون سادگی هست؛ خلاصه که شمارو نمی‌دونم اما شخصا فکر کردم باید قدردان زحمات تیم‌های توسعه django, flask, fastapi و برو بچه هایی که توی دوران سخنرانی ضد سرعت و ... پایتون با این زبان برنامه نویسی ادامه دادند باشم.

با یک مثال خیلی ساده شروع کنیم تا مطلب جا بیوفته قشنگ؛ توجه کنید من توقع دارم کار با logging رو مقدماتش رو بلد باشید.

اصلی ترین عنصر logger هست؛ اگر بخوام خیلی خلاصه بگم:
وظیفه‌اش اینه که یک پیام از شما دریافت کنه و  بر اساس level اون رو به handler درستش ارسال کنه.

با این تعریف عنصر بعدی که راجبش صحبت می‌کنیم handler هست.
وظیفه‌اش ارسال لاگ به مقصدی هست که براش تعریف شده.

اما ۲ مورد دیگه هم وجود داره که استفاده ازش می‌تونه زندگی رو بعدا براتون شیرین کنه:

formatter
اینکه چه اطلاعاتی توی لاگ فایل (علاوه بر پیام شما) بصورت خودکار قرار بگیره و اینکه این اطلاعات چطور نمایش داده بشه همش وظیفه این عزیز دل هست.

filters
وظیفه فیلتر کردن لاگ‌ها رو داره؛ چه اینکه نوشته نشه یا تغییراتی روش انجام بشه و بعد نوشته بشه.

استیج آماده شد؛ بریم سراغ مثال تصویر
استفاده از logging.basicConfig چیزی نیست که برای پروژه‌های مهم و بزرگ بخواید داشته باشید؛ چون معمولا بیش از ۳ مورد handler خواهید داشت که این یعنی تعداد زیادی logger که هرکدوم formatter, filter  های خودشون رو خواهند داشت.

ادامه پست بعدی ....

اگر بتونیم مزیت الگوریتم یادگیری شبکه عصبی (gradient backpropagation) رو با الگوریتم مدل‌های boosting بر مبنای درخت تصمیم مثل XGboost که پادشاهان Tabular Data هستند به صورت بنیادی ترکیب کنیم به چه مدلی میرسیم؟

مدل قدرتمند جدیدی در Tabular Dataبه نام GRANDE که بر اساس ایده Gradient Decision Tree ساخته شده و تونسته در اکثر دیتاست‌ها، از جمله Numerai (مسابقه معروف در پیشبینی بازار مالی با دیتاساینس) از XGboost و Catboost که تا به حال بهترین بودن عملکرد بهتری داشته باشه.
پکیج GRANDE رو میتونید با pip نصب کنید.
GRANDE: Gradient-Based Decision Tree Ensembles

کمی عمیق تر:
مسئله اصلی این هست که الگوریتم‌های درخت تصمیم و الگوریتم ترکیب درخت‌ها در boosting ها به صورت greedy هست که باعث ایجاد محدودیت در فضای جستجو و همچنین overfitting میشه. به همین دلیل نیاز هست تا فرآیند‌هایی مثل split به صورت differentiable بشه و بعضی موارد non-differentiable مدیریت بشن. بعد از این امکان بهینه کردن بنیادی پارامترهای درخت تصمیم و ensemble رو خواهیم داشت. و حتی میتونیم برای split values، split indices، leaf weights و leaf به طور جداگانه learning rate داشته باشیم. برای فهم دقیق الگوریتم مقاله‌های اصلی رو بخونید:
GRANDE paper : ICLR 2024
GradTree paper : NeurIPS 2023

یه جمله خیلی بامسما در کتاب Clean Code in Python هست که میگه:

Having maintainable software is not about anticipating future requirements (do not do futurology!)

ترجمه: داشتن یه نرم‌افزار قابل‌نگهداری به معنی پیش‌بینی نیازمندی‌های آینده نیست. (آینده‌پژوهی نکنید!)

اینجا "پیش‌بینی" به معنی تخصیص انرژی و زمان واسه ساخت یه بستر برای توسعه ساده‌تر در آینده با توجه به نیازمندی‌هایی هست که بعدها ممکنه بوجود بیان.

منظور اینه که بجای اینکه بیایم ذهنیت، معماری و دیزاین رو محدود به آینده کنیم، سعی کنیم نیازمندی‌های فعلی رو برطرف کنیم.

یه مثال کاربردی می‌زنم تا درک این قضیه ساده‌تر شه. فرض کنید شما یه Shop طراحی کردید و فقط یه متد پرداخت دارید و اونم PayPal هست. درحالی که دارید کلاس PayPal رو طراحی می‌کنید، این فکر به ذهنتون خطور می‌کنه که شاید بعدها متد پرداخت Stripe هم به سیستم اضافه شد. اونوقت من باید یه کلاس عین PayPal واسه Stripe درست کنم.. چرا از همین الان یه Base Class درست نکنم و PayPal و Stripe از اون بیس‌کلس ارثبری نکنن؟

موضوع اینه که هنوز نه به باره.. نه به داره.. استرایپ کو؟! داری عملا از دیزاین‌پترنی استفاده می‌کنی که اصلا نیازی بهش نداری. بله. درسته. این یه دیزاین OOP پرفکت هست و بهتره که همچین حرکتی رو بزنی ولی آیا الان؟!

اینجاست که Over-engineering کار دست آدم می‌ده. بنظرم این دو موضوع Overengineering و Overthinking در کنار هم میان. تمرکزتون رو بذارید روی نیازمندی‌های فعلی و سعی کنید سلوشن خوب برای الان بدید.. بعدا با تغییر نیازمندی‌ها، می‌تونید سراغ دیزاین‌پترن‌ها و متدلوژی‌ها و معماری‌های پیچیده‌تر هم برید!

امروز یک دعوت به همکاری دیدم
نوشته بود یک نیرو میخوایم برای تیم DevOps؛ برداشت من این بود که ی تیم جدا تشکیل دادند به نام devops
دوستان مدیران عزیزی که تو کانال هستند :
دقت دارید که DevOps نباید یک تیم جدا باشه بلکه یک فرهنگ سازمانی هست با هدف همکاری  بین تیم های
Development و Operation اصلا به همین دلیل هم اسمش شده DevOps لطفا اگر فکر دیگه‌ای دارید کتاب زیر (البته نسخه ۱ هم مناسب هست) رو بخونید از بزرگان DevOps, اینجا واقعا باید developmentهارو بریزید تو operationها نه اینکه ی گروه جدا automation تشکیل بدید واقعا اون یک چیز دیگه‌ای هست 🤦‍♂️ :
The DevOps Handbook, 2nd Edition
.
پ.ن : اینه که وقتی به طرف میگیم ما روزانه بیش از ۱۵ دیپلوی انجام میدیم خیلی‌ها باور نمی‌کنند و یا درکی از موضوع ندارند --> اضافه کنم ما به گرد پای تیم‌های حرفه‌ای و حتی معدود بچه‌های حرفه‌ای DevOps ایران هم نمیرسیم.

ثبت نام دوره جامع یادگیری عمیق
40 ساعت محتوا + 10 ساعت کلاس آنلاین تعاملی

🎉کد تخفیف30 درصدی ویژه عید فطر:
fitr403

https://class.vision/blog/deeplearning1403-hybrid/