Bizdagi ko'pchilik adabiyotlarda asabimga tegadigan eng oddiy narsalardan biri shu. "0 natural son emas, sababi natural sonlar sanashda ishlatiladigan sonlar" deyiladi. Aslidayam xuddi shunday. Masalan, savatda 3 ta olma bor deyilganida 3 bu olmalar soni (ya'ni olmalarni sanadik). Endi savatni bo'shatib, savatdagi olmalarni qaytadan sanab ko'ring. "Savatda olma yo'q" degani aslida "savatda 0 ta olma bor" degani. Prosto, "olma yo'q" deyish linguistik norma. Demak, 0 niyam sanashda ishlatsak bo'larkan. Demak 0 ham natural son.

P.S. 0 ta narsadan iborat boshqa narsalar ham bor. Masalan, Windowsni yaxshi ko'radigan Linuxchilar soni, NeoVim ishlatishini maqtanmaydigan developerlar soni, PHPda yozilgan xavfsiz dasturlar soni, ... .

Tepadagi postdan keyin "lekin sanashni 1 dan boshlaymiz-ku" degan savol chiqishi aniq edi va aynan qiziq joyi ham shunda. O'zi sanash nima?

To'plamlar nazariyasiga ko'ra sanash bu to'plamdagi jami elementlar sonini bildiradigan sonni (ya'ni to'plamning kardinalligini) topish. Gap shundaki, ta'rifga ko'ra o'sha sonni topish muhim, lekin uni qanday topish aniqlashtirilmagan (aniqrog'i, bu muhim emas). To'plamlar nazariyasining eng asosiy aksiomalaridan biriga ko'ra bo'sh to'plamdagi elementlar soni 0 ga teng. Demak, 0 ham sanoqda ishlatiladi va u bo'sh to'plamdagi elementlar sonini bildiradi.

Aslida shu joyda to'xtasak ham bo'lardi, lekin boyagi savol haliyam ochiq qolayapti: nega unda 1 dan boshlab sanaymiz?
Javob tepada aytilgan abstrakt tushuncha - to'plamdagi elementlar sonini konkret ketma-ketlik bilan, ya'ni algoritmik usulda qanday topishimizga borib taqaladi. Eng mashhur va "standart" usul bu incremental yoki recursive approach (biz biladigan 1 dan boshlab sanash). Bu usul uchun ishlatiladigan qoidalar:
– Bo'sh to'plamdagi elementlar soni 0 ga teng.
– Bo'sh bo'lmagan to'plamlar ichida kardinalligi eng kichik to'plamning kardinalligi 1 ga teng ("kardinalligi kichik" nimani bildirishining ham ta'rifi bor).
– Umumiy elementga ega bo'lmagan to'plamlar birlashmasining kardinalligi ularning alohida holatdagi kardinalliklari yig'indisiga teng, ya'ni A ∩ B = ∅ bo'lgan A, B to'plamlar uchun |A ∩ B| = |A| + |B|. Bu qoida ham boshqa bir qoidaning xususiy ko'rinishi.

A to'plamning kardinalligini topish uchun:
– B bo'sh to'plam olamiz.
– A to'plam bo'sh bo'lmagunicha undan kardinalligi 1 ga teng qism to'plamni "ayirib", B to'plamga "qo'shamiz" va B to'plamning kardinalligini qayta hisoblaymiz. Ya'ni A to'plamdan 1 ta element olib B ga qo'shamiz. Bu holatda A to'plamning kardinalligi 1 ga kamayib, B niki 1 ga oshadi.
– Oxirgi operatsiyadan keyin B to'plamning kardinalligi eng boshidagi A to'plamning kardinalligiga teng, sababi tepadagi 3-qoidaga ko'ra har bir qadamda ikkala to'plam birlashmasining kardinalligi o'zgarmayapti.

Savatdagi olmalarni sanash analogimiz bo'yicha boshida hamma olmani "sanalmagan" deb olamiz va sanalmagan olmalar tugaginicha ularni bitta-bittadan"sanalgan"larga o'tkazib chiqamiz. Oxiridagi sanalgan olmalar soni boshidagi sanalmagan olmalar soniga (ya'ni savatdagi jami olmalar soniga) teng bo'ladi.

Lekin ko'pchilik sanashning boshlanish nuqtasi deb sanalganlar 0 ta deb olingan vaqtni emas, 1-olma sanalmaganlardan sanalganlarga o'tkazilgan vaqtni qabul qiladi. Aslida esa "uje" 1 ta qadam o'tib bo'lgan bo'ladi. Xuddi shu sabab sanash 1 dan boshlanadi degan fikr shakllanib qolgan.

P.S. Lambda calculusda sonlar xuddi tepada aytilgan usulda tasvirlanadi. Faqat olmani 1 ta savatdan boshqasiga o'tkazish emas, abstrakt successor funksiyasi bilan.

Pythondagi super() funksiyasi nima vazifani bajaradi?
Javobingizni spoiler sifatida commentda qoldiring.

Endi javoblaringizga asoslanib mana bu kod natijasini toping.

Telegram X'ga anchadan beri yetishmayotgan feature – folderning ichida chat type bo'yicha filter qilish imkoniyati qo'shilibdi.

Qiziq o'yin topib oldim, faqat Windowsga ekan ((
https://store.steampowered.com/app/2060160/The_Farmer_Was_Replaced/

Yaqinda TATU tomonidan o'tkazilgan CTFda qiziq bir holat bo'ldi. Xullas, ma'lum funksiya uchun natijasi ma'lum bir shartni qanoatlantiradigan barcha input parametr qiymatlarining o'rta arifmetigini topish kerak edi. Bruteforce qilib ko'rdik va natija 127.5 chiqdi, lekin bu javob noto'g'ri ekan. Qayta-qayta tekshirib ko'rdik, lekin bir xil natija. Xullas, o'sha savolni yecha olmadik va oxirida 3-o'rinni oldik (yechganimizda 1-o'rinni olardik).

Ertasiga tashkilotchilardan so'rasam yo'nalish to'g'ri ekani, lekin hisob-kitobda xato bo'lishi mumkinligini aytishdi. Oxirida muammo kutilmagan bo'lib chiqdi: ular o'rta arifmetikni hisoblash uchun integer divisiondan foydalangan ekan😂 (lekin bu haqida shartda hech qanday ma'lumot berilmagan). Lekin na natijalar o'zgardi, na bu haqida biror joyda e'lon qilindi.

Xulosa: Agar to'g'ri javobni topa olmasang siqilma, ba'zan savolni tuzganlar ham topa olmagan bo'lishi mumkin.

Kanalda qanday mavzular bo'yicha uzunroq postlarni ko'rishni xohlaysiz?
Tuzukroq post yozmaganimgayam ancha bo'libdi.

Home is where you connect to wifi automatically
Home is where your internet works in 2G

We need a paradigm that is more predictable than Procedural Programming, more efficient than Object Oriented Programming and less fancy than Functional Programming.

5 programming language trends to look for in the next 10 years:

1. Moving (back) from developer comfort to code efficiency. We've created an insane amount of unnecessary abstractions in the name of "making developer's life easier". So much so that only a fraction of total computing power is spent to do the actual work in traditional software systems, the rest is simply wasted to deal with abstractions. With the current generation of computer hardware reaching to its maximum potential, the only real way to improve performance is gonna be making the software more efficient by chopping of as much unnecessary layers as possible, unless a breakthrough happens in hardware industry.

2. Immutability and statelessness. As they say, "Shared state is the root of all evil". Search the phrase and you'll find way more information than I could ever write here. My point is, even systems engineers (who usually loves to deal with nasty stuff) are getting tired of shared state shenanigans and I think they are gonna be the ones that will convert much of existing infrastructure to immutable.

3. Moving stuff from runtime to compile time as much as possible. With ideas coming from fields like Type Theory and Abstract Algebra in general, now we can predict a reasonably wide domain of "bad" program behaviours before actually running it. The best part is, we can completely eliminate most of them in compile time by adding new rules which we can guarantee that won't lead to such "bad" states. Current implementation of memory management in Rust is a great example of this approach.

4. New approach to concurrency and parallelism. Although general-purpose operating systems are fairly good at performing various kind of tasks, fairly good is not good enough for specific applications. A classic example is concurrency and parallelism. Although OS-level active units like processes and threads are good for average OS-level tasks, they are too heavy and not flexible enough to be directly used in modern languages with very dynamic behaviour. So, more and more languages are coming up with their own solutions often in the form of language-level units that are very light and flexible alternative of OS-level threads. Also it's worth mentioning that this kind of approach often involves some sort of tricks to make resources like CPU time and memory pages more predictable, which the underlying OS developers wouldn't appreciate. After all, language developers want their program to perform better, where OS developers want the whole system to perform better.

5. Rise of multi-mode languages. Compilers can do hell lot of optimization for you, but it usually makes compiling process much longer. On the other hand, you only need such fine-tuned software in production environments. Unoptimized and rough version of the same software (which can be compiled much faster) is usually good enough for various kinds of testing and debugging purposes. So, why not give developers an option to chooses how much optimized result they want? Of course, both compiled and interpreted languages are doing a bunch of tricks to achieve something similar, but I think solutions in the next 10 years is gonna be more fundamental. Maybe, a language that is normally interpreted, but can compile the code to executable when it's ready for production.

Mobile internetni yoqasan, o'lgudek sekin. fast.com'ga kirib tekshirib ko'rasan, yaxshi ishlayapti deydi. Keyin VPN bilan qaytadan kirib ko'rasan, endi sekin ko'rsatishni boshlaydi. Qolgan saytlarga kirib ko'rasan, bir xil ishlayapti. VPNda muammo yo'q, o'z-o'zidan 1 ta variant qoladi: ataylab sekinlatishayapti. "Mana, zo'r ishlayapti" deyish uchun faqat fast.com'ni tez ochib berishadi. O'ynab qo'yay bundaychikin operatorlaringga.

Alright, let's discuss. Leave your opinion in the comments about these 5 points (why it might or might not be the case). Also, you can introduce your own predictions for incoming PL trends.

By the way, I've watched Hussein's OS course recently. In short, I'm not satisfied with the course. I was expecting it to be way better considering the time it took to be released. I'll try to write a detailed review later on.

Universitet tomonidan tashkillashtirilgan "Integrable Systems Related to Reflection Groups in Algebra, Geometry and Topology" mavzusida o'tkazilayotgan yozgi maktabda qatnashayapman. Anchadan beri pure math bilan shug'ullanmay qo'yganim sezilayapti. Mavzularni yaxshi tushunish va orqada qolib ketmaslik uchun anchagina mehnat qilishga to'g'ri kelayapti.

Yaqinda kimdir shu mavzuda savol so'ragandi, hozir kimligini eslay olmaganim uchun linkni kanalga qo'yayapman.

https://youtu.be/7G4ipM2qjfw?si=bbX58y4sHJd5Gd1e

Knowledge of the day: Ham sandwich theorem