Advent of Code 2024

 (adventofcode.com)
1 पॉइंट द्वारा GN⁺ 2024-12-02 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • दिसंबर का programming puzzle event Advent of Code इस तरह डिज़ाइन किया गया है कि skill और language choice की बाधाएँ कम हों, ताकि लोग practice, education, competition जैसी अलग-अलग वजहों से इसमें भाग ले सकें
  • computer science background या high-performance hardware होना ज़रूरी नहीं है, और हर problem का ऐसा solution मौजूद है जो 10 साल पुराने hardware पर अधिकतम 15 सेकंड में पूरा हो जाता है
  • अगर solution अटक जाए, तो example जाँचने, खुद के बनाए test cases, input validation, और फिर दोस्तों या subreddit hints की मदद से समस्या को सीमित किया जा सकता है
  • 2024 FAQ में event duration में बदलाव, global leaderboard हटाना, private leaderboard नियम, AI का उपयोग, और copying·redistribution restrictions जैसी operational policies को समेटा गया है
  • speed competition वैकल्पिक है, और प्रतिभागी puzzles हल करने और सीखने पर अपने लिए उपयोगी तरीके से ध्यान केंद्रित कर सकते हैं

Advent of Code की प्रकृति और भागीदारी की शर्तें

  • Advent of Code Advent calendar फ़ॉर्मेट का एक event है, जिसमें छोटे programming puzzles होते हैं
  • puzzles अलग-अलग skill levels के लिए होते हैं, और इन्हें अपनी पसंद की programming language में हल किया जा सकता है
  • इसका उपयोग interview preparation, company training, university assignments, practice problems, speed competition, और प्रतिभागियों के बीच challenges के लिए किया जाता है
  • computer science background अनिवार्य नहीं है; थोड़ी programming knowledge और problem-solving ability के साथ भी इसमें भाग लिया जा सकता है
  • high-performance computer की भी ज़रूरत नहीं है, और हर problem का ऐसा solution है जो 10 साल पुराने hardware पर अधिकतम 15 सेकंड में पूरा हो जाता है

अटकने पर हल करने की प्रक्रिया

  • अगर solution अटक जाए, तो पहले puzzle में दिए गए examples से program को verify करना चाहिए
  • अगर example result सही नहीं आता, तो problem description दोबारा पढ़ें और देखें कि कहाँ गलतफहमी हुई या program अपेक्षा से अलग कैसे काम कर रहा है
  • अगर examples सही हैं लेकिन answer गलत है, तो ऐसे test cases खुद बनाकर program पर लागू करें जिनका answer हाथ से verify किया जा सके
  • यह भी जाँचना चाहिए कि पूरा puzzle input बिना किसी चूक के इस्तेमाल हुआ है या नहीं
  • अगर फिर भी बात न बने, तो दोस्तों से मदद माँग सकते हैं, बाद में फिर से कोशिश कर सकते हैं, या subreddit से hints ले सकते हैं

साइट का उपयोग और authentication

  • code blocks में, अगर JavaScript enabled है, तो triple-click करके पूरा block select किया जा सकता है
  • authentication के लिए OAuth का उपयोग करके external services के माध्यम से पहचान verify की जाती है
    • login करते समय credentials Advent of Code को नहीं, केवल उस external service को दिए जाते हैं
    • external service Advent of Code server को बताती है कि user वही व्यक्ति है
    • आम तौर पर पहले से public information के अलावा कोई अतिरिक्त जानकारी उजागर नहीं होती
    • Advent of Code authentication service का unique ID, name, URL, और image याद रखता है
  • अगर साइट का text पढ़ना मुश्किल लगे, तो high-contrast alternate stylesheet का उपयोग किया जा सकता है
    • Firefox में View → Page Style → High Contrast का built-in support है

कठिनाई, रिलीज़ समय, और event की अवधि

  • puzzles की difficulty और themes हर event में अलग होती हैं
  • आम तौर पर समय के साथ puzzles कठिन होते जाते हैं, लेकिन किसी व्यक्ति के skill combination के अनुसार महसूस होने वाली कठिनाई बहुत अलग हो सकती है
  • puzzles EST/UTC-5 मध्यरात्रि में जारी किए जाते हैं
    • क्योंकि वह समय organizer के लिए यह सुनिश्चित करने के लिए स्थिर होता है कि सब कुछ बिना समस्या के चल रहा है
    • अगर आप मध्यरात्रि में भाग नहीं ले सकते तो भी कोई समस्या नहीं; स्थानीय प्रतिस्पर्धा के लिए private leaderboards का उपयोग किया जा सकता है
  • event के दिनों की संख्या बदली गई है
    • Advent of Code चलाने में हर साल बहुत सारा free time लगता है, और उसका अधिकांश हिस्सा puzzles बनाने में जाता है
    • 10 साल तक schedule बनाए रखने के बाद बदलाव की ज़रूरत पड़ी
    • puzzles तारीख़ के नंबर से मेल खाने के लिए 1 दिसंबर से शुरू होते हैं, रोज़ाना जारी होते हैं, और दिसंबर के मध्य में समाप्त हो जाते हैं

leaderboard और speed competition

  • global leaderboard हटा दिया गया है
    • यह organizer, infrastructure, और कई users के लिए सबसे बड़े stress factors में से एक था
    • कुछ प्रतिभागी competition को ज़रूरत से ज़्यादा गंभीरता से लेने लगे थे, और DDoS attacks जैसी हरकतें भी हुईं
    • कई users ने केवल इसलिए गलत निष्कर्ष निकाला कि उनका समय तुलना के अन्य लोगों से धीमा था, इसलिए वे खुद को कमज़ोर programmer समझने लगे
    • यह 2015 में एक मज़ेदार feature के रूप में शुरू हुआ था, लेकिन 10 साल में यह लगातार बढ़ती समस्या बन गया
  • private leaderboard का read-only view share किया जा सकता है
    • इस feature या data का उपयोग करके नया global leaderboard नहीं बनाना चाहिए
  • तेज़ solving time वैकल्पिक है
    • जल्दी हल करने के लिए puzzle-solving के अलावा कई अतिरिक्त skills और बहुत practice की ज़रूरत होती है
    • speed-solve code अक्सर उस code से बिल्कुल अलग दिखता है जो code review pass कर सके
    • अपने लिए उपयोगी goals के अनुसार तरीका चुनना और speed competition को पूरी तरह नज़रअंदाज़ करना भी ठीक है

AI का उपयोग और private leaderboard के नियम

  • अगर आप किसी private leaderboard का हिस्सा हैं, तो organizer से अपेक्षित नियम ज़रूर जाँचें
  • अगर नियम आपको उपयुक्त न लगें, तो किसी दूसरे private leaderboard को खोज सकते हैं या खुद बना सकते हैं
  • private leaderboard के नियमों में maximum execution time, allowed languages, puzzle पहली बार कब खोला जा सकता है, कौन-से tools इस्तेमाल किए जा सकते हैं, यहाँ तक कि काम करते समय मज़ाकिया टोपी पहननी है या नहीं, जैसी बातें शामिल हो सकती हैं
  • Advent of Code puzzles हल करते समय AI का उपयोग recommended नहीं है
    • इसके लिए यह उपमा दी गई है कि क्या दोस्त को gym भेजने से आप खुद मज़बूत हो जाएँगे
    • puzzles इस तरह डिज़ाइन किए जाते हैं कि इंसानों के लिए हल करना रोचक हो; AI उन्हें हल कर सकता है या नहीं, यह ध्यान में नहीं रखा जाता
    • अगर उद्देश्य AI prompting practice है, तो उस उद्देश्य के लिए डिज़ाइन की गई दूसरी exercises ज़्यादा उपयुक्त हो सकती हैं

puzzle ideas, bugs, और copying policy

  • puzzle ideas नहीं भेजने चाहिए
    • copyright और attribution जैसे कानूनी मुद्दों के कारण ideas स्वीकार नहीं किए जाते
    • गलती से किसी हिस्से का उपयोग हो जाने की संभावना से बचने के लिए puzzle idea जैसे दिखने वाले emails भी नहीं पढ़े जाते
  • अगर आपको लगे कि आपने puzzle bug खोज लिया है, तो पहले subreddit पर जाँच करनी चाहिए
    • puzzle जारी होने के एक घंटे बाद तक बहुत से लोग उसे हल कर चुके होते हैं, इसलिए उसके बाद bug होने की संभावना बहुत कम होती है
  • Advent of Code का उपयोग मुफ़्त है, लेकिन उसकी copying स्वतंत्र नहीं है
    • अपने code repository में puzzle text या अपने input जैसे Advent of Code के हिस्से शामिल नहीं करने चाहिए
    • website बनाते समय उसे Advent of Code जैसा नहीं दिखाना चाहिए और न ही वैसा मिलता-जुलता नाम देना चाहिए

कानूनी सूचना और अनुमत दायरा

  • Advent of Code अमेरिका में registered trademark है
  • Advent of Code के design elements, wording, style, और concept उसकी एकमात्र संपत्ति हैं, और स्पष्ट लिखित सहमति के बिना उन्हें reproduce या use नहीं किया जा सकता
  • copyright notice 2015-2025 Advent of Code है और सभी अधिकार सुरक्षित हैं
  • discussions, classes, source code, print materials आदि में Advent of Code puzzles को link या refer किया जा सकता है, और यह commercial context में भी संभव है
  • Advent of Code users के solution implementations पर ownership या copyright claim नहीं करता

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-12-02
Hacker News की राय

  • AoC पसंद है, इसलिए पिछले 2–3 साल Rust में हल किया, और Discord पर सब मिलकर सबसे तेज़ solution बनाने जैसा खेलते रहे
    उस प्रक्रिया में तरह-तरह की performance optimization tips, advanced algorithms और SIMD सीखा
    इस बार Rust और Go में हल कर रहा हूँ, यह देखने के लिए कि क्या काम पर इस्तेमाल होने वाले Go को पसंद कर पाऊँगा या झेल पाऊँगा, या फिर यह hypothesis पक्का करूँगा कि यह खास नहीं है और इसे केवल बहुत ज़रूरी होने पर ही इस्तेमाल करूँगा

    • पिछले कुछ सालों से Go में हल करके देखा है; day 6 के बाद आगे जाने का समय या focus हमेशा कम पड़ता था, लेकिन इस तरह के काम के लिए यह काफ़ी अच्छा लगा
      यह practical है, environment setup या side work कम है, file पढ़ने/parsing जैसी ज़रूरी चीज़ें ज़्यादातर built-in हैं, performance भी अच्छी है और hardware के काफ़ी करीब है, इसलिए छिपे हुए performance traps कम हैं
      Rust कभी इस्तेमाल नहीं किया, इसलिए तुलना करना मुश्किल है, लेकिन बहुत सतही तौर पर देखें तो यह कम practical लगता है
      AoC में memory safety जैसे production standards की बहुत ज़रूरत नहीं होती, इसलिए बाद के problems में safety से ज़्यादा practicality और performance अहम लगते हैं
    • Rust में तेज़ी से solve करने वाला approach जानने में दिलचस्पी है; अगर share करने लायक कोई link हो तो देखना चाहूँगा
    • अच्छा होगा अगर Discord share कर सकें
      हर साल Zig में speed optimization करने की कोशिश करता हूँ: https://github.com/ManDeJan/advent-of-code
    • Go "Golang" नहीं है, और Rust की तुलना में इसकी compile time बेहतर है, साथ ही यह एक-दूसरे से match न होने वाले concurrency usage patterns को जबरन जोड़ने की कोशिश नहीं करता
      बल्कि उल्टा, मेरे सामने Rust को पसंद करने की कोशिश करने वाली दुविधा है
    • यह जानना चाहता हूँ कि AoC project को कैसे structure करते हैं
      Rust में करने की कोशिश की थी, लेकिन समझ नहीं आया कि तारीख़ के हिसाब से modules बाँटने चाहिए, या हर date को library file की तरह रखकर main entry point से connect करना चाहिए
      अगर कोई public repository हो तो share कर दें

  • इस साल की challenge है standard library या allocator के बिना C में लिखना
    इसे 32KB SRAM वाले STM32 पर चलने लायक होना चाहिए
    2 साल पहले assembly में करके देखा था, लेकिन assembly के लिए standard library बनाने में घंटों लगाने के बाद हार मान ली और Rust पर switch कर गया

    • पिछले साल असली Amiga 1200 पर C में करके देखा था, और DICE नाम का Matt Dillon का compiler/runtime इस्तेमाल किया था
      बहुत आगे नहीं बढ़ पाया, लेकिन memory protection न हो तो चीज़ें सचमुच मुश्किल हो जाती हैं
      इस साल Amiga में MMU वाला 060 upgrade है, तो शायद यह समझकर कि उसका कैसे उपयोग करूँ, फिर से कोशिश कर सकता हूँ
    • इस साल भी Common Lisp में जा रहा हूँ, लेकिन पहले दिन की problem को अपनी "जानकारी" वाली हर भाषा में हल करने का तय किया
      C भी शामिल था, लेकिन hash table न होने से सचमुच दर्दनाक रहा
      https://git.sr.ht/~q3cpma/aoc2024/tree/master/item/01
      अगर progress देखने के लिए repository link डाल दें तो अच्छा होगा
    • वह constraint काफ़ी कठिन लगता है, लेकिन शुभकामनाएँ
      पिछले साल external libraries के बिना C में सभी problems हल किए थे [1], और बहुत मज़ा आया
      इसने भूली हुई low-level चीज़ें, जैसे heap, खुद implement कराईं, और numeric routines भी खुद लिखने पड़े, जो उम्मीद से आसान निकले
      [1] https://github.com/sebastianotronto/aoc/tree/master/2023
    • अगर RPC calls कर सकें तो 32KB RAM में भी कुछ भी किया जा सकता है :-)
    • symmetric तरीके से देखें तो sh और Turing-complete न होने वाले standard CLI tools ही इस्तेमाल करना भी सोचने लायक है
      grep चल सकता है, awk नहीं—कुछ इसी तरह; वैसा ही सीमित, लेकिन खतरनाक memory corruption bugs नहीं

  • आम तौर पर AoC Common Lisp में करता हूँ, लेकिन इस साल Swift आज़मा रहा हूँ
    statically typed mainstream language के हिसाब से यह ऐसी छोटी-मोटी manipulations के लिए काफ़ी ठीक है
    https://github.com/codr7/aoc24/tree/main/swift/Sources/aoc
    यह साल थोड़ा अजीब है; मैं अपनी नई job में event तैयार कर रहा था
    क्योंकि मुझे लगा कि यह developers के लिए frameworks जोड़ने से ज़्यादा, असली problem solving सीखने में उपयोगी है
    लेकिन नया boss ऐसा निकला जिसके साथ बिल्कुल काम नहीं किया जा सकता, इसलिए मुझे छोड़ना पड़ा
    अंत में हमेशा की तरह शायद बस मैं और Emacs ही रहेंगे

    • अगर अभी तक नहीं किया है तो Swift leaderboard में शामिल होना अच्छा रहेगा: https://forums.swift.org/t/advent-of-code-2024
      अलग-अलग solutions की तुलना करना काफ़ी दिलचस्प है
    • जानना चाहता हूँ कि Swift में string parsing और manipulation काफ़ी दर्दनाक नहीं है क्या
      पहले Swift में AoC करने की कोशिश की थी, लेकिन इसी हिस्से की वजह से काफी ठंडा पड़ गया
      छोटी functional one-liners अच्छी थीं, लेकिन करीब एक हफ्ते बाद parsing burden बहुत ज़्यादा हो जाएगा ऐसा लगता है
    • जानना चाहता हूँ कि solution लिखना, compile करना और run करना सब Emacs से ही करते हैं क्या
      इस साल Swift आज़माना चाहता था, लेकिन इसके लिए Xcode खोलना थोड़ा ज़्यादा लगता है

  • फिर लौट आया, 25 दिनों तक धीरे-धीरे complex होते input parsers लिखने का season

    • ऐसे problems सबसे ज़्यादा नापसंद हैं
      असली problem input को handle करने लायक form में parse करने में होती है, और एक बार parsing हो जाए तो आसान हो जाता है
    • कुछ दिन बाद आखिरकार regular expressions इस्तेमाल करने पड़ते हैं, और हर साल भूल जाता हूँ इसलिए फिर से सीखना पड़ता है
    • input parser तारीख़ बढ़ने के साथ complex नहीं होता
      complex होती है problem खुद, और day 22 या 23 के आसपास की कठिन problem में भी input आम तौर पर whitespace से अलग की गई integers की lines या dots की grid जैसा होता है, यानी day 1–3 की आसान problems जैसा
    • input parsing में बस एक मज़ेदार कहानी जोड़ दी गई है
    • मेरे हिसाब से split/explode style parser की तुलना में scanf और state machine कहीं ज़्यादा effective हैं

  • इस साल लक्ष्य है सभी स्टार इकट्ठा करके कुल 500 स्टार पूरे करना
    यानी सभी सालों के सभी problems खत्म करना
    पिछले हफ्ते तक करीब 1024 लोग ऐसे थे जिनके पास कुल 450 स्टार थे
    मैंने 2022 के day 6 के आसपास ही शुरू किया था, लेकिन इसमें डूब गया, और 2023 की शुरुआत में समय मिला तो पिछले सालों के problems लगातार हल किए
    कुछ algorithms तैयार रखो तो यह बहुत मुश्किल नहीं होता, और हर साल कुछ topics दोहराए भी जाते हैं
    आम तौर पर जिन असली algorithms को अक्सर नहीं छूते, उन्हें फिर से सीखने का मज़ा है
    volunteers और Eric का धन्यवाद, और अब हर साल donate करने का सोच रहा हूं। सच में बहुत अच्छा event है

  • यह इस समय के highlights में से एक है, इसलिए अच्छा लगता है
    इस बार इसे प्रशांत महासागर को पूर्व दिशा में पार करती flight में हल करना पड़ा
    मेरे लिए भी, दोस्तों·सहकर्मियों·HN के लोगों के लिए भी यह एक मज़ेदार tradition बन गया है
    wastl और helper elves ने इसे बनाया, यह फिर से कमाल लगता है
    जिन्हें इससे value मिलती है, वे अगर संभव हो तो support करें
    यह passion project है, लेकिन असल cost लगती है, यह भी सच है

    • sponsors और AoC++ users इतने ज़्यादा हैं कि इसे VPS की monthly subscription भरने में मुश्किल वाले छोटे passion project की तरह देखना मुश्किल लगता है
      फिर भी adventofcode सच में शानदार है, और अगर संभव हो तो support करना अच्छा है
      हालांकि अभी मिल रहे support के पैमाने को देखते हुए लगता है creator काफी ठीक-ठाक चल रहे होंगे

  • इस साल F# और Gleam से करने की कोशिश करूंगा, लेकिन हर साल की तरह शायद 10–12 दिनों से ज़्यादा का समय और दिमाग नहीं होगा
    जो लोग Python इस्तेमाल करते हैं, उन्हें F# भी एक बार आज़माना चाहिए
    यह scripting के काफी करीब महसूस हो सकता है, और इसमें शानदार REPL भी है

    • AoC को Whitespace में हल करने की tradition जारी रखे हुए हूं [0]
      पहले साल इसे बहुत boring न होने देने के लिए standard library बनाने की motivation मिली
      अब लगता है कि बेहतर tools पहले ही खत्म कर दिए होते तो अच्छा रहता
      jq में लिखे gdb जैसे CLI debugger wsjq[1] से debugging करता हूं, लेकिन यह slow है
      [0]: https://github.com/thaliaarchi/ws-challenges
      [1]: https://github.com/thaliaarchi/wsjq
    • bash में कर रहा हूं, और देखना चाहता हूं कितनी दूर तक जा सकता हूं
    • पिछले दो AoC F# में किए थे, हालांकि सच कहूं तो बस शुरुआती कुछ दिन ही किए
      functional programming का experience न रखने वाले व्यक्ति के लिए भी मज़ेदार था
      इस साल participate करने का समय नहीं है, लेकिन अगर करता तो शायद फिर F# ही चुनता
    • मैंने भी F# सीखना शुरू किया है और इस साल AoC में इस्तेमाल कर रहा हूं
      अभी functional journey की शुरुआत में हूं, लेकिन अब तक लगता है कि AoC मददगार रहा है
    • Linux support कैसा है, यह जानने की उत्सुकता है :)

  • पिछले साल Day 12 पर पूरे एक हफ्ते तक अटका रहा, और हल निकालने के बारे में सोचते-सोचते जागते हुए हर पल उसी में चला गया
    इस साल खुद पर थोड़ा नरम रहकर participate नहीं कर रहा, और winter vacation को ठीक से enjoy करना चाहता हूं

    • कई साल लगातार इसने जिंदगी खा ली, और दो बार तो Christmas Eve पर बड़ी मुश्किल से खत्म किया
      अब तो इसे देखता ही नहीं। मज़ा काफी जल्दी stress में बदल जाता है
    • समझदारी लगती है
      boundaries तय करना और आराम के समय का आनंद लेना जरूरी है
      मेरे लिए Advent of Code एक slippery slope जैसा है
      difficulty बढ़ने पर पहले आसान लगता है, फिर rewarding तरीके से मुश्किल, लेकिन कब बहुत ज्यादा समय लगने लगता है पता नहीं चलता
      तब तक आप emotionally invested हो चुके होते हैं, यही risk है
    • एक दोस्त ने हाल ही में यह share किया था, शायद तुम्हें पसंद आए
      https://eli.li/december-adventure
    • graph cut puzzle पर चार महीने तक अटका रहा
      काटी जाने वाली सबसे लंबी तीन edges खोजने के लिए force-based graph engine तक लिखना पड़ा
      हल करने के बाद दूसरों के solutions देखे तो उन्होंने Meta के theorem prover का इस्तेमाल करके करीब 10 lines में खत्म कर दिया था
      मुझे वह बहुत बड़ा shortcut लगा

  • AoC पसंद है
    AI bot हल कर रहा है या कोई और पहले उठता है, इसकी चिंता करने की जरूरत नहीं; बस अपने मज़े के लिए हल करो
    चाहे challenge खुद पसंद हो, या कोई नई language आज़मानी हो, फर्क नहीं पड़ता
    मुझे work से अलग करने के लिए जितना हो सके Kotlin functional style में हल करना पसंद है
    आज का solution भी डाल दिया है। utilities इस्तेमाल करता हूं इसलिए pure Kotlin नहीं है, लेकिन बढ़िया functions जमा करके एक तरह की library बनाना भी मज़े का हिस्सा है
    https://github.com/Matsemann/algorithm-problems/blob/main/ad...

    • transpose function पसंद आया
      पिछले कुछ साल Python NumPy इस्तेमाल किया, और इस साल Kotlin इस्तेमाल कर रहा हूं; पहले दिन के problem में transpose function की सबसे ज्यादा कमी महसूस हुई
      मेरा code यहां है: https://github.com/charelF/AdventOfCode/blob/main/kt/src/y20...