कोरियन input method इतना असुविधाजनक था कि इस्तेमाल ही नहीं कर पाता था, लेकिन क्या आजकल यह काफी बेहतर हो गया है? Chrome वगैरह में input छूट जाना या आखिरी अक्षर मिट जाना जैसी समस्याएँ काफ़ी गंभीर थीं।
यह तरीका मैंने 25 साल पहले, जब मैं एक गेम कंपनी में काम करता था, तब debug code के रूप में अपनाया था—और क्या सिर्फ strcpy ही समस्या थी? Release में speed बढ़ाने के लिए इन्हें फिर से खोलकर ही service की गई थी। दरअसल गेम इंडस्ट्री में memory collision सबसे संवेदनशील मुद्दों में से एक है, इसलिए काम भी बहुत सावधानी और पूरी सतर्कता से किया जाता था, यहाँ तक कि memory debugger भी हमने खुद बनाकर इस्तेमाल किया था। लेकिन आज पीछे मुड़कर देखता हूँ तो पता चलता है कि वही चीज़ दरअसल garbage collection बना रही थी। धुंधली-सी यादें हैं।
ओहो, बहुत अच्छा लगा पढ़कर। आपने कहा कि अतिरिक्त सत्यापन करना है या नहीं, यह विश्वसनीयता के आधार पर तय किया जाता है, तो यह भी जानना चाहूंगा कि यह विश्वसनीयता किस तरह मापी गई वैल्यू थी।
VLM का इस्तेमाल करके समस्या को बहुत अच्छे से हल किया गया है, पढ़कर मज़ा आया।
पोस्ट पढ़कर मेरे मन में एक सवाल आया है।
YOLO डिटेक्शन – सिर्फ मुख्य ऑब्जेक्ट को crop करके analysis की सीमा कम करना
यह प्रक्रिया आपने कैसे जोड़ी, यह जानने की जिज्ञासा है।
पोस्ट पढ़ते समय मुझे लगा कि VLM की performance शायद YOLO से बेहतर होगी, इसलिए उल्टा crop करने पर कहीं ऐसा तो नहीं कि YOLO मॉडल गलत निर्णय कर दे और VLM तक पहुँचने से पहले ही महत्वपूर्ण जानकारी खो जाए।
crop करने का विचार आपको किस समस्या के कारण आया, और उसकी accuracy को कैसे validate करके इसे लागू किया, यह जानना चाहता हूँ।
कुछ high-end MCU में, जैसा आपने कहा, MPU के ज़रिए केवल access permissions ही नहीं बल्कि cache से जुड़ी properties भी region unit के आधार पर सेट की जा सकती हैं। इसके लिए ST का यह material अच्छा reference होगा: https://community.st.com/t5/stm32-mcus/…
हालाँकि, इस लेख में इस्तेमाल किए गए ESP32-S3 में general-purpose CPU या कुछ MCU की तरह memory region के हिसाब से cacheable / non-cacheable properties को MPU या किसी समान mechanism से सेट करने का तरीका उपलब्ध नहीं है।
ESP32-S3 के मामले में external memory (Flash/PSRAM) को cache/MMU के माध्यम से access करने के लिए डिज़ाइन किया गया है (TRM 4.3.3 External Memory), और access permission control PMS(Permission Management System) के माध्यम से होता है (TRM Chapter 15), लेकिन यह सुविधा access protection के लिए है; यह cache के रास्ते access करना है या नहीं, या access path itself को बदलने का काम नहीं करती।
त्रुटि C4996 'strcpy' : यह function या variable असुरक्षित हो सकता है। strcpy_s का उपयोग करने पर विचार करें। deprecation को disable करने के लिए _CRT_SECURE_NO_WARNINGS का उपयोग करें। details के लिए online help देखें.
बड़ा प्रभाव और उसके अनुरूप बहुत अधिक पारिश्रमिक लेना संभव हो सकता है, लेकिन इससे यह बात अपने-आप सिद्ध नहीं होती कि वही व्यक्ति "कंपनी में सक्रिय रूप से जोखिम उठाने वाला एकमात्र व्यक्ति" है। और जिसे चुना गया है, वह बड़ा शेयरधारक है या नहीं, इस पर निर्भर करते हुए तो यह बात और भी कम सही बैठती है.
अगर यही तर्क मानें, तो कर्मचारी का प्रभाव छोटा होने के कारण वह छोटी ज़िम्मेदारी उठाएगा और छोटी सैलरी पाएगा, लेकिन उसी तरह वह भी सक्रिय ज़िम्मेदारी उठाने वाला कर्मचारी होगा, और CEO के भी AI से प्रतिस्थापित न किए जा सकने का कोई कारण नहीं है.
आपने अपनी पहली टिप्पणी में जो तर्क दिया था, वह यह नहीं था क्या कि CEO ही सक्रिय जोखिम उठाने वाला एकमात्र व्यक्ति है, इसलिए उसे AI से प्रतिस्थापित नहीं किया जा सकता?
आह, generic कंप्यूटरों से अलग, ESP32 जैसे MCU में ऐसा MMU नहीं होता जो runtime पर page unit के हिसाब से memory properties बदल सके, और cacheable / non-cacheable होना पहले से तय memory region unit के आधार पर निर्धारित होता है, इसलिए जैसा आपने कहा वैसा इस्तेमाल करना संभव नहीं है (internal SRAM पूरी तरह non-cacheable है, और PSRAM पूरी तरह cacheable memory के रूप में fixed है).
आपने जो cache consistency की बात की, उसकी वजह से हर बार cache invalidate करना पड़ता होगा, तो फिर इसे सीधे non-cacheable क्षेत्र में इस्तेमाल क्यों नहीं किया गया, यही जानने की उत्सुकता थी।
इसीलिए आजकल गुरु लोग कहते हैं कि नए लोग agents को कहीं बेहतर इस्तेमाल करते हैं। जो चीज़ उन्हें लंबे समय तक पैसे कमाने देती रही, उसे वे unlearn ही नहीं कर पा रहे हैं।
kime इनपुट मेथड की सिफारिश करता हूँ
कोरियन input method इतना असुविधाजनक था कि इस्तेमाल ही नहीं कर पाता था, लेकिन क्या आजकल यह काफी बेहतर हो गया है? Chrome वगैरह में input छूट जाना या आखिरी अक्षर मिट जाना जैसी समस्याएँ काफ़ी गंभीर थीं।
यह एक तीखा अवलोकन है। इंसानों की error rate तो इससे भी ज़्यादा होती है..
यह तरीका मैंने 25 साल पहले, जब मैं एक गेम कंपनी में काम करता था, तब debug code के रूप में अपनाया था—और क्या सिर्फ
strcpyही समस्या थी? Release में speed बढ़ाने के लिए इन्हें फिर से खोलकर ही service की गई थी। दरअसल गेम इंडस्ट्री में memory collision सबसे संवेदनशील मुद्दों में से एक है, इसलिए काम भी बहुत सावधानी और पूरी सतर्कता से किया जाता था, यहाँ तक कि memory debugger भी हमने खुद बनाकर इस्तेमाल किया था। लेकिन आज पीछे मुड़कर देखता हूँ तो पता चलता है कि वही चीज़ दरअसल garbage collection बना रही थी। धुंधली-सी यादें हैं।ओहो, बहुत अच्छा लगा पढ़कर। आपने कहा कि अतिरिक्त सत्यापन करना है या नहीं, यह विश्वसनीयता के आधार पर तय किया जाता है, तो यह भी जानना चाहूंगा कि यह विश्वसनीयता किस तरह मापी गई वैल्यू थी।
संदर्भ के लिए, gpt-4o-mini मॉडल में image input के समय input tokens की लागत काफ़ी ज़्यादा होती है, इसलिए मैं सुझाव दूंगा कि आप दूसरे lightweight models पर भी विचार करें!
VLM का इस्तेमाल करके समस्या को बहुत अच्छे से हल किया गया है, पढ़कर मज़ा आया।
पोस्ट पढ़कर मेरे मन में एक सवाल आया है।
यह प्रक्रिया आपने कैसे जोड़ी, यह जानने की जिज्ञासा है।
पोस्ट पढ़ते समय मुझे लगा कि VLM की performance शायद YOLO से बेहतर होगी, इसलिए उल्टा crop करने पर कहीं ऐसा तो नहीं कि YOLO मॉडल गलत निर्णय कर दे और VLM तक पहुँचने से पहले ही महत्वपूर्ण जानकारी खो जाए।
crop करने का विचार आपको किस समस्या के कारण आया, और उसकी accuracy को कैसे validate करके इसे लागू किया, यह जानना चाहता हूँ।
ओह, यह काफ़ी अच्छा लग रहा है। अच्छा होगा अगर इसे कई भाषाओं में port किया जाए!
ऐसा लग रहा है कि यह संरचनात्मक समस्या में बदलकर उसका समाधान करने से ज़्यादा, एक नया मॉडल बनाने जैसा है।
कुछ high-end MCU में, जैसा आपने कहा, MPU के ज़रिए केवल access permissions ही नहीं बल्कि cache से जुड़ी properties भी region unit के आधार पर सेट की जा सकती हैं। इसके लिए ST का यह material अच्छा reference होगा: https://community.st.com/t5/stm32-mcus/…
हालाँकि, इस लेख में इस्तेमाल किए गए ESP32-S3 में general-purpose CPU या कुछ MCU की तरह memory region के हिसाब से cacheable / non-cacheable properties को MPU या किसी समान mechanism से सेट करने का तरीका उपलब्ध नहीं है।
ESP32-S3 के मामले में external memory (Flash/PSRAM) को cache/MMU के माध्यम से access करने के लिए डिज़ाइन किया गया है (TRM 4.3.3 External Memory), और access permission control PMS(Permission Management System) के माध्यम से होता है (TRM Chapter 15), लेकिन यह सुविधा access protection के लिए है; यह cache के रास्ते access करना है या नहीं, या access path itself को बदलने का काम नहीं करती।
TRM(Technical Reference Manual) लिंक: https://documentation.espressif.com/esp32-s3_technical_reference_manua….
त्रुटि C4996
'strcpy': यह function या variable असुरक्षित हो सकता है।strcpy_sका उपयोग करने पर विचार करें। deprecation को disable करने के लिए_CRT_SECURE_NO_WARNINGSका उपयोग करें। details के लिए online help देखें.MMU नहीं है, लेकिन MPU से memory region और उनकी properties तय की जा सकती हैं.
एक बार इसे review कर लें तो अच्छा रहेगा
बड़ा प्रभाव और उसके अनुरूप बहुत अधिक पारिश्रमिक लेना संभव हो सकता है, लेकिन इससे यह बात अपने-आप सिद्ध नहीं होती कि वही व्यक्ति "कंपनी में सक्रिय रूप से जोखिम उठाने वाला एकमात्र व्यक्ति" है। और जिसे चुना गया है, वह बड़ा शेयरधारक है या नहीं, इस पर निर्भर करते हुए तो यह बात और भी कम सही बैठती है.
अगर यही तर्क मानें, तो कर्मचारी का प्रभाव छोटा होने के कारण वह छोटी ज़िम्मेदारी उठाएगा और छोटी सैलरी पाएगा, लेकिन उसी तरह वह भी सक्रिय ज़िम्मेदारी उठाने वाला कर्मचारी होगा, और CEO के भी AI से प्रतिस्थापित न किए जा सकने का कोई कारण नहीं है.
आपने अपनी पहली टिप्पणी में जो तर्क दिया था, वह यह नहीं था क्या कि CEO ही सक्रिय जोखिम उठाने वाला एकमात्र व्यक्ति है, इसलिए उसे AI से प्रतिस्थापित नहीं किया जा सकता?
मुझे तो यह ज़्यादा काम का नहीं लग रहा..
आह, generic कंप्यूटरों से अलग, ESP32 जैसे MCU में ऐसा MMU नहीं होता जो runtime पर page unit के हिसाब से memory properties बदल सके, और cacheable / non-cacheable होना पहले से तय memory region unit के आधार पर निर्धारित होता है, इसलिए जैसा आपने कहा वैसा इस्तेमाल करना संभव नहीं है (internal SRAM पूरी तरह non-cacheable है, और PSRAM पूरी तरह cacheable memory के रूप में fixed है).
अच्छा सवाल पूछने के लिए धन्यवाद!
वाह, ये तो इसे बाँट रहे हैं.. सच में बहुत डरावनी कंपनी है।
यह अफरातफरी आखिर कब शांत होगी, किसी भी तरह से,,
सार्वजनिक छुट्टियों का प्रदर्शन बहुत अच्छा है
> Luck = [Doing Things] × [Telling People]
मुझे लगता है मैंने यह फ़ॉर्मूला कुछ साल पहले भी देखा था, लेकिन इस दौरान मैं इसे ठीक से अमल में नहीं ला पाया।
आपने जो cache consistency की बात की, उसकी वजह से हर बार cache invalidate करना पड़ता होगा, तो फिर इसे सीधे non-cacheable क्षेत्र में इस्तेमाल क्यों नहीं किया गया, यही जानने की उत्सुकता थी।
इसीलिए आजकल गुरु लोग कहते हैं कि नए लोग agents को कहीं बेहतर इस्तेमाल करते हैं। जो चीज़ उन्हें लंबे समय तक पैसे कमाने देती रही, उसे वे unlearn ही नहीं कर पा रहे हैं।