Julia: جيف بيزانسون دكتوراه

ccfperez الذي يهتم أيضًا بهذه المشكلة المعلقة

المعلومات الداعمة المرفقة.

كمسألة إجرائية ، قد يتطلب إغلاق هذا العمل في مستودع منفصل. ربما ينبغي تضمين الأطروحة في Base لتسهيل مشاركة الآخرين.

كما أن ترتيب المهمة الأخيرة أمر مضلل ؛ سوف يتكرر بالفعل بشكل متكرر خلال العملية.

+1 لتضمينه في Base ، أو على الأقل في julia/doc/thesis . أو ربما theses للسماح بالاحتياجات المستقبلية.

(يرجى المضي قدمًا وفتح فرع أطروحة يا جيف.)

كما أن ترتيب المهمة الأخيرة أمر مضلل ؛ سوف يتكرر بالفعل بشكل متكرر خلال العملية.

* تكرر أيضًا بالفعل

إنني أتطلع إلى أن أكون حاضرًا في حفل _ إغلاق المشكلة_.

لا يمكنني إعادة إنتاج هذه المشكلة محليًا ؛ هل هي خاصة بمعهد ماساتشوستس للتكنولوجيا؟

أصبح أحد مؤلفي جوليا الأساسيين ، JeffBezanson ، أكاديمي مطور إشكالي

هل هذه نسخة جيثب من أطروحة دكتوراه؟ يتعين على جيف فتح العلاقات العامة مع اقتراحه وستقرر اللجنة ما إذا كانت ستدمج أم لا ...

+ Inf للحصول على حل سريع لهذا واحد!

واجهت نفس المشكلة في IPython repo قبل بضعة أشهر ، وآمل أن يتم إصلاحها قبل 32 يومًا.
أنا متأكد من أنها تضمنت القهوة وأعمالًا ورقية مزعجة وتغييرًا في الخطة في اللحظة الأخيرة بسبب آلات ثقب الصخور.

حظ سعيد !

محدث: التقى جيف بلجنة أطروحته وقدم لنا مخططًا تقريبيًا.

سعيد لسماع أنه يتم إحراز تقدم!

لكن git log --date=short --all --since=22.days.ago --author="Jeff Bezanson" لا يزال يجعل المرء يتساءل كيف لديه الوقت لكتابة أطروحة. إما ذلك ، أو أنه بطل خارق. في الواقع ، اخدش ذلك: نحن نعلم جميعًا أنه بطل خارق ، لذا لا تهتم.

تسجل الالتزامات التي تتضمن juliatypes.jl محاولاتنا لوصف نظام جوليا للطباعة ، وهو عمل أطروحة ذو صلة مباشرة.

يبدو أن عمل نظام الكتابة يضرب بالفعل بعض الأعصاب: https://twitter.com/plt_hulk/status/535045242920378369

أشك نوعًا ما في أن هذا رد مباشر على عمل جيف ، على الرغم من أنني قد أكون مخطئًا. تغريدة مرحة في كلتا الحالتين.

jiahao ، كان تعليقي في الغالب لسان الخد --- تساءلت كيندا عن هذا الشيء بالذات. أنا ، على سبيل المثال ، أميل إلى الكثير من الالتزامات عندما أقوم بصقل شيء ما للعرض التقديمي.

timholy النكتة لاحظت. :)

سيكون من الخطأ عدم ذكر ماغريت اللطيفة تحية لمتعاون النظرية المحلي jeanqasaur الذي قدمه ونشره على تويتر :

"خيانة الأنواع" لها خاتم جميل ، أليس كذلك؟

هذا مضحك جدا.

أحبها!

طلب المساعدة: يبحث Jeff عن أمثلة لطيفة تُظهر إرسال متعدد (وربما وظائف مرحلية) ، أشياء قد تكون أصعب / أبطأ بكثير في اللغات التي لا تحتوي على هذه الميزات.

هو ، show ؟

(وربما وظائف مرحلية)

يجب أن تخدم subarray.jl و subarray2.jl بشكل جيد إلى حد ما. وثيقة التصميم موجودة في http://docs.julialang.org/en/latest/devdocs/subarrays/

أعتقد أن حزمة التوزيعات تجعل الإرسال المتعدد مفيدًا حقًا. الحصول على أشياء مثل rand(Gamma(1, 1), 5, 5) مقابل rand(Normal(0, 1), 3) هو مكسب كبير في التعبير بدون تكلفة أداء بسبب الإرسال المتعدد.

لا أرى كيف أن هذا هو أفضل مثال لأنه حقًا يتباهى
إيفاد واحد. كيف يختلف عن Gamma(1,1).rand(5,5) الذي أنت
في لغة OO أكثر تقليدية مثل Python أو Java؟

يوم الجمعة ، 19 كانون الأول (ديسمبر) 2014 ، الساعة 1:39 مساءً ، John Myles White [email protected]
كتب:

أعتقد أن حزمة التوزيعات تجعل الإرسال المتعدد يبدو حقًا
مفيد. وجود أشياء مثل راند (جاما (1 ، 1) ، 5 ، 5) مقابل راند (عادي (0 ، 1) ،
3) هو مكسب كبير في التعبير دون تكلفة الأداء بسبب
إيفاد متعدد.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/JuliaLang/julia/issues/8839#issuecomment -67678367.

نعم. استبدل ذلك بأمثلة لحساب اختلافات KL باستخدام النتائج التحليلية: kl(Normal(0, 1), Normal(0, 1)) مقابل kl(Normal(0, 1), Gamma(1, 1)) .

كان يجب أن أضيف أيضًا ، كانت هناك بعض الإحصائيات التي يحتمل أن تكون مفيدة حول شكل الحياة _ بدون _ وظائف مرحلية في رسالتي الأولية في # 8235. رسالة الاستلام إلى المنزل: أدى إنشاء جميع الطرق من خلال البعد 8 إلى> 5000 طريقة منفصلة ، وتطلب أكثر من 4 دقائق من التحليل وخفض الوقت (على سبيل المثال ، تأخير لمدة 4 دقائق أثناء تجميع جوليا). بالمقارنة ، يتم تحميل تنفيذ الوظيفة المرحلية في لمح البصر ، وبالطبع يمكن أن يتجاوز 8 أبعاد.

مقابل الإرسال الفردي ، فإنه لا يزال يوضح توحيد ما تصفه لغات OO الأخرى على النحو التالي: الوظائف مقابل الطرق. يمكنك التقيد بفرز Python (a) مقابل a.sort (). بالمقارنة مع لغات OO "التقليدية" ، فإنها تغير بشكل كبير معنى أن تكون الوظيفة "مرتبطة" بفصل.

يمكنك الإشارة إلى كيفية استبداله بالحاجة إلى متغيرات الحالة الثابتة مقابل متغيرات الحالة ، حيث يمكنك الإرسال على المثيل أو النوع. قد يكون لدي المزيد من الأفكار من بعض محادثات IRC الأخيرة ، عندما يمكنني الوصول إلى جهاز كمبيوتر.

لدي تطبيق fmap . هذا يجتاز عدة مصفوفات و
يطبق دالة على كل مجموعة من العناصر. هذا التنفيذ هو في الواقع
بطيء جدًا نظرًا لأن عدد المصفوفات يمكن أن يكون عشوائيًا. لجعل هذا مفيدًا ،
لقد أنشأت تخصصًا يدويًا في هذا لأعداد مختلفة من
الوسائط yss . كنت أرغب دائمًا في كتابة دالة مرحلية لهذا ،
لكن لم تفعل ذلك بعد.

ستحتاج الوظيفة المرحلية إلى تقييم المكالمة map على وجه الخصوص
التي تنتج الوسيطات لـ f .

-ريك

function fmap{T,D}(f::Function, xs::Array{T,D}, yss::Array...;
                   R::Type=eltype(f))
    [<strong i="18">@assert</strong> size(ys) == size(xs) for ys in yss]
    rs = similar(xs, R)
    <strong i="19">@simd</strong> for i in 1:length(xs)
        <strong i="20">@inbounds</strong> rs[i] = f(xs[i], map(ys->ys[i], yss)...)
    end
    rs::Array{R,D}
end

يوم الجمعة ، 19 كانون الأول (ديسمبر) 2014 الساعة 12:46 مساءً ، ستيفن ج. جونسون <
[email protected]> كتب:

طلب المساعدة: يبحث Jeff عن أمثلة لطيفة تُظهر العديد من الأمثلة
إيفاد (وربما وظائف مرحلية) ، أشياء ستكون كثيرة
أصعب / أبطأ في اللغات التي لا تحتوي على هذه الميزات.

قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/JuliaLang/julia/issues/8839#issuecomment -67671331.

إريك شنيتر [email protected]
http://www.perimeterinstitute.ca/personal/eschnetter/

عذرا ، تجاهل استدعاء eltype(f) في توقيع الوظيفة في الكود الخاص بي ،
هذا غير قياسي.

-ريك

يوم الجمعة ، 19 كانون الأول (ديسمبر) 2014 الساعة 3:08 مساءً ، Erik Schnetter [email protected]
كتب:

لدي تطبيق fmap . هذا يجتاز عدة مصفوفات و
يطبق دالة على كل مجموعة من العناصر. هذا التنفيذ هو في الواقع
بطيء جدًا نظرًا لأن عدد المصفوفات يمكن أن يكون عشوائيًا. لجعل هذا مفيدًا ،
لقد أنشأت تخصصًا يدويًا في هذا لأعداد مختلفة من
الوسائط yss . كنت أرغب دائمًا في كتابة دالة مرحلية لهذا ،
لكن لم تفعل ذلك بعد.

ستحتاج الوظيفة المرحلية إلى تقييم استدعاء map على وجه الخصوص
التي تنتج الوسيطات لـ f .

-ريك

function fmap{T,D}(f::Function, xs::Array{T,D}, yss::Array...;
                   R::Type=eltype(f))
    [<strong i="26">@assert</strong> size(ys) == size(xs) for ys in yss]
    rs = similar(xs, R)
    <strong i="27">@simd</strong> for i in 1:length(xs)
        <strong i="28">@inbounds</strong> rs[i] = f(xs[i], map(ys->ys[i], yss)...)
    end
    rs::Array{R,D}
end

يوم الجمعة ، 19 كانون الأول (ديسمبر) 2014 الساعة 12:46 مساءً ، ستيفن ج. جونسون <
[email protected]> كتب:

طلب المساعدة: يبحث Jeff عن أمثلة لطيفة تُظهر العديد من الأمثلة
إيفاد (وربما وظائف مرحلية) ، أشياء ستكون كثيرة
أصعب / أبطأ في اللغات التي لا تحتوي على هذه الميزات.

قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/JuliaLang/julia/issues/8839#issuecomment -67671331.

إريك شنيتر [email protected]
http://www.perimeterinstitute.ca/personal/eschnetter/

إريك شنيتر [email protected]
http://www.perimeterinstitute.ca/personal/eschnetter/

timholy ، بما أن Matlab و NumPy لديهما مصفوفات فرعية / شرائح أيضًا ، فلماذا يمكننا القول بأن الإرسال المتعدد ضروري هنا؟

سهولة التنفيذ؟ بقدر ما أستطيع أن أقول أنه يمكنك محاكاة إرسال متعدد بأي لغة ، لذلك فهو ليس ضروريًا لأي شيء.

ربما ليس من الجيد اقتراح شيء لم نقرر بعد أننا نريده. في https://github.com/JuliaLang/julia/issues/9297 ، هناك اقتراح يسمح لنا بالحصول على مواضع UTF-8 العازلة الفعالة وفهرسة مريحة بدون ثقوب حتى تتمكن من إجراء عمليات حسابية مريحة عندما تريد ذلك. سيعيد Regex والبحث الفهرس الداخلي المغلف ، لكن s[2] يمكن أن يعطي الحرف الثاني بغض النظر عن عدد البايتات التي تم استخدامها لتشفير الأول.

هل يمكنهم صنع مصفوفات فرعية / شرائح فعالة AbstractArrays ، أم أن تنفيذها يعمل فقط مع كتل متجاورة من الذاكرة؟ هذه ليست مشكلة صعبة للغاية لحلها إذا كان بإمكانك افتراض أن المصفوفة الأم بها ذاكرة متجاورة ؛ يصبح الأمر أكثر تشويقًا عندما لا تقوم بهذا الافتراض.

نعم ، هذه هي الميزة الرئيسية التي نبحث عنها: ليس فقط أن شيئًا ما يمكن القيام به بشكل جيد مع وظائف متعددة الإرسال و / أو مرحلية ، ولكن الافتقار إلى هذه الميزات بلغات أخرى جعل تنفيذ الميزة أكثر صعوبة (من الناحية المثالية ، كثيرًا أصعب من أن أحداً لم يحاول ذلك).

timholy ، تتميز مصفوفة NumPy بخطوة ثابتة لكل بُعد ، وليس بالضرورة التقارب (يعادل بشكل أساسي DenseArray ). يتم الاحتفاظ بهذه الخاصية تحت التقطيع ، لذلك يمكن تقطيع الشرائح نفسها إلى شرائح إلى آخره.

كان لدى aberrant بعض الأسئلة الجيدة على IRC على هذا المنوال. لقد حاولت استخراج أجزاء التعليقات ذات الصلة فقط (من بين المحادثات والإشعارات غير ذات الصلة) أدناه:

2014-12-10 (EST)
11:41 aberrant: “Organizing methods into function objects rather than having named bags of methods “inside” each object ends up being a highly beneficial aspect of the language design.”
11:41 aberrant: why?
12:20 Travisty: aberrant: I can’t speak for them, but I imagine that the argument is that it’s a nice separation of concerns. I have data (which I will represent with types) and routines for operating on that data (which I will represent as functions), and rather than having some routines belong to specific types, they are kept separate
12:21 aberrant: Travisty: I sort of understand the argument, but I’m not sure I agree with it :)
12:22 Travisty: aberrant: Yeah, sure. This is the sort of thing that may be hard to argue about from first principles, and it may be useful to look at examples. I think one place where this design simplified things was in impementing the standard mathematical functions on all of the numeric types, and dealing with conversion
12:22 Travisty: I’m not sure, but I think the solution in julia is quite elegant because of this design and it would be a bit trickier to do it in the traditional OOP setting
12:23 aberrant: Travisty: perhaps. I need to think about it some more. I really like pure OO, and this is a bit of a change that I need to wrap my head around.
...
12:54 vtjnash: julia has a convention that a method name will end in a ! to signify that the method will mutate one of it's arguments
12:56 aberrant: that’s one thing I sorely miss in python. foo.sort() vs foo.sorted() always confused me.
12:57 vtjnash: except that in python, isn't it sort(foo) vs sorted(foo) ?
12:57 aberrant: it might be :)
12:58 aberrant: no
12:58 aberrant: it’s foo.sort vs sorted(foo)
12:58 vtjnash: ah
12:58 aberrant: foo.sort modifies foo in place.
12:58 aberrant: see?
12:58 aberrant: that’s what I mean.
12:58 vtjnash: well, anyways, that's an unintentional example of why . oriented programming is a pain
12:58 aberrant: sort(foo) vs sort!(foo) makes much more sense.
12:59 vtjnash: python made a reasonable choice there
12:59 vtjnash: and tries to help you remember
12:59 vtjnash: but it still was forced to make some decision

2014-12-14 (EST)
15:25 aberrant: there’s no way to do type constants, I guess?
15:25 aberrant: http://dpaste.com/18AEHBG
15:25 aberrant: like that
15:27 vtjnash: no. that declares a local variable inside the type (can be seen by the constructors and other methods in there)
15:27 vtjnash: instead, define `y(::Foo) = 6`
15:28 aberrant: is that mutable?
15:29 aberrant: hm, yeah, that’s not what I want though.
15:29 aberrant: but I guess I can use it.
15:30 vtjnash: not what you want, or not what other languages do?
15:31 vtjnash: multiple dispatch in julia allows you to collapse 4 or 5 or more different constructs needed by other OO languages into one abstraction
15:33 aberrant: oh, I see how it works.
15:33 aberrant: well, it’s a function and therefore more overhead
15:33 aberrant: basically, I want to set the “bitwidth” of an IPv4 address to be 32, and the “bitwidth” of an IPv6 address to be 128, and then be able to write a function that takes ::IPAddr and uses the appropriate bitwidth.
15:34 aberrant: I can do this with the function, but it seems like overhead to have a function return a constant.
15:35 aberrant: e.g., http://dpaste.com/3RXRCAG
15:36 vtjnash: don't assume that a function has more overhead
15:36 vtjnash: in this case, it would actually have less overhead
15:54 aberrant: wow, ok
15:54 aberrant: I don’t see how, but I’ll take your word for it :)
15:59 vtjnash: inlining
...
18:04 aberrant: there’s no way to associate a constant inside a type?
18:04 aberrant: it would make my life a whole lot easier.
18:04 mlubin: aberrant: t.constant or constant(t) is just a syntax difference
18:04 mlubin: julia uses the latter
18:05 aberrant: mlubin: the issue is that you have to instantiate the type first.
18:05 aberrant: mlubin: I need the equivalent of a class property.
18:05 mlubin: constant(::Type{Int32}) = 10
18:05 mlubin: constant(Int32)
18:05 aberrant: oh. wow.
18:06 Travisty: The only member of Type{T} is T, which is why this works
18:06 mlubin: mind=blown? ;)
18:06 aberrant: yeah
18:06 aberrant: that’s jacked up
18:07 aberrant: there’s NO WAY I would have ever thought of that on my own :(
18:07 mlubin: once you see it for the first time it becomes a lot more intuitive
18:07 aberrant: ipaddrwidth(::Type{IPv4}) = uint8(32)
18:08 aberrant: w00t
18:10 aberrant: can I do a const in front of that?
18:11 Travisty: I don’t think so, but usually when julia generates code, it should be inlined so that just the constant uint8(32) appears, instead of a function call

إذا كنت تبحث عن مزيد من الأمثلة: https://github.com/JuliaLang/julia/pull/7291

تخفيض صافي الكود أمر رائع من 6K C ++ إلى حوالي 1K Julia. تظهر معايير الأداء الأولية أنها أقل بقليل من ضعف C ++ الأصلي.

كم عدد اللغات التي تعرفها والتي يمكن أن تدعي تنفيذ printf ، من عوامل التشغيل (+ - * / ، Int ، Float) إلى تنسيق الإخراج الرقمي ، في اللغة نفسها ، والمعيار ضمن هامش صغير من إصدارات libc؟ ربما C ++؟ لا تستطيع C حتى المطالبة بهذا (ليس لديها زيادة في التحميل على المشغل).

بايثون / ماتلاب / إلخ. قد يكون قادرًا على المطالبة بأجزاء من هذا ، ولكن هل حاولت استخدام مشغلي السلسلة في MATLAB؟

هذه مناقشة ممتعة للغاية وأود أن أضيف بعض النقاط:

• ما يبدو أنه لم تتم الإجابة عليه حقًا هو كيفية مقارنة جوليا بتعدد الأشكال في C ++ بسرعة. في C ++ يمكن للمرء أن يكون لديه تعدد أشكال ثابت من خلال القوالب أو تعدد الأشكال الديناميكي من خلال OO. لكن الأخير يتطلب جدولًا vtable ويكون دائمًا أبطأ قليلاً ، خاصةً عند استدعاء مثل هذه الأشياء في حلقة ضيقة. لهذا السبب لن يفرط المرء في تحميل مشغل الوصول إلى الصفيف لأن هذا لن يكون سريعًا. يستخدم Eigen على سبيل المثال تعدد الأشكال الثابت.
• في جوليا ، لا توجد وجهة بين وظيفة افتراضية وغير افتراضية وما زلنا لا نفرض عقوبات على الأداء. ما أفهمه هو أن ميزة hugh هي أن Julia يمكنها إنشاء رمز "سريع" وبالتالي لا يزال بإمكانها إنشاء رمز سريع حيث يعني وقت تشغيل C ++ أنه لا يمكن لأحد تعديل الرمز الذي تم إنشاؤه بعد الآن. بالإضافة إلى ذلك في جوليا يمكننا القيام بالتضمين في وقت التشغيل. لذلك لا توجد وظيفة استدعاء النفقات العامة. وفي جوليا ، لا يتعين علينا التفكير في كل هذا لأنه يتم تلقائيًا
• هناك شيء واحد ضخم (مرة أخرى) هو: الأدوية الجنيسة بدون النفقات العامة وبدون كل هذا الألم الذي تعاني منه C ++ (تبحث في أوقات الترجمة) هناك طرق مختلفة لكيفية تنفيذ الأدوية الجنيسة وتستخدم IMHO Julia نفس نموذج C # ، لذلك قد لا يكون هذا جديدًا تمامًا (لـ أطروحة جيف). لكن ما زلت أعتقد أن هذا يمكن أن يكون شيئًا للمناقشة في الأطروحة.

مدى صعوبة شرح مدى فعالية الإرسال المتعدد ، هو بحد ذاته مثير للاهتمام.

سعيد لأننا في نفس الصفحة الآن. نعم ، لا تعتمد المصفوفات الفرعية الجديدة الخاصة بنا على وجود خطوات كبيرة ، كما أنها لا تتطلب فهرسة خطية (على الرغم من إمكانية استخدامها ، وهي تعمل بشكل افتراضي إذا كانت فعالة). لذا فهم يعملون بكفاءة مع أي AbstractArray ويدعمون طرق العرض "non-strided" ( Vector{Int} indexes) أيضًا.

للتوضيح ، لقد قدمت المصفوفات الفرعية الجديدة لدينا في المقام الأول كمثال على الوظائف المرحلية ، وليس الإرسال المتعدد. ومع ذلك ، فإن المخطط الحالي سينهار في خطوة الإنشاء بدون إرسال متعدد: نطلق على طرق الإنشاء المختلفة تمامًا لكل من slice(::AbstractArray, ::UnitRange{Int}, ::Int, ::Vector{Int}) و slice(::AbstractArray, ::Int, ::UnitRange{Int}, ::UnitRange{Int}) ، إلخ. تحتاج إلى إرسال متعدد حتى يعمل النظام.

بدون وظائف منفصلة ، يجب على مُنشئ varargs مواجهة حقيقة أن تكرار المدخلات في مجموعة الفهارس ليس ثابتًا من النوع: لمعالجة الفهارس الفردية في حلقة ، يجب عليك تعيينها إلى متغير سلمي مسمى ، وهذا المتغير هو مضمون ألا يكون مكتوبًا جيدًا على الرغم من أن مجموعة الإدخال يمكن أن تكون كذلك. بالطبع ، الوظيفة المرحلية تفعل أكثر من ذلك بكثير: تقريبًا كل القرارات "الصعبة" - هل نتخلى عن هذا كبعد مقسم ، أو نحتفظ به ، وما هي العواقب على التمثيل الداخلي للكائن؟ --- يمكن إجراؤها في وقت الترجمة ، مما يقلل من مُنشئ وقت التشغيل إلى عملية تافهة بشكل ملحوظ. يحدث فقط أن تختلف العملية البسيطة الخاصة لكل مجموعة من أنواع المدخلات ، لذلك لاستغلال هذه التفاهات وتسريع البناء ، تحتاج إلى استدعاء طرق مختلفة مخصصة لكل مجموعة من أنواع الإدخال. هذا هو السبب في أنك بحاجة إلى وظائف مرحلية وإيفاد متعدد.

أنا شخصياً أشك في أنه سيكون من الممكن القيام بما قمنا به بدون الجمع بين الوظائف المرحلية والإرسال المتعدد ، ومن المحتمل أن تتمتع جوليا الآن بأكثر طرق عرض الصفيف مرونة وكفاءة من أي لغة. لكني لا أدعي أنني أجريت أي نوع من الدراسة الفعلية لهذه المشكلة.

هذا يجعلني أتساءل عما إذا كان ينبغي أن أكتب المصفوفات الفرعية الخاصة بنا للنشر - يبدو أن لدينا شيئًا جديدًا هنا.

StefanKarpinski : لنكن نقد الذات: ربما لم نكتبها بعد؟

timholy أرى في الواقع شيئين هنا ، الوظائف المرحلية (التي يجب أن أعترف بأنها ليست مفهومة تمامًا) وكيف تتناسب جوليا مع وظائف C ++ الافتراضية مقابل كون القوالب (C # و Java متشابهان هنا).

بالنسبة لمقارنة C ++ ، سيكون من المثير جدًا القيام بالتوقيتات وإثبات تجريبيًا على أنه يمكننا الوصول إلى تعدد الأشكال في وقت التجميع (وأنا متأكد من أننا نفعل ذلك)

شيء آخر أردت صياغته لبعض الوقت هو كيفية مقارنة جوليا بـ C ++ فيما يتعلق بمفاهيم C ++ (لايت). التصنيف الفرعي الذي لدينا هو جزء كبير من مفاهيم C ++.

هل يحتاج المرء حتى إلى كتابة مجموعة من كود C ++ وتشغيل التوقيتات للتحقق من ذلك؟

A = rand(3,5)
<strong i="6">@code_llvm</strong> slice(A, 2, :)
<strong i="7">@code_llvm</strong> slice(A, :, 2)

لا يوجد شيء في الأساس سوى عمليات التحميل والتخزين (أي الوصول إلى الذاكرة) هناك.

timholy أعتقد أن الأمر يستحق كتابة هذا. أعتقد (ولكن لم أتحقق من ذلك) أن العديد من الأنظمة التي تنفذ مصفوفات Nd لها تطبيقات متخصصة للأبعاد القليلة الأولى ، ثم تعود عمومًا إلى شيء بطيء بخلاف ذلك ، ولا ينبغي أن يكون هذا هو الحال بالنسبة للتنفيذ الجديد.

حالة أخرى ذات صلة هي كتابة مخزن Nd متناثر فعال (المصفوفات هي الحالة الخاصة الشائعة).

تيم ،

نعم حقًا إن النظر إلى كود التجميع الناتج هو أداة رائعة. ولكن ما زلت أعتقد أنه يجب مقارنة هذا في سياق أكبر ، حيث (في تنفيذ C ++) يجب أن تؤخذ الوظائف الافتراضية في الاعتبار.

تخميني هو أنه ليس multiple dispatch سريعًا جدًا ولكن يمكننا تضمينه في وقت التشغيل وبالتالي تحويل الوظيفة الافتراضية (التي هي وظائفنا العامة) إلى تعليمات فعالة بدون وظيفة استدعاء غير مباشر.

إذا كان هذا صحيحًا (من فضلك صححني إذا كنت مخطئًا JeffBezansonvtjnashstevengjtimholy ) فإن المضاعف في multiple dispatch ليس سبب تواجد جوليا بهذه السرعة ولكن هناك جانبًا أنيقًا يؤثر على إمكانية صياغة رمز معين أجمل (حيث يتم تقييد الإرسال الفردي)

ربما لا أفهم ، لكنني لست متأكدًا من التمييز الذي تقوم به. في Julia ، لا يبدو أن "inline" و "runtime" متلازمتان معًا ؛ يتم تنفيذ التضمين أثناء استدلال النوع ، أي في وقت الترجمة. يتم استخدام الإرسال المتعدد لتحديد الطريقة المناسبة للأنواع المستنتجة.

الالتباس هنا هو أن "وقت الترجمة" و "وقت تشغيل" C ++ لا يمكن مقارنتها مع Julia. يمكن أن يحدث Codegen أثناء "وقت التشغيل" ، لذا أعتقد أنه عندما أقوم بتضمين include("myscript.jl") يتم تنفيذ عملية الترميز. وحتى إذا لم تكن كلمة "runtime" هي الكلمة المناسبة لذلك من منظور C ++ فهي "وقت التشغيل".

والإرسال على أنواع مختلفة يشبه جدول vtable ولكنه أكثر عمومية ، أليس كذلك؟

هذا يجعلني أتساءل عما إذا كان ينبغي أن أكتب المصفوفات الفرعية الخاصة بنا للنشر - يبدو أن لدينا شيئًا جديدًا هنا.

إنه بعيد قليلاً عن الموضوعات القياسية ، ولكن قد تفكر في تقديمه إلى JSS. نحتاج المزيد من مقالات جوليا.

أحب أن يكتب تيم منشورًا في مدونة ليصف هذا العمل للبدء به ، حيث إنه سيجعل الكثير من الناس على دراية بالسرعة. JSS هي فكرة رائعة ، وربما بعض الأعمال التأسيسية التي تم إجراؤها في إطارات البيانات والتوزيعات تستحق الكتابة أيضًا؟ أنا بالتأكيد سأستمتع بقراءته.

حسنًا ، ما جعلني أفكر في الأمر هو أنه تمت كتابة الكثير منه: http://docs.julialang.org/en/latest/devdocs/subarrays/. بالنسبة للمنشور ، قد ترغب في الخوض في الكثير من التفاصيل ، ولكن هذا يصل إلى عدد لا بأس به من نقاط الصورة الكبيرة الرئيسية.

بالنسبة للسؤال الذي طرحه stevengj حول الإرسال المتعدد ، أود أن أقول إنه بدون الإرسال المتعدد ، من الصعب جدًا كتابة مكتبتنا الأساسية في جوليا. أنا أقول ما هو معروف بالفعل للجميع هنا ، وأتساءل عما إذا كان هذا ليس مثالًا مقنعًا للأسباب التي أثيرت هنا.

ترتبط التفاصيل مثل العمليات على الأرقام والتحويل / الترويج بشكل معقد بإرسال متعدد. نظرًا لأن الإرسال المتعدد هو ما يفضح أساسًا استدلال النوع في المترجم للطريقة التي تُستخدم بها الأنواع في الكود ، فنحن قادرون على كتابة مكتبة قاعدة رقمية عامة وسريعة. لاقتباس عبارة قمت بها - فهذا يساعد في فصل صنع السياسة من المترجم إلى مكتبات. على سبيل المثال ، أظهر لي JeffBezanson مرة كيف تنفق مواصفات المخطط ثلث مساحتها على التفاصيل الرقمية.

غالبًا ما ينتهي الأمر بالعديد من الأنظمة المفسرة بامتلاك أنواع عامة وفحص أنواع كائناتها في وقت التشغيل لاتخاذ قرارات بشأن الكود المطلوب تنفيذه. غالبًا ما يكون لديهم تطبيق منفصل في C / C ++ / Fortran في المكتبة الأساسية لكل نوع ، مما يؤدي إلى قاعدة بيانات كبيرة ويصعب تصحيحها. غالبًا ما يتم إنشاؤها من خلال نظام ماكرو خارجي ، ولكن استخدام قوالب C ++ أدى بشكل متزايد إلى تجنب هذه المشكلة المحددة. مسألة اللغتين ونوع الاستدلال لا تزال قائمة في هذه الحالات.

في مستوى ما ، يكون الاتجاه هو عدد اللغات العلمية التي تستهلك تكلفة تحديد الأنواع في وقت التشغيل والقيام باختيار الكود المناسب. في Julia ، مع الجمع بين الاستدلال بالنوع ، والإرسال المتعدد والبرمجة العامة ، تكون تكاليفنا لكليهما أقل بكثير مما يسمح لنا بكتابة كود منفصل عام - C بدون أنواع.

أحد الأمثلة على ذلك هو مقارنة عدم المساواة مع MathConst (تمثل أرقامًا غير منطقية) في PR # 9198:

https://github.com/JuliaLang/julia/pull/9198/files#diff -e247e18c426659d185379c7c96c1899dR29

• يقارن FloatingPoint مقابل MathConst التعويم مع العائم أعلى / أسفل الثابت
• يجد Rational{T} مقابل MathConst (لأنواع الأعداد الصحيحة المحدودة T ) أقرب عقلاني يمكن تمثيله بواسطة النوع ؛ ثم بناءً على ما إذا كان أعلى أو أدنى من النوع غير المنطقي الحقيقي.

ما يجعل هذا ممكنًا هو الوصول السهل إلى وظائف Rational و BigFloat في وقت الترجمة. على الرغم من أنه قد يكون من الممكن استخدام شيء مثل المعالج الأولي للماكرو ، إلا أنه يتطلب عمليتين أساسيتين لكل الوظائف.

لدي تحديث صغير حول هذه المسألة. المستند مفتوح الآن للجمهور: https://github.com/JeffBezanson/phdthesis

اليوم أطلق نوعًا من المسودة حسب الموعد النهائي الذي فرضه على نفسه. انها ليست مسودة كبيرة. العديد من القطع مفقودة تمامًا. أنا أيضًا لا أطالب بأي مسؤولية عن أي شيء موجود داخل تعليقات TeX ، أو موجود فقط في محفوظات الإصدار السابق :)

نرحب بجميع الملاحظات! على وجه الخصوص ، إذا كان لديك أمثلة لطيفة من كود جوليا تُظهر اللغة جيدًا ، خاصةً أي شيء يصعب الاستغناء عنه. أبحث دائمًا عن أمثلة إرسال متعددة جيدة وغير تافهة.

شكرا لجعل هذا العام. لقد فوجئت عندما حاولت اتباع رابط استخدمته SGJ وضربت 404.

ربما يمكن أن يكون حساب المصفوفة المثلثية مثالاً على فائدة إيفاد جوليا المتعدد. هنا UpperTriangular+UpperTriangular=UpperTriangular ، لكن UpperTriangular+LowerTriangular=Matrix .

تحدثنا أيضًا عن الترويج لأنواع العناصر. يعجبني أنه يمكنك تجنب الترويج عندما لا يكون ذلك ضروريًا ، على سبيل المثال

julia> Base.LinAlg.UnitLowerTriangular(ones(Int, 3, 3))\[1,2,3]
3-element Array{Int64,1}:
 1
 1
 1

julia> Base.LinAlg.UnitLowerTriangular(ones(Int, 3, 3))\[1,2,3.0]
3-element Array{Float64,1}:
 1.0
 1.0
 1.0

لا يمكنني تحديد مدى خصوصية هذا بالنسبة لجوليا ، ولكن كما رأينا ، يبدو أن Eigen على الأقل لن يدير عملية الترقية ، ولكنه يتطلب أن تكون أنواع العناصر مستقرة في ظل عملية الجبر الخطي.

نتمنى أن يذهب جيف إلى المرحلة النهائية الآن ، لذا فإن التعليقات على أطروحته وتصحيحاتها (انظر مستودع جيثب المذكور أعلاه) ستكون موضع ترحيب خاص الآن.

لا تتردد في إرسال تقارير العلاقات العامة للأخطاء المطبعية والمراجع المفقودة وما إلى ذلك.

stevengj هل نتوقع إعلانًا عن جدول الدفاع هنا؟

نعم.

آمل أن يكون لديه وظيفة في صفوف معهد ماساتشوستس للتكنولوجيا بالفعل ... (أو في أي مكان حيث سيواصل عمل جوليا الرائع) ... قراءة أطروحته الآن ... أشياء رائعة ، IMO!

andreasnoack مقصور على فئة معينة ، لكنه مضحك على أي حال: حدد نوع حلقة مصفوفة السهم وقم بتطبيق عامل تشوليسكي من القاعدة لترى كيف تبدو بنية عامل التشولسكي لمصفوفة الأسهم لمصفوفات الأسهم. https://gist.github.com/mschauer/c325ff89cd378fe7ecd6 ("A" مصفوفة سهم ، "F" مصفوفة كاملة ، "L" سهم نصف سفلي ").

تضمين التغريدة

تم تحديد موعد الدفاع: الأربعاء 13 مايو ، الساعة الواحدة ظهرًا Stata D-463.

JeffBezanson هل تخطط لتسجيله من خلال replay.csail.mit.edu؟

... ربما أفضل أن أنساها ... :)

أليس هذا ما هو مربع الاختيار الأخير؟

هل أنت متأكد من أنك يجب أن تعطي العنوان؟ قد تتعرض للمضايقات من قبل المعجبين الذين يريدون نسخًا موقعة من أطروحتك! : ابتسامة عريضة:

لقد حصلت بالفعل على التذاكر الخاصة بي. سمعت أن السعر يصل بالفعل إلى 800 دولار في السوق السوداء.

لم يكن Stata D-463 موجودًا في يومي ... (لقد كنت هناك فقط لزيارة الأصدقاء وفي يوم قاعدة بيانات NE) ... هل سيكون كبيرًا بما يكفي؟ بالتأكيد سيحتاج إلى 10-250!

رسميًا D-463 يناسب 48 كرسيًا. إذا اعتقدنا أن هذا لن يكون كافيًا ، فيمكننا النظر في الحصول على غرفة أكبر.

أنا بجدية لا أعتقد أنك تقدر حقًا ما فعلته! إذا ظهر جميع المعجبين بك ، فربما لن يكون 10-250 كبيرًا بما يكفي ... احجز Kresge الآن!

التجريد في الحوسبة التقنية

• مرشح الدكتوراه: جيف بيزانسون
• مشرف الرسالة: الأستاذ الدكتور آلان إيدلمان
• لجنة الأطروحة: البروفيسور ستيفن جونسون ، البروفيسور سامان أماراسينغ ، البروفيسور جيري سوسمان
• التاريخ: الأربعاء 13 مايو 2015
• الوقت: 1 مساءً
• الموقع: حرم معهد ماساتشوستس للتكنولوجيا ، 32-D463

_ تشتهر بيئات البرمجة المستندة إلى Array بالحوسبة العلمية والتقنية. تتكون هذه الأنظمة من مكتبات وظائف مدمجة مقترنة بلغات عالية المستوى للتفاعل. على الرغم من أن المكتبات تعمل بشكل جيد ، إلا أنه يعتقد على نطاق واسع أن البرمجة النصية بهذه اللغات بطيئة بالضرورة ، وأن الأعمال البطولية فقط في الهندسة يمكنها في أحسن الأحوال تحسين هذه المشكلة جزئيًا.

_ تجادل هذه الأطروحة بأن المطلوب حقًا هو بنية أكثر تماسكًا لهذه الوظيفة. للعثور على واحد ، يجب أن نسأل عن ماهية الحوسبة التقنية حقًا. تقترح هذه الأطروحة أن هذا النوع من البرمجة يتميز بالتركيز على تعقيد المشغل وتخصص الكود ، وأنه يمكن تصميم لغة لتناسب هذه المتطلبات بشكل أفضل.

الفكرة الأساسية هي دمج الكود_الاختيار _ مع الكود_التخصص _ ، باستخدام الوظائف العامة واستدلال نوع تدفق البيانات. يمكن أن تعاني أنظمة مثل هذه من التجميع غير الفعال ، أو من عدم اليقين بشأن ما يجب التخصص فيه. نظهر أن الإرسال المستند إلى النوع القوي بما فيه الكفاية يعالج هذه المشاكل. اللغة الناتجة ، جوليا ، تحقق "شرحًا عن طريق الإزالة" بأسلوب Quine للعديد من الميزات الإنتاجية التي يتوقعها المستخدمون في الحوسبة التقنية.

هل ستكون هناك نسخ مطبوعة من أطروحته متاحة للجمهور؟

ربما وقعت نسخ

هذا ما أتمناه ... أعتقد أنه يمكنني الحصول على بعض الدولارات الكبيرة على موقع Ebay لبيع نسخة موقعة في غضون 10 إلى 15 عامًا (عندما أحتاجها حقًا لسداد تعليم أطفالي الجامعي ... esp. إذا ذهبوا إلى حيث قالوا إنهم يريدون الذهاب ...: ابتسامة عريضة:)

حظا سعيدا جيف!

حظ سعيد! إذا كنت في المنطقة ، فسأكون أحد المعجبين الذين ذكرهم ScottPJones

ScottPJones : +1:

كسر ساقه ، جيف!

حظا سعيدا جيف!

حظ سعيد! تضمين التغريدة

تضمين التغريدة

أتمنى أن أحصل على مقعد.

حظا طيبا وفقك الله

أخبرته أنه كان يجب أن يحجز 10-250!

مرسل من الايفون الخاص بي

في 13 مايو 2015 ، الساعة 11:53 صباحًا ، كتب Yichao Yu [email protected] :

تضمين التغريدة

أتمنى أن أحصل على مقعد.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub.

حظ سعيد!

كما سبق!

لحسن الحظ ، دخلت مبكرًا بما يكفي للحصول على مقعد ... وكنت على حق (كالعادة: ابتسامة عريضة :) كان يجب عليه حقًا حجز غرفة أكبر!

تهانينا

مثبت.

لا يزال هناك مربع اختيار واحد غير محدد. من الأفضل أن تعمل.

: shipit:: الاستوائية_المشروب:: بيرز:: كوكتيل:: تادا:!

:ممتاز:

مبروك يا دكتور بيزانسون!

مبروك يا جيف!

+1

أحسنت

تم ملء خانة الاختيار الأخيرة الآن بويسكي كنتاكي بوربون.

مبروك جيف!

يوم الأربعاء ، 13 مايو 2015 الساعة 1:44 مساءً ، مايك نولتا إخطارات @github.com
كتب:

+1

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/JuliaLang/julia/issues/8839#issuecomment -101772806.

تهانينا!

مبروك جيف! : بيرز:: بيرز:: ابتسامة:

هذا رائع! مبروك يا جيف. :العاب ناريه:

أخبار رائعة. مبروك يا جيف!

تهانينا!

تهاني

Woop woop تهانينا جيف!

مبروك يا دكتور بيزانسون!

شكرًا لنشر الصورة ،ScottPJones. jiahao ، أعتقد أن لديك بعض الصور أيضًا؟

مبروك جيف. لقد أثر عملك الذي انتهى بهذه الدكتوراه على الكثير منا. سيكون لها تأثير كبير بالفعل على الحوسبة العلمية! انطلق!

تهانينا.

رائعة!

مبروك جيف !!

رائع ، مبروك !!

تهانينا للدكتور بيزانسون!

الأطروحة لمن يرغبون في إلقاء نظرة خاطفة:

https://github.com/JeffBezanson/phdthesis/blob/master/main.pdf

تهاني!

تهانينا!

تهانينا!

تهانينا: +1:

لا أعرف لماذا قررت GitHub تدوير كل صوري ، لكن ها هي.

إصدار فيديو حفل الختام: http://youtu.be/hGpLOZX6CEY

ألف مبروك لك يا جيف! إذا كنت في سياتل ، دعني أشتري لك مشروبًا للتهنئة. :)

مبروك جيف. إنه شعور جميل جدًا أن تحتفل بعملك كمجتمع.

تهانينا!

jiahao ، قد يكون من المفيد إعادة تشغيل أحدث عالم لـ Julia كمواد تكميلية لصفحة الشكر والتقدير :)

شكرا لكم جميعا.

للأسف لم يتم الانتهاء من أطروحتي بالفعل ، ولكن آمل أن يتم قريبًا ...

لدي المزيد من الصور ، سأرسلها إلى جيف بعد أن أستيقظ (لأمه ، سيدة لطيفة جدًا!) _يمكن للدكتور بيزانسون نشرها هنا إذا رغب ...

لم تفعل؟؟؟ هل طلب منك جيري إزالة كل هذا "التركيب" الدموي والسماح له بالكتابة باستخدام تعبيرات s؟

JeffBezanson استخدام جهاز Mac ليس صورة لم أتوقع رؤيتها على الإطلاق!

ياي!

تهانينا

أحسنت من كل معجبيك هذا الجانب من البركة.

لم تفعل؟؟؟ هل طلب منك جيري إزالة كل هذا "التركيب" الدموي والسماح له بالكتابة باستخدام تعبيرات s؟

لقد فعلتها! انا لا امزح. لكنه سيستقر في وضع s-expr الاختياري.

كنت أتحدث إليه بعد العرض التقديمي ... لقد أحب الأشياء الخاصة بك ، لكنه لم يهتم حقًا بكل ما يتعلق بالصياغة ... هناك الكثير منها فقط ... لقد ذكرني بمدى صغر حجم دليل المخطط : ابتسامة عريضة: عندما أمضيته في 6.001 [تم تدريس الفصل الدراسي الأول] ، كان علينا تنفيذ مترجم مخطط صغير في MacLisp ... نظرًا لأن البرنامج كان صغيرًا جدًا ، كان ممكنًا جدًا ...

وأنا متأكد من أنه يمكنك التخلص من ذلك بسرعة كبيرة ، باستخدام زجاجة البوربون هذه للشركة (إذا بقي أي شيء! ؛-))

عند الحديث عن طول دليل المخطط ، إنه أمر مضحك: نسبة كبيرة منه مخصصة لتوثيق سلوك الأرقام ، بينما في جوليا يتم تعريفها في المكتبات. من المحتمل أن تكون جوليا لغة أساسية أصغر من لغة المخطط (ما لم تكن بالطبع قد قمت بتدبيس مواصفات LLVM بها).

سواء أكان ذلك أم ضده ، هناك الكثير من التركيز على بناء الجملة! راجع أيضًا القسم 7.1 من http://www.schemers.org/Documents/Standards/R5RS/HTML/. بناء جملة المخطط أكثر تعقيدًا مما يعتقده الناس!

من المحتمل أن تكون جوليا لغة أساسية أصغر من لغة المخطط (ما لم تكن بالطبع قد قمت بتدبيس مواصفات LLVM بها).

نعم ، جوليا لديها عظام جيدة!

هل حان الوقت لاستكشاف الماكرو @sexpr القديم؟

مبروك على التخرج وعلى ما حصلت عليه مع جوليا!

: cake: مبروك!

تهانيناJeffBezanson!

تهانينا :)

: +1:

تضمين التغريدة وقت طويل لا رؤية!

أشتقت لكم يا أصدقاء :)

تهانينا!

مجرد سؤال: لا يحتوي ملف PDF على روابط في ToC ولا فهرس قابل للتصفح في البيانات الأولية لقوات الدفاع الشعبي.
لماذا يصعب على كاتب مترجم متخرج من معهد ماساتشوستس للتكنولوجيا إضافة \ usepackage {hyperref} في ديباجته؟

هذا لأنه من المفترض أن تقرأ كل شيء وليس مجرد تخطي. ؛-)

لكن نعم ، هايبرريف سيجعل هذا أكثر سهولة.

أعدك بقراءة كل شيء إذا قمت بإضافة الروابط: P

تهانينا. الحرية تنتظر.

تهانينا ، دكتور بيزانسون!

@ nicola-gigante ، يمكنك تقديم طلب سحب: ابتسامة : .

هل يمكننا الضغط من أجل جائزة أفضل أطروحة؟

http://awards.acm.org/doctoral_dissertation/nominations.cfm

تهنئة!!!

jpfairbanks - فكرة جيدة! يجب أن يقدمه مستشار أطروحته على الرغم من ... إلحاح آلان إيدلمان ، على ما أعتقد ...

نعم ، يحتاج إلى ترشيح من قبل المستشار و 5 خطابات دعم. مرتكز على
هذه المشكلة أعتقد أن 5 أشخاص على الأقل يعتقدون أنه يستحقها.

هل يقتصر على 5 خطابات دعم؟ أيضًا ، العدد الحقيقي للأشخاص الذين يعتقدون أنه يستحق ذلك أكبر ببضع مرات على الأقل!

تضمين التغريدة

alanedelman : أعتقد أن jpfairbanks لديه وجهة نظر جيدة ، يجب أن يتم ترشيح جيف لجائزة أطروحة الدكتوراه من إيه سي إم.

تضمين التغريدة

ScottPJones "بالإضافة إلى ذلك ، يجب تضمين 3 رسائل على الأقل وليس أكثر من 5 رسائل داعمة من خبراء في هذا المجال يمكنهم تقديم رؤى أو أدلة إضافية على تأثير الأطروحة."

ربما يكتب له جيري واحدة (بعد أن يضيف وضع s-expr!): ابتسامة عريضة:

الصفحة الأولى لأخبار القرصنة :-) مبروك يا جيف.

@ nicola-gigante أنت على حق ، سأضيف hyperref.

شكرا للجميع مرة أخرى. كل تقديرك هو الجائزة النهائية.

jiahao لأن لديهم بيانات دوران EXIF ​​لا تهتم بها المتصفحات. معظم الوقت. لا يهتم Chrome ببيانات EXIF ​​إلا إذا كانت الصورة هي النافذة الخاصة به. انقر بزر الماوس الأيمن و "فتح في علامة تبويب جديدة" لرؤيتها بالاتجاه الصحيح.

يمكنك استخدام أداة إزالة البيانات الوصفية EXIF ​​لإزالتها وتدويرها بالطريقة "الصحيحة".

+1 لترشيح جائزة أطروحة ACM.

آخر موعد للترشيح هو 31 أكتوبر 2015.

http://awards.acm.org/doctoral_dissertation/nominations.cfm

لا أحب أن تطلب ACM نقل حقوق النشر إليهم وحقوق النشر الحصرية. لا تزال قيمة ومرموقة على أي حال.

تهاني!

حقوق النشر الحصرية!؟! لدي ديبس على نسخة موقعة (أو اثنتين ... أحتاج واحدة لبيعها على e-bay في غضون 10-15 سنة ، وأخرى لأحتفظ بها لنفسي: ابتسامة عريضة :) ... يجب أن أحصل على ذلك قبل أن يتم قفله بواسطة ACM!
(بالطبع ، ربما يعني ذلك أنه سيكون متاحًا في المكتبة الرقمية لـ ACM للأعضاء)

بمجرد تسليم الرسالة لي للتوقيع لدي كل النية
من ترشيح الأطروحة لجوائز مختلفة :-)

يوم الأحد ، 17 مايو 2015 الساعة 8:49 صباحًا ، سكوت ب
كتب:

حقوق النشر الحصرية!؟! لدي ديبس على نسخة موقعة (أو
اثنان ... أحتاج واحدًا لبيعه على e-bay في غضون 10 إلى 15 عامًا ، وآخر لأحتفظ به لنفسي [الصورة:
: ابتسامة عريضة:]) ... حصلت على ذلك قبل أن تغلقه ACM!
(بالطبع ، ربما يعني ذلك أنه سيكون متاحًا على أجهزة ACM
مكتبة رقمية للأعضاء)

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/JuliaLang/julia/issues/8839#issuecomment -102801616.

لا توجد تعليقات منJeffBezanson ... آمل أن يحتفل (تحقق أكثر من صندوقه الأخير) ، ولم يتم قفله في غرفة في مكان ما بواسطة GJS حتى يعمل على وضع s-expr!

تهانينا!

تهانينا ،JeffBezanson!

(متأخر) مبروك!

تحديث: أرسل المستند للتو. النسخة المقدمة هي https://github.com/JeffBezanson/phdthesis/tree/876be73a5aab9b034fac3eb9ea9d8f96713f786f .

أنا متأكد من أنها ناقصة من نواح كثيرة. اوه حسنا. آمل ألا يكون هناك شيء سيء حقًا.

لطيف - جيد. تهانينا على الانتهاء حقًا من الحصول على درجة الدكتوراه.

مبروك يا جيف! إنجاز عظيم. أنا متأكد من أنك سعيد لأن الأمر انتهى.

لقد وجدت بالفعل أن أطروحتك تملأ بعض الثغرات في وثائق جوليا ، لذلك من الواضح أنها ستكون مفيدة للغاية. جميع الوثائق بها عيوب. البقية منا معجبون بنقاط القوة! تهاني!

وشكرا لك على مشاركتها!

ووت! مبروك الانتهاء من المناقشة والأطروحة وكل الأعمال الأخرى التي تدل عليها وتمثلها. من الجيد أن يكون لديك هذا الإنجاز للتعرف على كل الأشياء التي أنجزتها. أتمنى أن تكون فخوراً!

JeffBezanson ، آمل أنك تخطط لأخذ بضعة أيام إجازة للاحتفال بالبرودة والاحتفال ، أو ربما تخطط للاحتفال بإصلاح نظام الكتابة أو شيء من هذا القبيل. :-)

جميل أن ملف pdf الجديد يحتوي على Hyperref - لمن يرغبون في التصفح. يجب أن نضعه أيضًا في قائمة منشورات جوليا.