بالاخره فرصت شد که بلاگ خودم رو هوا کنم :)
مثل همه‌ی کار های بی‌ربطی که دقیقا وسط امتحانا ادم ویرش میگیره تا انجام بده، منم در این برهه‌ی حساس کنونی خوشی زد زیر دلم که بلاگ خودم رو داشته باشم. البته تصمیم جدیدی نبود ولی خب محرکی به کیفیت و قدرت فرار از امتحانا تا حالا نبود که برم سر وقتش.
خلاصه، ماجرا از تست ورد پرس و ور رفتن با صد‌جور تم جور و ناجور شروع شد تا اخرش رسیدم به این که بیام از گیت‌هاب پیج استفاده کنم. به هر حال بعد از کلی بالا و پایین، الان درحدی هست که از نظرم قابل قبول باشه. اصلا مگه قراره چی‌کار کنم؟ :)

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

میخوام سعی کنم که اون‌جا بیشتر بنویسم و این‌جا بهش رفرنس بدم. اگر نظری داشتید توی کامنت‌های این پست واسم بنویسید. ممنونم.

قانون Littlewood's

“a person can expect to experience events with odds of one in a million (referred to as a "miracle") at the rate of about one per month.”

پیرو این ماجرای مضرب سه، تو توییر چشمم خورد به ارجاعی به این قانون (و بعدی) که برام خیلی جذاب بود. ماجرا از این قراره که، بر اساس قانون Littlewood، هر آدمی میتونه انتظار داشته باشه ماهی یک‌بار اتفاقی معجزه‌آسا (رخدادی با احتمال وقوع یک در میلیون) براش رخ بده/ناظرش باشه.

چراییش و مفروضاتش از این قراره:

“Littlewood defines a miracle as an exceptional event of special significance occurring at one in-a-million frequency. He assumes that during the hours a human is awake and alert, a human will see or hear one "event" per second, which may be either exceptional or unexceptional. Additionally, Littlewood supposes that a human is alert for about eight hours daily.
As a result, in 35 days, a human will have experienced about one million events under these suppositions. Therefore, accepting this definition of a miracle, one can expect to observe one miraculous event every 35 days, on average – therefore, according to this reasoning, seemingly miraculous events are commonplace.”

قانون Truly Large Numbers

اگر به تعدادی زیاد (و کافی)، نمونه‌ی تصادفی مستقل داشته باشیم، امکان وقوع هر رخداد نادری (یا به تعبیر بالاتر، معجزه) ممکنه.

مثالی که براش میزنه هم جالبه:

“In high availability systems even very unlikely events have to be taken into consideration, in series systems even when the probability of failure for single element is very low after connecting them in large numbers probability of whole system failure raises (to make system failures less probable redundancy can be used - in such parallel systems even highly unreliable redundant parts connected in large numbers raise the probability of not breaking to required high level).”

منابع: ۱، ۲

خب ماجرا از این جا شروع شد که یه استاد اقتصاد دانشگاه Milan-Bicocca در این توییت سر گشاده خیلی بی‌اعصاب‌طور به تمام متقاضیان PhD در سرتاسر جهان گفتش که اگه research statement‌تون رو با چت جپت/Chatgpt نوشتید، اسم منه دیه نیارید! عکس research statement نمونه‌ای رو هم گذاشته زیر توییتش.
بعدش گفته نمره‌ات رو صفر میدم، ازین به بعد وقت ما و خودتم نگیر. مرسی اه :)) [بزرگوار لامصب استریتوتایپ استاد ایرانیه‌ها قشنگ! حالا جلوتر میبینید چرا. تایم امتحانا و نمراتم هست ذهنا آمادست و دل‌ها خون😭😢]

و بزرگوار شب خوابید و صبحش پا شد(البته خودش میگه نصف شب نوتیفاشو دیدم دیگه خوابم نبرد) دید هزارتا کامنت و فحش و اینا گرفته که بَبَم جان تو از کجا فهمیدی chatgpt بوده و روشی نیست که به صورت قطعی بتونه تشخیص بده و ازین جور احادیث خلاصه.

ایشونم در اومد یه بیانه توبه‌نامه طوری نوشت طوری که نه سیخ بسوزه نه کباب :)
مثلا عذرخواهی کرد که نباید مثلا حتی متن یه دانش‌آموز که قرار بوده خصوصی باشه رو به صورت عمومی منتشر کرده ولی عملا هنوز توییتش رو پاک نکرده😁 یا مثلا گفتش که من خودم خدایگان political correctness و این حرفام تو رو جدتون به من نچسبونید این برچسب‌ها رو که تو سیاست‌ تبعیض‌آمیز داری نسبت به دانشجوهای غیرانگلیسی زبان. و در ادامه افزود اصن همه کسایی که اپلای میکنن غیرانگلیسی زبانن و این چیزا.

ولی فارغ از اینا یه سری نکات جالبم گفت، مثلا گفت که من کارم اینه که باید بشنیم کلی انشاهای ملت رو بخونم و مثلا متن طرف پر red flag بود برای من و به چندتاش اشاره هم کرد که ببینیم چیا بود مثلا:

اولیشو میگه پر لغاتی بود که تیکه کلام chatgpt عه! اع مگه chatgpt هم تیکه کلام داره؟
بله متاسفانه. کلماتی مثل delve, crucial, intricate, ... اینا از کلمات پرتکراری هستن که جپت عاشق اوناست.

این وسط یه پرانتز نسبتا بزرگ هم باز کنم که یه مقاله‌ای اخیرا منتشر شده به اسم
"Delving into Chatgpt usage in academic writing through excess vocabulary"
که توش میان و بررسی میکنن که چقدر از جپت تو نوشتارهای علمی استفاده شده است. جواب یک کلمه‌ایش اینه که خیلی! خیلی خییلی زیاد(همون اندازه که کافیه عشقت رو به پول بفروشی). ولی موردهای جالبی هم داره که این توییت یه سری نتایج رو نشون میده که تو عکس در پیام پایین میذارم.
🔗 توییت مربوط به مقاله، پایان پرانتز.

دیگه چی میگفت این آقای استاد دانشگاه از رد فلگ‌های متنی که گذاشته بود؛ اینکه فونت آخرین جمله به طرز مشکوکی عوض شده بود و به گفته خودش واضح‌ترین نشونه این بود که در فونت Calibri وقتی که میخوای از apostrophe/آپاستروف استفاده بشه این به صورت خمیده است در حالیکه آپاستروف‌های جپت مستقیمه.

چرا اینارو دارم میگم؟
نکته اینجاست که این مسئله از چند جنبه جالبه و این ازون جاهاست که به قول جادی موضوع در تقاطع تکنولوژی و جامعه است. پس فکر کردن به اینا و بحث و گفتگو راجع بهش به‌نظرم جالب و مفیده(حتما اگه خواستید نظرتونو نسبت به این نوشته یا کلا موضوع بگید.).

یک مورد دیگه اینکه در نهایت استاد میگه که نمیشه بخاطر اینکه فک میکنی یکی رزومه‌شو با AI درست کرده ریجکتش کرد ولی میگه من به چنین انشایی نمره خیلی کمی میدم و عملا شانس دعوت شدن به مصاحبه‌اش خیلی کم میشه.

از اون ور قضیه هم برام جالبه که یه آدم‌هایی که روزانه دارن تعداد زیادی انشا رو بررسی میکنن چقدر به جزئیات ریز و جالبی توجه میکنن که شاید من و شما نفهمیممش و فک میکنم بقیه هم همین‌طورن. جالب‌تر اینکه آخرش استاده میگه که من خودم خیلی از جپت استفاده می‌کنم و استفاده ازش هم خیلی خوبه ولی ندید کل انشاتون رو اون بنویسه. یه متنی بنویسید و با جپت صاف و صوفش کنید. خلاصه کلا این ابزار‌ها خیلی جدیدن و آموزشی برای استفاده ازش و همچنین برخورد باهاش نداشتن آدما و خلاثه برای همه ما جدیده. منم به بهانه این توییت خواستم راجع به این نکات حرف بزنم و اشاره کنم چون این جور مسائل خیلی برام جالبه. نظر کلی من اینه که این فناوری‌ها در نهایت ابزارن و همون طور که با چاقو میشه آدم کشت میشه میوه پوست کند یا غده‌ی چرکین رو از دل یکی درآورد ولی آدم باید حواسش باشه که چطور از چیز‌ها استفاده میکنه.

خلاصه این بود انشای من.
#LLM
@SingularThinker

خوندن این پست از عرفان رو از دست ندین. از این بین، این قسمتش توجه من رو خیلی جلب کرد. این مورد که گفته شد، دقیقا مثل یپدا کردن تقلب توی تمرین‌هاست (به خصوص تمرین‌های کد‌نویسی). اگر این فرصت براتون پیش اومده که تمرین تصحیح یا بررسی کنید، تقلب‌ها و کپی‌کاری ها خودشون به حرف میان و داد میزنن که «آهای حروم‌زاده‌ها! من هنوز زنده‌ام!».

وقتی تعداد زیادی برگه/کد برای یک موضوع مرتبط میبینید پیدا کردن الگو‌های تکراری (بالاخص اگر نویسنده چندان اهمیتی به این ماجرا نده و نخواد دست ببره توی تمرین کپی شده) اصلا کار سختی نیست. همیشه اگر خواستید کپی کنید، شرافتمندانه کپی کنید و نیم‌نگاهی هم به شعور طرف مقابل داشته باشید :)

https://youtu.be/41RqAbh0D4k

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

«ملت میخوان بچه‌دار شن هم باید برن بودجه رو بخونن پس؟! باید بخونن!»

داستان تعزیه در ایران، به روایت MMehran. رشته‌ توییتی‌ست خوندنی:

پ.ن: اگر بخوام لیستی از اکانت‌های فارسی که باید حتما در توییتر دنبال کرد رو اسم ببرم، این اکانت قطعا در بالای این لیست جا داره.

https://x.com/MMehran/status/1560264132703571968

بیاید اول یکم مرور کنیم که Fuzzing چیه. فرض کنید یک فانکشن‌ای نوشتید که چهار تا عدد از تایپ integer رو به عنوان پارامتر دریافت میکنه. فرض کنید تابع‌تون چیزی شبیه به اینه :

fun foo(int x, int y, int z, int t) {
    
    // bunch of statements

    if ( (x^t+1)^3 + (2.3*y)^2.3 - 0.8*(z^4) == 0) { // call the condition as 'f'
        Bug();
    }

    // bunch of statements
}

همونطور که ملاحظه می‌کنید، توی برنامه‌ما یک point ای وجود داره که اگر reachable باشه به باگ می‌خوریم. حالا سوالی که وجود داره اینه که بفهمیم آیا این امکان وجود داره که شرط f ارضا بشه یا خیر. برای اینکه به جواب سوال‌مون برسیم، باید یک decision procedure پیاده‌ کنیم که به عنوان ورودی فرمول f رو ازمون بگیره، و بهمون true یا false برگردونه. یک computer scientist اولین سوالی که به ذهنش میرسه اینه که آیا این مسئله محاسبه پذیره یا خیر و اگر هست از نظر پیچیدگی در چه کلاسی قرار داره. به طور خلاصه خدمتتون میگم که این مسئله undecidable هستش. حالا سوالی که پیش میاد اینه که چیکار کنیم؟ رهاش کنیم بره؟ خب قطعا نه. یه راهی که از دهه ۵۰ میلادی، یعنی از زمان پانچ کارت ها وجود داره اینه که بیایم شروع کنیم با یک الگوریتم Pseudo random number generating برای این ۴ تا متغیر value جنریت کنیم و چک کنیم ببینیم که آیا این فرمول تحت اون assignment ارضا میشه یا نه. اگر شد که خب میگیم بله reachable هستش و برنامه مون باگ داره. اگر نشد... خب بیاید این یه تیکه رو فعلا اسکیپ کنیم :)

حالا قضیه‌ی Fuzzing هم ریشه‌اش برمیگرده به random testing اما قطعا با رندوم تستینگ فرق داره. می‌تونیم بگیم رندوم تستینگ ساده‌ترین و naive ترین نوع Fuzzing هستش. تکنیک‌های Fuzz testing با توسعه‌ای که از دهه ۹۰ تا الان داشتن، ساختارمند شدند و باهوش تر عمل می‌کنند. یک سری‌هاشون از نوع generation-based هستند یعنی هر iteration ورودی‌ها رو از اول تعیین می‌کنند. یک سری‌هاشونم mutation-based هستند و میان input ها رو modify می‌کنند. فاز تستینگ‌ها به شکل white و black و gray box انجام میشن. بلک باکس اینطوریه که fuzzer هیچی از ساختار برنامه نمی‌دونه. gray box یعنی اینکه ما نیاز داریم کمی instrumentation روی کدمون انجام بدیم و به طبع white box هم که مشخص میشه چیه.

فازری که داچمن رفته سراغش از نوع gray-box و mutation-based هستش. منتهی باهوش تره، یعنی بلده که mutation هاش رو به سمت یک سری هدف و یا coverage خاص که از پیش براش مشخص شدن هدایت کنه. اصلاحا به این نوع فازرها میگن Directed Grey-box fuzzing. این تکنیک توسعه‌ و پیاده‌سازیش توسط آقای Abhik Roychoudhury و تیمش صورت گرفته. ایشون یه گروه بسیار سوپر و قوی توی دانشگاه NUS دارن که تو حوزه‌ی Fuzzing و Automated Program Repair فعاله. بسیار توصیه می‌کنم اگر به این بحثا علاقه‌مند هستید برید و کارشون رو بخونید.

تا اینجا مقدمه بود میریم سراغ بحث اصلی.

بحث Graybox Fuzzing بسیار توی این سال‌های اخیر مورد توجه قرار گرفته و سعی میشه توی کابردهای مختلفی بیان و یک فازر Target-specific طراحی کنن. بزرگترین ضعف Fuzzer ها زمانیه که به دنیای Distributed Systems و Concurrency ورود می‌کنن. تمام این حرفایی که توی پست بالا در مورد AFLGo زدم صرفا منوط میشه به برنامه‌های Sequential. توی برنامه‌های ترتیبی چون صرفا یک Thread داریم، واسه همین چیزی به اسم Scheduler وجود نداره در مقابل Fuzzer. مثلا همین مثالی که من زدم یا کیس استادی داچمن، این ابزارها میان با تکنیک‌های Static Analysis بررسی میکنن که آیا اون نقطه Reachable هست و هر جا که لازم باشه برای رسیدن به اون نقطه ورودی تهییه کنن، فازر رو صدا میزنن. خیلی بخوان براتون مرام خرج کنن به جای Static Analysis میان از تکنیک‌های Runtime Analysis استفاده میکنن که البته توی اینم خیلی ضعیفن و اکثر ابزارهای قوی این حوزه تکیه شون به Static Analysis عه. یعنی میان از طریق آنالیز سینتکس کدتون پیش میرن. خود غیرقطعی بودن Fuzzer یک طرف، اینکه Static Analysis بخاطر اینکه خیلی از مسائل کلیدیش Undecidable عه کلی corner case به جا می‌ذاره یک طرف.(اینجا یکم توضیح دادم اینو). خب همه‌ی اینا باعث میشه که Fuzzer ها نسبت به یک سری از برنامه‌های ترتیبی هم حتی خوب عمل نکنن. مثلا فرض کن برای اون فرمول f ای که توی پست قبل آوردیم، بیاد و ۱ میلیارد assignment جنریت کنه ولی هیچکدوم نتونن فرمول رو ارضا کنن. سوال، آیا فرمول ارضا ناپذیره، یا اینکه واقعا assignment ای وجود داره که fuzzer نتونسته پیداش کنه؟ جواب، نمی‌دونیم. ایراد بعدی شون توی برنامه‌های Sequential، گیرم Fuzzer بیاد و یه assignment به ما برگردونه و بگه این کار رو خراب میکنه. آقای داچمن هم برن و کلی کد رو بخونن و بالا و پایین کنن و یک patch ای بدن که دیگه برنامه روی اون assignment به باگ نخوره. آیا به راستی حالا که اینطور شده، باگ برنامه برطرف شده؟ جواب، نمی‌دونیم.

حالا بریم سراغ برنامه‌های Distributed و Concurrent. توی این برنامه‌ها یک چیزی هست به اسم Scheduler که داره thread ها رو زمان‌بندی می‌کنه. فازرها وقتی به چنین سدی میخورن هیچ برنامه‌ای براش ندارن. همینطور رندوم scheduler جلو میره و هر وقت لازم باشه برای جلو رفتن یک input ای داده بشه فازر کال میشه. حتی به فرض تهش هم یک assignment ای برگردونده بشه و شما بفهمی که برنامه‌ات باگ داره. از کجا میخوای بفهمی که چه Scheduling ای ما رو به این باگ رسونده؟ عملا دیباگینگ برنامه غیرممکن میشه. حالا همین آقای Abhik سال پیش یک مقاله‌ای رو چاپ کردن با عنوان Greybox Fuzzing of Distributed Systems که نشون بدن خیز برداشتن برای Distributed System. به زودی همین امسال دیس این مقاله میاد بیرون :) برای پیش درآمدش این تاک رو ببینید ( از 5:17:29 تا 5:48:36)

با همه‌ی این توصیفات جا داره بگم که Fuzzing و Static Analysis به هیچ وجه نمی‌تونن جای خالی Verification رو پر کنن و ما این رو با توسعه JMC نشون خواهیم داد. شما وقتی برنامه‌ات رو با JMC وریفای می‌کنی، اگر باگ داشته باشه قطعا پیداش میکنه، برات یک Execution Trace از ابتدای اجرای برنامه برمیگردونه که نشون بده چی شد که به این باگ رسیدیم و علاوه بر اون دیتای کامل Scheduling ای که ما رو به این باگ رسونده رو هم بهتون میده، شما مقایسه کنید Debugging با این حجم دیتا آسون تره و یا صرفا با داشتن چهار تا Value ؟

حالا برای اینکه خیلی هم سر دیباگینگ اذیت نشید یه کاری رو داریم با خانم Andreea Costa شروع میکنیم، ایشون یکی از محققین گروه Abhik هستند، که با استفاده از JMC برنامه رو وریفای کنیم و وقتی باگ رو پیدا کردیم به شکل Automated برنامه رو Repair کنیم تا دیگه باگی نداشته باشه. یعنی نه تنها باگ رو پیدا کنیم بلکه رفعش کنیم و ثابت کنیم که باگ واقعا رفع شده. تمام تکنیک‌های Automated Program Repair تا به امروز بر پایه‌ی Static Analysis و Fuzzing ساخته شدن و قطعا می‌تونید حدس بزنید که Patch هایی که می‌سازه ممکنه واقعا Bug-free نباشه.

خلاصه که فرمال پیشه کنید.

اگر هم میخواید Fuzzing رو اصولی یاد بگیرید و کار کنید، که بسیار توصیه میشه اینکار رو بکنید،‌ منابعی که اینجا گفتم عالین.

استفاده از LLMها چه بلایی سر یادگیری میاره؟

احتمالا در طی این یک سال شما هم متوجه تاثیر استفاده از "AI" توی پروسه‌ی یادگیریتون شدین. تاثیری که اگر نخوام سخت‌گیر باشم، کفه‌ی ضررش ترازه با منفعتش.

Working hard and struggling is actually an important way of learning. When you’re given an answer, you’re not struggling and you’re not learning. And when you get more of a complex problem, it’s tedious to go back to the beginning of a large language model and troubleshoot it and integrate it.

این مقاله به یک مطالعه راجع‌به تاثیر استفاده از AI در یادگیری و تحصیل و به‌طور مشخص در علوم کامپیتور می‌پردازه. خوندن این مقاله رو بهتون شدیداً توصیه میکنم:

https://cacm.acm.org/news/the-impact-of-ai-on-computer-science-education/

علم چیست؟ شبه‌علم چیست؟

اجازه‌ بدین تا جایی که سوادم قد میده و میدونم یک جواب به این سوال بدم و بعدش برای این که بیشتر بدونیم دو تا پادکستی رو که اخر این پست گذاشتم رو بررسی کنیم.

وقتی راجع‌به علم صبحت میکنیم و این که ادعا کنیم که آیا روشی که به‌کار می‌بریم (یا به ‌کار برده شده) علمی یا scientificه، دو ویژگی براش درنظر گرفته میشه:

۱- تکرار‌پذیری (Replicability) داشته باشه. به این معنی که بشه در شرایط یکسان و با به‌کار گیری روش یک‌سان دوباره به اون نتیجه رسید. البته دو واژه‌ی Reproducibility و Replicability گاها به‌جای هم استفاده میشن. گاهی این دو رو به یک معنا میدونن، گاهی هم تعریف‌های متفاوتی براشون در نظر میگیرن:

In a review paper on the use of the terms reproducibility and replicability, Barba (2018) outlined three categories of usage, which she characterized as A, B1, and B2:

A: The terms are used with no distinction between them.
B1: “Reproducibility” refers to instances in which the original researcher's data and computer codes are used to regenerate the results, while “replicability” refers to instances in which a researcher collects new data to arrive at the same scientific findings as a previous study.
B2: “Reproducibility” refers to independent researchers arriving at the same results using their own data and methods, while “replicability” refers to a different team arriving at the same results using the original author's artifacts.

۲- ابطال‌پذیر (Falsifiable) باشه. به این معنی که اصولا گزاره و نظریه‌ در معرض ابطال باشن. در واقع این امکان وجود داشته باشه که بشه آزمایشی رو طراحی کرد یا مشاهده‌ای رو مطرح کرد که تحت اون بشه اون نظریه یا فرضیه رو رد کرد:

“In so far as a scientific statement speaks about reality, it must be falsifiable: and in so far as it is not falsifiable, it does not speak about reality.”
― Karl R. Popper, The Logic of Scientific Discovery

پس اگر روشی رو مطرح می‌کنیم و ادعا میکنیم که اون علمیه، باید بتونه این دو نیازمندی رو مرتفع کنه. این چیزی بود که من از این ماجرا در خلل بحث‌ها و خوندن‌های پراکنده‌ام بهش رسیدم و امیدوارم که اگر که کافی نیست ولی نقطه‌ی شروع خوبی باشه. حالا با این مقدمه وقتشه بریم سراغ پادکست‌ها:

این اپیزود از پادکست «فلسفه‌ی علم» به این میپردازه که چطور علم رو از شبه‌علم میشه تمیز داد. «ابطال‌پذیری» یا «falsifiability» که پوپر اون رو سنجه‌ای برای تشخیص علم از شبه‌علم عنوان کرد به چه معناست و چه رابطه‌ای بین فلسفه‌ی علم و تاریخ علم وجود داره.

و در ادامه، اگر هم راجع‌به تاریخ علم کنجکاوید و میخوایید بیشتر راجع‌به اون بدونید و این که چرا تاریخ علم نقشی اساسی در فهم ایدئولوژی‌ها و اندیشه‌ها داره، میتونین به اپیزود ۲۹‌م همین پادکست تحت عنوان: «چرا تاریخ اینقدر بنیادین است؟» گوش بدین. مهمان برنامه هم دکتر امیرمحمد گمینی ـه که از اساتید پژوهشکده تاریخ علم دانشگاه تهرانن و در زمینه‌ی تاریخ علم و به طور خاص، تاریخ علم در ایران و اسلام کار میکنن.

شاخص بیگ مک

It’s just a burger, but the price of a Big Mac can help us understand the dizzying cost of living.

“If [the price of a Big Mac is] moving, it means there’s something really strong going on in the economy at large,”
-Leonora Risse, associate professor of economics at the University of Canberra.

راجع به شاخص قدرت خرید و سنجش برابری قدرت خرید (PPP) داخل کانال قبلا یکی دو تا پست گذاشتم که به‌نظرم اون‌ها رو ببینید. ارجاع دادم به ویدیو‌ی چراز که خیلی خوب این ماجرا رو توضیح داده. ولی جهت یادآوری، به طور خلاصه: برای این که بشه قدرت خرید مردم کشور‌های مختلف رو سنجید درحالی که ارزش پول یک‌سان ندارند، روش‌‌های مختلفی وجود داره. یکی از اون روش‌ها، روش غیر رسمی‌ه به‌نام شاخص بیگ مک یا Big Mac Index.

ماجرا از این قراره که با پاسخ دادن به این سوال که شما توی کشورتون، با ۵۰ دلار آمریکا (به طور معمول ارز مبدا رو دلار آمریکا در نظر میگیرن)، چند تا بیگ مک میتونید بگیرید به تخمینی از قدرت خرید مردم اون کشور برسید. این که چرا بیگ مک انتخاب شده و فرقش با PPP چیه، ماجرا از این قراره:

- prevalence of the fast food chain worldwide
- the sandwich remains largely the same across all countries.

توی PPP، ما با سبد کالا سر‌ و ‌کار داریم که اون‌ها رو قراره توی کشور‌های مختلف مقایسه کنیم ولی توی شاخص بیگ‌ مک، تنها یک محصول مطرحه که اتفاقا همه‌جا با احتمال خیلی بالایی یک کیفیت و اندازه رو داره که مقایسه‌پذیریش رو خیلی ساده‌ میکنه.

این مقدمه رو گفتم که این مطلب رو بذارم. تو این مقاله اومدن تغییرات هزینه‌‌ی زندگی و بحران‌هایی که در یک بازه‌ی چند‌ساله (از ۲۰۱۷ تا ۲۰۲۴) رو با همین شاخص بررسی کردن. این که چه تغییرات قیمتی توی اجزای یک ساندویچ بیگ مک پیش اومده و یه سری آمار و ارقام دیگه و به طور خاص به دوره‌ی COVID هم پرداختن. این پست اینتراکتیوه و خیلی حرف رو ساده و سر راست میزنه که خوندنش رو جذاب کرده. اگر حوصله داشتید، به‌نظرم خوندنش براتون میتونه هم جالب باشه هم مفید.

https://www.abc.net.au/news/2024-08-05/cost-of-living-interest-rates-burgers/104156654

پی‌نوشت (یادآوری): من تو آگورا بجز مطالبی که مربوط به علوم کامپیوتره و به‌طور مشخص، موضوعاتی که در راستای شغل‌ و تخصص منه، در چیز دیگه‌ای نه متخصصم و نه اداعایی دارم. حتی در باره‌ی اون‌‌هایی که در حیطه کاری منه هم ادعایی ندارم ولی علی‌الاصول به سبب تجربه‌ و درس خوندن تو اون زمینه‌ها احتمال خطاش توی اون‌ها کمتره. به هر صورت، هیچ‌کدوم از مطالبی که این ‌جا مینویسیم که حاصل برداشت شخصی از کنجکاوی‌های شخصیه، مصون از خطا نیستند. اگر چیزی اینجا نوشتم که غلطه یا فکر میکنید که ساده‌سازیش به صحت مطلب خدشه‌ای وارد کرده خوش‌حال میشم بهم بگید. چه توی pv، چه توی کامنت‌ها.

یه بابایی اومده و کامپیوتر ۸‌بیتی که توی کتاب "But How Do It Know? " نوشته‌ی J Clark Scott توصیف شده رو با Go و Assembly شبیه‌سازی کرده بدون این که درگیر کار با ادوات الکترونیکی بشه. اینجا راجع‌به این تجربه‌ش نوشته:

A few months ago it dawned on me that I didn’t really understand how computers work under the hood. I still don’t understand how modern computers work. However, after making my way through But How Do It Know? by J. Clark Scott, a book which describes the bits of a simple 8-bit computer from the NAND gates, through to the registers, RAM, bits of the CPU, ALU and I/O, I got a hankering to implement it in code.

https://djharper.dev/post/2019/05/21/i-dont-know-how-cpus-work-so-i-simulated-one-in-code/


ولی اگه دلتون میخواد ببینید چطوری میشه همچین کامپیوتری ساخت و نه صرفا شبیه‌سازیش کرد، این پلی‌لیست برای شماست:

Building an 8-bit breadboard computer!

یه یارویی هست تو یوتیوب که میاد چیزای مختلفی رو با لگو می‌سازه. احتمالا ویدیو‌هاش به چشمتون خورده. این ویدیو رو که اخیرا گذاشته واقعا جذاب بود! میاد هربار یک برج لگویی درست میکنه و یک ماشین (باز هم با لگو) طراحی میکنی که بتونه این برج رو خراب کنه. بعد از هر بار که موفق میشه، میاد و سازه‌ش رو سنگین تر و محکم‌تر میکنه طوری که مجبور بشه ماشینش رو بازطراحی کنه که بتونه از پس تخریب سازه‌ی جدید بر بیاد. خودتون ببینید:


https://www.youtube.com/watch?v=HY6q9hwYcoc