1 पॉइंट द्वारा GN⁺ 4 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • सपोर्ट बंद हो चुके लगभग 24 Java 1.0 गणित applets को आधुनिक AI coding agents की मदद से JavaScript में port किया गया, और वे visualization tools भी पूरे किए गए जिन्हें पहले लागू नहीं किया जा सका था
  • मौजूदा applets कुछ ही घंटों में restore हो गए; Besicovitch set में रंगीन display जैसी graphics improvements और 1999 में Allen Knutson के साथ बनाए गए honeycomb applet का reimplementation भी हुआ
  • porting के दौरान agent द्वारा बनाया गया bug drag handling से जुड़ी 1 छोटी समस्या थी; उल्टा, उसने मौजूदा code में 2 अनपहचाने bugs खोजे, जिससे कुल code quality लगभग समान स्तर पर बनी रही
  • जटिलता के कारण 1999 में छोड़े गए “Minkowski space का Inkscape” विचार को कुछ घंटों की vibe coding से special relativity visualization app के alpha version के रूप में लागू किया गया, और Gilbreath conjecture visualization भी नया बनाया गया
  • गणितीय argument का core हिस्सा न होने वाली auxiliary visualizations में LLM-generated code के bugs का जोखिम अपेक्षाकृत कम है, इसलिए इन्हें भविष्य के papers में interactive supplementary material के रूप में इस्तेमाल किया जा सकता है

Java 1.0 applets की शुरुआत और बंद होना

  • 1999 से मशीनों की मदद से गणित पर शोध करने और पढ़ाने के तरीकों में रुचि रही, और complex analysis तथा linear algebra lectures के लिए कई applets Java 1.0 में विकसित किए गए
  • lectures के अलावा honeycomb और Besicovitch set समेत कई गणितीय objects को visualize करने के लिए भी applets का इस्तेमाल किया गया
  • कुछ हद तक सफलता मिली, लेकिन खुद programming करने में बहुत समय लगता था, और web standards ने उस Java version को support करना बंद कर दिया, जिससे applets चलना बंद हो गए

AI का इस्तेमाल कर JavaScript में porting

  • मौजूदा webpages और blog data को आसानी से maintain होने वाले repository में ले जाते समय आधुनिक AI assistance का उपयोग किया गया
  • प्रयोग के तौर पर agent से मौजूदा applets को किसी currently supported language में port करने को कहा गया, और अंततः JavaScript चुना गया
  • लगभग 24 मौजूदा applets कुछ ही घंटों में फिर से काम करने लगे, और कुछ graphics भी सुधरे
    • Besicovitch set applet पुराने monochrome display से color display में बदल गया
    • 1999 में Allen Knutson के साथ बनाया गया और manual implementation में खास तौर पर कठिन honeycomb applet भी restore हुआ

नए bugs और मौजूदा code की errors की खोज

  • LLM-based coding agents स्पष्ट या सूक्ष्म bugs बना सकते हैं, लेकिन इस porting में नई मिली समस्या सिर्फ 1 छोटी bug थी
    • एक complex analysis applet में main area के बाहर drag करने पर अनचाहा behavior दिखा
  • इसके विपरीत, agent ने मौजूदा code में छिपे 2 अनपहचाने bugs खोज निकाले; इन्हें साथ में देखें तो कुल code quality लगभग समान स्तर की रही
  • ये applets गणितीय argument के core components नहीं, बल्कि auxiliary visual materials हैं, इसलिए bug होने पर भी उससे जुड़ा जोखिम अपेक्षाकृत कम है

1999 में छोड़ा गया special relativity tool

  • मौजूदा apps की porting बिना अधिक कठिनाई के आगे बढ़ी, तो नए apps बनाना भी आजमाया गया
  • 1999 में special relativity visualization tool के रूप में “Minkowski space का Inkscape” जैसा विचार बनाया गया था, लेकिन उस समय Inkscape भी release नहीं हुआ था
  • Java code लिखना शुरू किया गया, लेकिन complexity संभालना मुश्किल होने से project छोड़ दिया गया
  • AI agent के साथ कुछ घंटों की vibe coding के बाद उस समय की कल्पना से मेल खाता spacetime diagram applet implement किया गया
  • निर्माण-वार्ता का सारांश भी公開 किया गया, और repetitive technical implementation reports को editing के दौरान काफी हद तक हटाया गया
  • मौजूदा app कुछ play testing से गुजरा alpha version है; LLM-generated code की प्रकृति के कारण unresolved bugs और rough edges बचे हो सकते हैं, इसलिए और feedback की जरूरत है

Gilbreath conjecture visualization

  • Gilbreath conjecture paper पर blog post लिखने के बाद, paper और post के साथ जोड़ने के लिए visualization tool भी agent से मांगा गया
  • कुछ घंटों की बातचीत के बाद Gilbreath conjecture visualization पूरा हुआ
  • निर्माण-प्रक्रिया की conversation log भी साथ में प्रकाशित की गई, और development बिना बड़ी कठिनाई के आगे बढ़ा

papers के interactive supplementary material के रूप में उपयोग

  • भविष्य के papers में interactive visualizations को supplementary material के रूप में जोड़ने पर विचार किया जा रहा है
  • ऐसी visualizations paper के core हिस्से के लिए अनिवार्य नहीं होतीं, इसलिए LLM agents के साथ guided interaction से generate होने पर भी errors से जुड़ा जोखिम स्वीकार करने लायक स्तर पर है

1 टिप्पणियां

 
GN⁺ 4 시간 전
Hacker News की रायें
  • LLM से visualization सामग्री बनाते हुए कंप्यूटर साइंस की क्लासें काफी बेहतर हुईं: https://htmx.org/essays/universities-and-ai/#demos-visualiza...
    जिन सामग्रियों की हमेशा इच्छा थी लेकिन समय न होने से बना नहीं पाते थे, वे अब उपलब्ध हो गई हैं, और Claude की मदद से मौजूदा 16-bit educational computer को पूरक करने वाला एक सरल 8-bit computer भी कुछ ही दिनों में design कर लिया: https://bdp.cs.montana.edu/

    • जिन अतिरिक्त features को हमेशा चाहते थे लेकिन समय नहीं था, उन्हें implement करना LLM का शानदार use case है. खासकर visualization code में perfect structure या maintainability जरूरी नहीं होती; बस सही visual result देना होता है, और LLM मनचाहा रूप आने तक बार-बार सुधार करने में माहिर है
    • गणित के papers पढ़ते समय LLM से visualizations बनवा रहा/रही हूँ. “इस लेख के हर हिस्से को 3Blue1Brown वीडियो की style में manim का उपयोग करके visualize करो” कहने पर प्रभावशाली नतीजे मिलते हैं
      इससे सामग्री को जल्दी समझने और पहले से ज्यादा papers पढ़ने में मदद मिली है
    • LLM से PIL commands और parameters लिखवाकर और बदलवाकर कई-कई घंटे बचाए
    • grading weight बदलने वाली post देखें तो https://acbart.github.io/2026/04/19/proctored-grades/ करीब 50-50 वितरण जैसा दिखता है. तो क्या इसका मतलब है कि हर quiz में 40% पाने वाला student भी C- के साथ course पास कर सकता है?
    • microcontroller class में instructor ने blackboard पर 8-bit computer के registers, memory और instructions खुद बनाकर समझाए थे, और अंदरूनी working को समझने में बहुत मजा आया
      लगा था कि पढ़ाई गई चीजों को ज्यादा simulate कर पाना अच्छा होगा. शिक्षा में किसी चीज को components में तोड़कर उनके interactions देखे जाते हैं, इसलिए vibe-coded simulations बेहतरीन tool बन सकते हैं
  • अगर Terry Tao coding agent से app बनाते हैं, तो अब Fields Medal विजेता भी हमारी तरह LLM से Docker container start क्यों नहीं हो रहा पूछने से बस एक कदम दूर हैं

    • LLM से पहले भी professional software बनाने वाले Fields Medal विजेता Martin Hairer थे: https://en.wikipedia.org/wiki/Martin_Hairer, https://www.hairersoft.com/
    • सोचा था AI सबको सबसे ऊँचे स्तर तक उठा देगा, लेकिन उल्टा इसने top लोगों को हमारी पहुँच के स्तर तक नीचे ला दिया
    • इसके उलट, उस दिन का इंतजार है जब coding agent Terry Tao से पूछेगा कि जिस proof पर वह काम करना चाहता है, वह Fields Medal के लायक है या नहीं
  • खासकर पारंपरिक software क्षेत्र के बाहर संभावित software demand लगभग अनंत है. LLM की प्रगति आज रुक भी जाए, तो नई बनी software लिखने की क्षमता का पूरा उपयोग करने में 10 साल लगेंगे, और यह example इसे अच्छी तरह दिखाता है

  • “LLM से बने interactive supplementary materials paper के core के लिए essential नहीं हैं, इसलिए agent के साथ guided interaction से ऐसे visualizations बनाने का जोखिम उठाया जा सकता है” — यह निष्कर्ष balanced है
    LLM एक tool है, इसलिए कुछ कामों के लिए सही है और कुछ के लिए नहीं; आम तौर पर उसके results पर ज्यों का त्यों भरोसा नहीं करना चाहिए

    • LLM agent के results हमेशा verify करने चाहिए, लेकिन AI का मानवीकरण न करने को कहते हुए trust जैसा मानवीकृत शब्द इस्तेमाल करना थोड़ा मजेदार है. models और execution tools बेहतर हो रहे हैं और effective workflows स्थापित हो रहे हैं, इसलिए AI पर trust तेजी से बढ़ रहा है
      hammer को कीलों के लिए भरोसे से इस्तेमाल करते हैं, screws के लिए नहीं; लेकिन इससे hammer को आम तौर पर अविश्वसनीय नहीं कहते. AI की मुश्किल यह है कि अभी हमें पता नहीं कि कौन-सी चीज कील है और कौन-सी screw
      सिर्फ भरोसा मत करो कहने के बजाय यह बताना ज्यादा उपयोगी है कि पहले से ज्यादा समय planning, iteration और review में लगाना चाहिए; skills, context और sub-agents के उपयोग के तरीके सीखने चाहिए; और पहले non-operational, low-risk projects में practice करनी चाहिए. अच्छे workflow और उपयुक्त uses को समझते हुए trust बनाना लक्ष्य होना चाहिए
    • इस context में trust का मतलब क्या है, समझ नहीं आता. Donald Knuth को hire करके सारा code लिखवाएँ तब भी यह भरोसा नहीं करूँगा कि उसमें bugs नहीं होंगे या वह मेरी जरूरतों के लिए सही होगा
    • AI optimists में कई लोग Tao के mathematical proof में LLM का इस्तेमाल करने वाले बयान को आधार बनाकर strongly मानते हैं कि systems पहले ही बहुत advanced हैं और autonomously operate करते हैं
    • LLM maintain करने में मुश्किल और भरोसे लायक नहीं होने वाला भयानक code बनाते हैं. personal toy जैसे low-risk projects को vibe coding से बनाना ठीक है, लेकिन high-risk code के लिए यह स्पष्ट रूप से suitable नहीं है
  • Terry Tao को coding agent इस्तेमाल करते देखना ऐसा लगता है जैसे Michelin-star chef ने microwave instant food खोज लिया हो और सच में उत्साहित हो गया हो

    • पुराने cookbooks को देखते हुए, अगर microwave cooking को गंभीरता से आगे बढ़ाया गया होता तो कैसा होता—इस पर लिखा यह लेख दिलचस्प लगा: https://malmesbury.substack.com/p/my-journey-to-the-microwav...
    • Michelin-star chefs भी असल में microwave को काफी महत्व देते हैं। Marco Pierre White ने microwave को “कमाल की चीज़” कहा और कहा कि herring पकाने में यह उबालने या grill करने से बेहतर है: https://www.independent.co.uk/life-style/marco-pierre-white-...
      José Andrés ने भी microwave omelet को सबसे कम fail होने वाली dish बताया और इसे “मानव इतिहास का सबसे शानदार फूला हुआ omelet” कहा: https://www.tasteofhome.com/article/jose-andres-microwave-om...
    • ज्यादा सटीक उपमा यह है कि Charles और Henry Greene, Gamble House में रखे जाने वाले नाजुक jewelry box के joints को fix करने के लिए तकनीक से एक बारीक custom jig बना रहे हों। हाथ से भी बनाया जा सकता है, लेकिन जिन लोगों को बहुत कुछ बनाना है उनके लिए समय कीमती होता है
      Tao जैसे उस्ताद दिखाते हैं कि तकनीक वह jig बना सकती है, और machine makers धीरे-धीरे साबित कर रहे हैं कि वे सिर्फ jewelry box के लिए jig ही नहीं, बल्कि jig बनाने वाली machine बनाने के jig भी बना सकते हैं
    • सोचता हूँ कि शुरुआती microwave instant foods पर उस समय के महान chefs ने कुछ लिखा था या कोई प्रतिक्रिया दी थी क्या
    • जब microwave पहली बार आया होगा, तो chefs भी सचमुच रोमांचित हुए होंगे। कम से कम पहली बार देखने पर यह लगभग जादू जैसा लगता है
  • गणित और physics के पुराने educational Java applets चलाना लंबे समय से CheerpJ Applet Runner का लोकप्रिय use case रहा है, जो WebAssembly के जरिए browser में Java bytecode चलाता है
    जब agents इसे ठीक से modernize करके इस समस्या को हल कर रहे हैं, तो इसे कैसे लिया जाए—यह थोड़ा जटिल है। छात्रों का content के साथ modern और accessible तरीके से interact कर पाना निश्चित रूप से अच्छा है, लेकिन भले ही यह commercially महत्वपूर्ण न हो, education में इसका उपयोग हमेशा गर्व का स्रोत रहा है: https://chromewebstore.google.com/detail/cheerpj-applet-runn...

  • किसी domain expert का AI से अपने क्षेत्र की कोई चीज़ मजेदार तरीके से बनाना पढ़ना हमेशा अच्छा लगता है, लेकिन यह हमेशा hobby project ही लगता है, serious काम नहीं

    • Terry Tao उन प्रमुख mathematicians में से हैं जो cutting-edge mathematical discovery में AI के इस्तेमाल की संभावनाएं explore करते रहे हैं। यह लेख हल्का है, लेकिन उन्होंने core research में AI assistance पर भी काफी लिखा है
      https://terrytao.wordpress.com/tag/artificial-intelligence/, https://academy.openai.com/public/blogs/terence-tao-ai-is-re...
    • university professor के लिए educational material development काम का हिस्सा है, तो समझ नहीं आता कि इसे hobby project क्यों माना जा रहा है
    • काम में Claude Code इस्तेमाल करना शुरू करने के बाद, लगता है कि ज्यादा से ज्यादा 5 साल में coding अपने मौजूदा रूप में career के तौर पर खत्म हो जाने की संभावना काफी ज्यादा है
      मैं उम्रदराज़ हूँ और जरूरत पड़े तो कल ही तंग budget में retire हो सकता हूँ, लेकिन मेरे 25 साल के भांजे जैसे young developers की चिंता होती है, जिन्होंने अभी इतना asset नहीं बनाया कि काम किए बिना चल सके। सीधे code लिखना वैसा ही specialist domain बन जाएगा जिसे बहुत कम लोग करेंगे, जैसे हाथ से square root निकालना या type casting करना
    • “हमेशा” और “कभी नहीं” बहुत ज्यादा strong expressions हैं। मुझे लगता है अगले साल इसी समय तक हमें AI का काफी serious use देखने को मिलेगा, और फिर ऐसा कहना मुश्किल होगा
      AI coding का व्यापक उपयोग अभी शुरू ही हुआ है, और models भी हाल में ही serious work लायक स्तर पर पहुंचे हैं। मैंने असली use cases देखे हैं, लेकिन organization policies, private code और trade secrets की वजह से personal blog पर production code में use publicly बताना मुश्किल होने के कई कारण हैं
    • Tao AI का इस्तेमाल formal verification mathematics और mathematical problem-solving ideas में भी कर रहे हैं। यह कहना कि supplementary material है इसलिए ठीक है, शायद इसका मतलब है कि वह visualization formally verified नहीं है और उसमें bugs हो सकते हैं; और चूंकि यह paper का core नहीं है, इसलिए AI को अलग से contributor के रूप में mention करने की जरूरत नहीं है
  • “code complexity इतनी बढ़ गई कि संभाली नहीं जा सकी और project छोड़ दिया” वाला हिस्सा पढ़कर हंसी आई। Terry Tao तक के लिए भी इतना complex code होता है कि वे लिख नहीं पाते
    मुझे बड़ी उम्मीद है कि LLMs बहुत से ऐसे लोगों को software development में शामिल कर देंगे जो अपने-अपने fields में बेहद smart हैं, लेकिन coding में entry नहीं कर पाए थे

  • Claude से 30 साल पुराने high school German Java applet game को JavaScript में port किया, और fake Git history भी बनाई: https://github.com/bradfitz/koffer#der-verloren-koffe
    इसे online भी चलाया जा सकता है: https://bradfitz.github.io/koffer/js/
    करीब 30 साल पुराना code फिर से चलते हुए देखना शानदार है

  • लेख का awkward पहला sentence ही इस बात का सबूत है कि इसे AI ने नहीं लिखा। वह sentence है: “1999 में Java 1.0 से complex analysis और linear algebra classes के लिए applets बनाते हुए honeycomb structures या Besicovitch sets जैसे mathematical objects को visualize करने के समय से ही, मुझे machines की मदद से mathematics को research और teach करने के तरीकों में रुचि रही है”

    • यह बहुत Terence Tao जैसा writing style है। जिन वाक्यों को छोटा-छोटा बांटा जा सकता है, उन्हें लंबा जोड़कर लिखते हैं, लेकिन पढ़ने-समझने पर खास असर नहीं पड़ता
    • ऐसा style Claude द्वारा smooth तरीके से फिर से लिखे गए फीके output से हमेशा बेहतर है