+1 لعدم وجود مشغلي infix على الإطلاق. هذا الموضوع يجذب الكثير من الضوضاء ، و O (n) مقابل a * b * c * d ... التسلسل ليس جيدًا.

إذا كان هناك نقاش حول البدائل ، فعندئذٍ +100 لنقلها إلى القائمة البريدية julia-infix-operator-debates .

+1 لعدم وجود مشغلي infix على الإطلاق. هذا الموضوع يجذب الكثير من الضوضاء ، و O (n) لـ a * b * c * d ... التسلسل ليس جيدًا.

+1 لذلك

إذا كان هناك نقاش حول البدائل ، فعندئذٍ +100 لنقلها إلى القائمة البريدية لمناقشات جوليا إنفكس عامل التشغيل.

: يضحك:

هههه. +1 على julia-infix-operator-debates .

(سأشعر شخصيًا بالحزن لرؤية هذا الاستخدام لـ * و ^ اذهب ...)

قدم ستيفان مؤخرًا شرحًا لطيفًا وموجزًا ​​عن سبب رغبته في رؤيتهم يذهبون ، سأقتبس ذلك هنا:

مشكلتي مع * لسلسلة السلاسل ليست أن الناس يجدونها غير متوقعة ولكنها استخدام غير مناسب للوظيفة العامة * ، والتي تم الاتفاق عليها لتعني الضرب العددي. إن الحجة القائلة بأن الأوتار تشكل أحاديًا هي حجة رقيقة نوعًا ما لأن الكثير من الأشياء تشكل أحاديًا ولا نستخدمها بشكل عام. في الوقت الذي قدمت فيه * للسلاسل ، كنا أقل صرامة بشأن تلاعب المشغل - استدعاء | و & لأوامر الصدف - لقد أصبحنا أكثر صرامة بمرور الوقت ، وهذا أمر جيد. هذه واحدة من آخر التورية المتبقية في المكتبة القياسية. السبب في أن ++ سيكون أفضل ليس لأنه سيكون من الأسهل التعلم (يعتمد على المكان الذي أتيت منه) ، ولكن لأن عامل ++ في جوليا يعني بشكل لا لبس فيه تسلسل التسلسل.

لاحظ أن عامل المعاقبة ليس مصدر قلق أكاديمي بالكامل. تُظهر حالة ركن Char أين يمكن أن تسبب العقوبة مشاكل: قد يتوقع الناس بشكل معقول أن ينتج "x" * 'y "إما" xy "أو 241. لهذا السبب ، فإننا فقط نجعل كلتا العمليتين لا أخطاء في الأسلوب ، ولكنها قد تكون معقولة تمامًا للسماح لـ 'x' ++ 'y' بإنتاج "xy". هناك حالات أقل بكثير لوجود 'x' * 'y' ينتج 241 أو 'ñ' ، لكن عملية التسلسل التسلسلي منطقية بالفعل.

مراجع المناقشات السابقة:
https://groups.google.com/forum/#!msg/julia -dev / 4K6S7tWnuEs / RF6x-f59IaoJ
https://groups.google.com/d/msg/julia-users/nQg_d_n0t1Q/9PSt5aya5TsJ
https://groups.google.com/d/msg/julia-users/JnTy-XcfLF8/JeeHREk2TvwJ

1771

2301

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

لم أشاهد هذا قبل إطلاق العنان للتشدق على آخر سلسلة بريدية غير متوقعة خرجت عن مسارها ، حيث اقترحت julia-stringconcat بدلاً من (الأفضل) julia-infix-operator-debates . + إنتماكس. اقتل عوامل التشغيل.

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

1) أنت بحاجة إلى شيء ليس له معنى آخر للناقلات ، لأن الناس الذين
القيام بمعالجة السلسلة لكسب العيش توقع أن تكون قادرًا على استخدام السلاسل كمتجهات للأحرف
(والعكس صحيح). قد يستبعد ذلك + و * و ^ و & و ||.

2) أنت بحاجة إلى شيء لا يمكن الخلط بينه وبين معظم المبرمجين (وليس فقط العدد
عالم الحوسبة). هذا يستبعد ، <> (SQL واللغات الأخرى).
أعتقد أن ++ سيكون _little_ مربكًا ، ولكن نظرًا لأنه عامل أحادي في C / C ++ / Java / إلخ.
وسيكون هذا عاملًا ثنائيًا ، أعتقد أنه سيكون جيدًا.

3) تحتاج إلى عامل تشغيل بسيط ، على الأقل للتسلسل ، وإلا فسوف يتم لصقك به
طن من الطماطم الافتراضية من قبلنا جميعًا الذين يقومون بمعالجة السلسلة.

سأصوت لـ ++ ، يتم استخدامه للتسلسل بلغة شائعة بشكل معقول ، مثل Haskell ،
إنه يثير فكرة الإضافة إلى السلاسل معًا ، أي ربطها ، وهي كذلك
ليس لها أي معنى آخر للناقلات / المصفوفات ، ويمكن استخدامها كعنصر عام
عامل تسلسل المتجه / المصفوفة ، وهو جيد أيضًا (لكل نقطة 1 أعلاه)

https://www.destroyallsoftware.com/talks/wat

للتعبير عن رأيي في هذه المسألة ، لقد استخدمت اللغات التي كان عامل تسلسل السلاسل فيها . ، + ، (مسافة) ، _ و ++ . عندما بدأت جوليا وعلمت أن _ كانت مشغل concat ، كانت فكرتي الأولى هي cool, that makes sense ، لأنني لم أحب أبدًا + . الحجة الوحيدة المؤيدة لعدم استخدام * أحبها هي تلك التي قدمها StefanKarpinski حول الغموض بين Char كعدد صحيح و Char كسلسلة مكونة من حرف واحد. على هذا النحو ، يبدو أن ++ كمشغل concat معقول ، على الرغم من أنه في هذه الحالة يجب أن نعطيه دلالات واضحة. الخيارات الثلاثة العامة لـ ++ (ما يجب أن تفعله إذا كان النوع متساويًا يبدو واضحًا) التي تبدو معقولة بالنسبة لي هي:

++(x,y) = ++(string(x),string(y))
++(x,y) = #MethodError
++(x,y) = ++(promote(x,y)...)

حيث يروج الترويج لنوع حاوية مناسب. الخيار الأخير يعني

x = Uint8[1,2,3]
"abc"++x == Uint8['a','b','c',1,2,3]

keno ، هذا غير صحيح ، لأن "a" هو Char ، نوع 32 بت.
لذلك ، يجب أن تكون الإجابة إما: UInt8 [97 ، 98 ، 99 ، 1 ، 2 ، 3] ، أو Char ['a' ، 'b' ، 'c' ، 'x01' ، 'x02' ، 'x03 "]

أنا أصوت لصالح ++

في الواقع ، إذا كان لديك ASCIIString ، فيمكنه الترقية إلى UInt8 [] فقط ، ولكن يجب ترقية UTF8String (بالإضافة إلى UTF16String و UTF32String) إلى Char [].

(وهذا النوع من الترويج سيكون مفيدًا جدًا لمعالجة السلسلة الخاصة بي ...)

يمكن أن يكون عنوان هذه المشكلة "أخذ سلسلة السلسلة على محمل الجد".

الغموض بين Char كعدد صحيح و Char كسلسلة مكونة من حرف واحد.

سألاحظ فقط أن:

julia-0.4> Char <: Integer
false

julia-0.4> 'a' * 'b'
ERROR: MethodError: `*` has no method matching *(::Char, ::Char)
Closest candidates are:
  *(::Any, ::Any, ::Any)
  *(::Any, ::Any, ::Any, ::Any...)

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

من فضلك ، دعونا لا نُخضع أنفسنا لأكثر من 200 تعليق قبل أن نشعر أنه تم التعامل معها بجدية كافية.

هل يمكن لشخص أن يقيم علاقات عامة؟ أعتقد أن الجميع يؤيد إهمال * ، ^ (إذا كان ذلك لإزالة خطأ القائمة البريدية فقط). يبدو أن عامل ++ يحصل على قوة دفع جيدة ، ولكن من الواضح أنه أمر صعب وليس من الواضح جعله عامًا. هناك دلالات صعبة (مثل push! مقابل append! ) ، تعقيد حسابي ضعيف ، وليس هناك حاجة واضحة لمواد متكررة أخرى. لذلك دعونا نجعلها تعمل بشكل جيد مع السلاسل (وربما الأحرف) ونسميها اليوم.

ScottPJones بالتأكيد ، كنت أكتبها بهذه الطريقة لأغراض توضيحية ، حيث يمكن تحويل Char s إلى Uint8 s إذا كانت في النطاق. تمت الموافقة على مشكلة ترقية UTF8String.

jiahao : يمكن أن يكون عنوان هذه المشكلة "أخذ سلسلة السلسلة على محمل الجد".

هههه.

أي شخص في أمر دفعة؟

أعتقد أنني أريد واحدة ، لكن هل يمكنني الحصول عليها بـ ++ بدلاً من * ؟

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

• إيقاف استخدام * و ^ للسلاسل
• تنفيذ ++ للسلاسل على السلاسل

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

اريد واحد مع ++! : ابتسامة عريضة:

staticfloat : 100:: +1:

إذا أردنا إجراء مناقشة حقيقية حول "التعامل بجدية مع السلاسل" ، على سبيل المثال ، مثل مشكلات الأداء المتعلقة بمحاولة جعل السلاسل يتم إنهاؤها 0 ، فأين يمكننا القيام بذلك؟ (فكر في عملية السلسلة الفرعية أو الشريحة الشائعة جدًا على سلسلة ... مع Julia ، عليك إنشاء سلسلة جديدة في كل مرة)

إذا كنا نتعرض لكسر في السلسلة على أي حال ، فيبدو أنه وقت مناسب مثل أي وقت للتخلص من $ أيضًا.

ربما يكون البديل المفضل المفضل لدي لعدم التسبب في حدوث كسر هو الإصدار الخالي من المشغل (https://github.com/JuliaLang/julia/tree/jb/strjuxtapose)

+1 لإيقاف * و ^ للسلاسل.

أشعر بالكثير من الغموض حول عامل التشغيل ++. من الجيد الآن ، على سبيل المثال ، أن يقوم "$a$b" و string(a,b) بنفس الشيء تمامًا. سيكون من السهل الخلط بين هذا و a++b . كم مرة تحتاج إلى ربط سلسلة بمصفوفة؟ هذه عملية غريبة ، نظرًا لأنه ليس من الواضح ما تشير إليه عناصر المصفوفة --- يمكن أن تكون نقاط رمز أو بيانات أولية.

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

"foo"  "bar" # "foobar"
"foo"   bar  # "foo$bar"
 foo   "bar" # "$(foo)bar"
 foo "" bar  # "$foo$bar"

من قبل ، كان لهذا عيب أنه لم يكن هناك نموذج عامل منه ، على سبيل المثال أنه يمكنك الانتقال إلى reduce ، لكن هذا لم يعد صحيحًا بعد الآن حيث يمكنك استخدام التحميل الزائد للمكالمات لجعل ""(args...) do سلسلة السلسلة . وبالتالي ، يمكنك كتابة reduce("", objs) والحصول على سلسلة من الجمل النصية لمجموعة من العناصر. يمكن تعميم هذا من خلال:

julia> call{S<:String}(str::S, args...) = join(args, str)
call (generic function with 934 methods)

julia> reduce("", [1,"foo",1.23])
"1foo1.23"

julia> reduce(",", [1,"foo",1.23])
"1,foo,1.23"

إذا كنت على وشك التعليق على ما كتبهStefanKarpinski للتو ، فيرجى قراءة # 2301 أولاً.

تضمين التغريدة لم يكن هناك نهاية للأخطاء في التعليمات البرمجية من تطبيقات Multivalue / Pick ، ​​لأنهم استخدموا التجاور ... من الصعب معرفة ما كان يفعله الكود بالفعل.
أيضًا ، ما يحدث مع الحجج الكلية ... المسافة البيضاء مهمة في جوليا ، إذن
<strong i="8">@foo</strong> "Scott" "Paul" "Jones" للماكرو توقع 3 وسيطات تبدأ في الانهيار ، أليس كذلك؟

JeffBezanson إذا اضطررت إلى استخدام Vector {UInt8} أو Vector {Char} للسلاسل القابلة للتغيير ، لإجراء معالجة السلسلة الخاصة بي ، فأنا أود حقًا أن أكون قادرًا على ربط سلسلة غير قابلة للتغيير إلى أحدها ... تمامًا مثل الأشخاص يشكو من عدم القدرة على ربط السلاسل و Chars الآن ، فهما عمليتان يتم إجراؤهما بشكل متكرر.

ولكن ما الذي يفعله تسلسل سلسلة مع Vector {UInt8}؟ ماذا لو احتوى المتجه على UTF-8؟

JeffBezanson يجب أن يكون
يجب أن يؤدي تسلسل المتجه {Char} مع UTF8String إلى إرجاع Vector {Char} (على سبيل المثال ، قم بالتحويل من UTF8-> UTF32 أولاً) ... بالنسبة للأداء ، سأفحص UTF8String لمعرفة عدد الأحرف المنطقية أولاً ، وإنشاء الإخراج تخزين مؤقت كبير بما يكفي لكليهما ، ثم انسخ Vector {Char} ، وقم بتحويل UTF8String مباشرة إلى المخزن المؤقت ...)

في الواقع ، ربما يكون من الأفضل اللعب على أي تسلسل باستخدام المتجهات ، باستثناء ربما Vector {Char} ، ولديك حزمة سلسلة قابلة للتغيير ، وإضافة طرق لـ ++ هناك ... أكثر نظافة ، IMO.

نعم ، أوافق ، على خلاف ذلك ، يصبح الأمر معقدًا بعض الشيء.

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

أتفق مع pao على أن ركوب الدراجة على هذا يؤدي إلى نتائج عكسية ، وأجد صعوبة في فهم سبب اهتمام الناس كثيرًا بتهجئة هذا. * السهل التعود على Char*Char لا يأتي كثيرًا بما يكفي ليكون جديرًا بالقلق.

التسلسل a * b هو اسم مستعار لـ string(a, b) باستثناء الحالة الخاصة حيث يكون a و b مصفوفات رقمية ، نعم ، أو رقمية ، فهذا يعني تتضاعف.

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

سيؤدي ذلك أيضًا إلى تسهيل جعل a op b op c op d يعني string(a,b,c,d) مع تأثيرات الأداء الواضحة. لذلك فقط string() يحتاج إلى تحسينات في الأداء (حيث إنها وظيفة عامة جدًا في الوقت الحالي).

++ جيد. يمكن عمل ما يفعله لغير سلاسل لاحقًا.

stevengj 1) لماذا تفترض أن Char ++ Char لا يأتي كثيرًا للقلق؟
هذا شيء يزعجني بشأن المناقشات هنا ... أرى الكثير من "هذا ليس مهمًا" ... ولكن هذا مجرد رأي ، ولديك أشخاص من ذوي الخبرة في معالجة السلاسل يخبروك أنها _هي_ مهم. 2) * أمر محير إلى حد ما بالنسبة للكثير من الناس ، كما أقول أنه بالنسبة لمعظم الأشخاص الذين يقومون بمعالجة السلسلة ، فإنهم يفكرون أولاً في التكرار ، وليس التسلسل مطلقًا. لقد رأيت الكثير من الناس قد طرحوا ذلك. 3) ربما كان يجب أن يكون مقدار التعليقات السلبية حول * كعامل تشغيل تسلسلي ، منذ سنوات ما رأيته ، دليلًا على أنه لم يكن القرار الأفضل ، وكان يجب إعادة النظر فيه مرة أخرى في الإصدار 0.1 أو 0.2 ، ليس عندما يريد الناس إطلاق سراح 0.4 ...

simonster بخصوص "abc"++[1, 2, 3] . هذا مثال جيد على أن "عامل التشغيل بالنقطة" رمزي موروث من matlab يعضنا من وقت لآخر. لمقارنتها ، فإن عامل التشغيل التسلسلي في J / APL هو , ويأتي مع "عائلة من مشغلي النقاط" المميزة بالشرائح التي يجب أن يعمل عليها المشغل.

   'abc' , '123'
abc123

'abc' ,"0 '123'
a1
b2
c3

او حتى

 'abc' ,"1 0 '123'
abc1
abc2
abc3

هذا لا يعالج مسألة نوع الترويج الذي تناولته.

_ تعديل: أرغ ، لقد ضيعت الفرصة لأقول لا شيء

ScottPJones ، يبدو أن الكثير من اللغات الأخرى لديها عوامل تشغيل Infix لسلسلة السلاسل ولكن ليس مشغلات Char-concatenation. لا أرى ضجة من الشكاوى. لا يزال بإمكانك ربط الأحرف عن طريق تنفيذ string(char1, char2) (أو استخدام سلاسل length-1 كما في Python) ، لذلك لا توجد وظائف مفقودة. إذا نظرت إلى الكود الموجود في أي لغة منتشرة ، فإن عدد استخدامات تسلسل السلاسل يفوق عدد مثيلات تسلسل حرفين.

الادعاءات بأن تسلسل الأحرف في أي مكان قريب من أهمية أو فائدة تسلسل السلسلة هي ببساطة غير معقولة.

ستكون هناك دائمًا تعليقات سلبية حول اختيارات التدقيق الإملائي. (سيشتكي الأشخاص القادمون من Python دائمًا من أننا نحتاج إلى end بدلاً من استخدام المسافة البادئة.) تختلف الأذواق ، ويمكن لبعض الأشخاص الذين لديهم مشاعر قوية إحداث الكثير من الضوضاء. إذا اخترنا ++ ، فأنا أضمن لك أن الوافدين الجدد سيستمرون في الشكوى - "لماذا لم تستخدم + ؟ + أكثر قابلية للاكتشاف وبديهية لأنني معتاد إليها من اللغة _X_. "

لا يعجبني بشكل خاص * ؛ أنا ببساطة لا أهتم كثيرًا. شعوري هو أن الشفرة المستمرة تتسبب في حدوث تغييرات إملائية لا طائل من ورائها هي أكثر ضررًا لجوليا من أي فائدة سنحصل عليها من استبدال حرف بأخرى.

بصرف النظر عن كل ذلك ، سيكون ++ مؤلمًا للغاية من وجهة نظر الترقية. نظرًا لأن ++ لا يتم تحليله حاليًا كعامل infix ، فلن تكون هناك طريقة نظيفة للحفاظ على التوافق مع الإصدارات السابقة مع Compat - ستكون ترقية في يوم العلم ، تتطلب كل حزمة تستخدم تسلسل السلسلة إلى fork في إصدارات 0.3 و 0.4 (أو استخدم string(a,b) ، للتخلي عن تسلسل infix بالكامل).

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

نعم ، يجب تغييره مرة واحدة فقط ، من ما هو عليه الآن إلى الحالة النهائية (أو لا تغيير إذا كان هذا هو القرار). إن الإهمال الآن وإضافة عامل تشغيل لاحقًا عندما يقوم الجميع بتغيير الكود الخاص بهم إلى سلسلة (أ ، ب) أو "$ a $ b" يعني فقط للمستخدمين.

و O (n) لـ a * b * c * d ... التسلسل ليس جيدًا.

هل يمكنك أن تفعل أفضل من O (n) لسلسلة السلسلة؟

stevengj تميل اللغات التي استخدمتها (والتي يتم استخدامها بكثافة أيضًا في معالجة السلاسل) إلى عدم وجود نوع حرف منفصل (M [UMPS] و Pick و JavaScript و Lua و Python وغير ذلك الكثير ...) ، لذلك لا تظهر مشكلة على الإطلاق ، وتلك التي تعمل (Java ، C ++) تتعامل مع سلسلة من السلاسل مع الأحرف والأحرف ذات الأحرف بشكل جيد.
لا أعرف ما هو الكود الحالي الذي كنت تبحث عنه ، ولكن في جزء كبير من الكود الذي تعاملت معه (كل من الكود الداخلي والرمز عند آلاف العملاء) ، تم ربط الأحرف بالأحرف والسلاسل بشكل كبير (وتم تحسينه بشكل خاص بسبب عدد المرات التي تم إجراؤها فيه) [وفقط واحد من هؤلاء العملاء مسؤول عن حوالي 54٪ من السجلات الطبية داخل الولايات المتحدة].
هذا ليس "تغييرًا إملائيًا لا طائل منه" ، فقد طرح الكثير من الأشخاص عددًا من الاعتراضات الجيدة على استخدام * لتسلسل السلسلة ... إذا لم يزعج الأشخاص بجدية ، فلن ترى هذه المحادثة باستمرار هيا تعال.
إذا كنت لا تستخدمها كثيرًا ، ولا تهتم كثيرًا بشكل خاص ، ويرى الأشخاص الذين يرغبون في إجراء معالجة سلسلة في Julia أن هذا يمثل مشكلة خطيرة ، فلماذا تعترض كثيرًا؟
لم أدافع أبدًا عن التغيير * إلى شيء آخر بناءً على الذوق ، أو لأن لغة أخرى تفعل ذلك بطريقة مختلفة ، كانت حججي حول: الارتباك (يميل الناس أكثر إلى التفكير في التكرار ... (* يعني جعل مضاعفات شيء!) ، وعدم الاتساق مع المتجهات (وهي مشكلة للأشخاص الذين يقومون بالكثير من معالجة السلاسل ، فنحن نميل إلى التفكير في السلاسل على أنها نواقل للأحرف) ، والمشكلات المتعلقة باستخدام Char باستمرار (Char * Char ، والتي لديها ولكن ماذا عن المعاملات الرقمية الأخرى باستخدام Char؟ أحيانًا يعمل Char مثل UInt32 ، وأحيانًا لا يعمل ...)

اختر ، على سبيل المثال ، استخدام حرف واحد "محددات النظام" ، يُشار إليه بأشياء مثل @RM ، @VM ، @FM ، @SVM. .. (سجل ، قيمة ، file ، وعلامات subvalue) ، لذلك سترى "Scott":<strong i="9">@SVM</strong>:"Jones":<strong i="10">@VM</strong>:1:<strong i="11">@SVM</strong>:"Memorial":<strong i="12">@SVM</strong>:"Drive" ، لإنشاء سجل ، من المحتمل أن يبدو في JSON [["Scott","Jones"],["1","Memorial","Drive"]] .
في النكاف ، يتم ذلك على النحو التالي:
"Scott"_$c(1)_"Jones"_$c(0)_1_$c(1)_"Memorial"_$c(1)_"Drive"
(لكن في الممارسة العملية ، يمكنك استخدام ماكرو لـ $c(0) و $c(1) ، مثل $$$subdlm و $$$valdlm ... هذه هي نفسها Char(0) و Char(1) في جوليا)
ونعم ، هناك أيضًا الكثير من الأماكن التي يكون فيها تسلسل أحرف متعددة ... في M [umps] ، هناك بناء الجملة $char(codepoint,...) ، لذا يمكنك الحصول على $c(1,a,1,b,2,c) ... [ حيث يتم تقييم أ ، ب ، ج كأعداد صحيحة ، أي نقاط رمز).

simonbyrne أنا لا أفهم حتى لماذا قال أحدهم أن a * b * c * d يجب أن يكون O (n) ... هذا جنون!
(ولكن ربما كان الأمر كذلك في جوليا ، إشارة أخرى إلى أن التعامل مع الخيط ببساطة لم يؤخذ على محمل الجد)

بيانات سلسلة السلسلة من بعض لغات البرمجة الأكثر شيوعًا :

• Python: + ، لا توجد سلسلة أحرف (أو نوع حرف)
• بيرل: . ، لا يوجد نوع حرف
• روبي: + ، لا يوجد نوع حرف
• C ++: + لكل من السلاسل والأحرف (ولكن فقط من أجل string + char ، وليس char + char)
• فورتران: // (يتم التعامل مع الأحرف والطول 1 بالتبادل تقريبًا)
• اذهب: + ، بدون سلسلة شخصية
• هاسكل: ++ ، لا توجد سلسلة أحرف (لكن قبلها عبر : )
• جافا: + ، لا توجد سلسلة أحرف (يبدو أنها موجودة ولكنها موثقة بشكل سيئ)
• الهدف ج: عدم وجود عامل تشغيل للتسلسل (والكثير من الشكاوى عبر الإنترنت)
• C #: + للسلاسل والأحرف (أحرف "unicode" 16 بت)
• جافا سكريبت: + ، بدون نوع حرف
• باسكال: + ، تسلسل الأحرف (يبدو أنه موجود في بعض إصدارات باسكال) موثق بشكل سيئ
• فيجوال بيسك: + و & ، تسلسل الحرف موجود على ما يبدو لكنه غير موثق

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

أيضًا ، تشير البيانات إلى أن التحميل الزائد على معنى التسلسل بعملية حسابية ليس مشكلة خطيرة: يبدو أن الناس يعتادون عليها بسهولة ، ويستمرون في اعتمادها بلغات جديدة.

وتشير البيانات إلى أن بناء الجملة لتسلسل الأحرف ليس مشكلة مهمة - فالعديد من اللغات المستخدمة بشكل شائع لمعالجة السلاسل لا تحتوي حتى على نوع حرف ، والعديد من اللغات التي تحتوي على نوع حرف إما لا تحتوي على حرف + سلسلة أو char + char التسلسل ، أو إذا فعلوا ذلك ، فلن يكلفوا أنفسهم عناء توثيقها جيدًا. إذا كنت تقوم بالكثير من تسلسل الأحرف في الحلقات الداخلية ، فربما تحتاج إلى رمز أكثر تخصصًا على أي حال ، وإذا لم يكن في رمز الأداء الحرج ، فيمكنك دائمًا استخدام سلاسل string أو السلاسل length-1.

(على أي حال ، نظرًا لأن Char لم يعد نوعًا فرعيًا Integer في 0.4 ، إذا أردنا ذلك ، يمكننا دائمًا إضافة عامل سلسلة أحرف في وقت ما في المستقبل. أو يمكنك إضافة هذا بنفسك في برنامجك الخاص إذا كانت عملية مهمة في بعض حالات الاستخدام المتخصصة. بيت القصيد من تصميم Julia هو أن الوظائف "المضمنة" لا تتمتع عادةً بميزة أداء معينة على كود المستخدم.)

ScottPJones ، إذا خصصت سلسلة متجاورة جديدة ، فإن a * b * c * d يكون بالضرورة Ω (n) ، حيث n هو العدد الإجمالي للأحرف ، لأنه يحتاج إلى لمس كل البيانات. لا يمكنك القيام بعمل أفضل إلا إذا أنتجت " سلسلة حبل " أو بنية بيانات مشابهة لا تنسخ البيانات فعليًا ، ولكن لها عيوبها (قد تكون العمليات اللاحقة أبطأ). التقصير في تخصيص سلسلة متجاورة جديدة ليس بالأمر الجنون ، وفي الحقيقة يبدو أنه ما _جميع_ لغة أخرى افتراضية أيضًا.

لا أعتقد أن هناك أي مشكلة على الإطلاق مع a * b * c ، على الأقل ليس أكثر من أي مشكلة مع string(a,b,c) ، نظرًا لأنها مترجمة إلى ذلك :

julia-0.4> <strong i="9">@which</strong> "a" * "b" * "c"
*(s::AbstractString...) at string.jl:77

ومع ذلك ، أوافق 100٪ مع stevengj لذا سأترك الأمر عند هذا الحد.

ومع ذلك ، أوافق 100٪ مع stevengj لذا سأترك الأمر عند هذا الحد.

: +1:

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

stevengj هذا هو استنتاجك ... لا أوافق بشدة على أنه يجب أن يكون + ، إذا كان هناك أي شيء ، للعديد من الأسباب نفسها التي تجعل * مشكلة في جوليا ، من حيث أنها تجعل الكثير من المشاكل عند التعامل مع Chars والقدرة على التصرف بنفس الطريقة على السلاسل والمتجهات.
بياناتك غير صحيحة على الرغم من ذلك ، + بالنسبة إلى Java يعمل بشكل جيد مع شخصية ، كما أن VB يعمل أيضًا (جربهم إذا كنت لا تصدقني! [وهو _ موثق])
في Haskell ، ما عليك سوى عمل سلسلة نصية ++ [ch] أو [ch] ++.
يعمل باسكال أيضًا بشكل جيد (يمكنني إرسال مثال لك)
لذلك ، بالنسبة إلى Python و Perl و Ruby و C ++ و Java و C # و JavaScript و VB و Fortran و Haskell و Pascal ، ليس لديهم مشكلة في تسلسل الأحرف ...
(أيضًا ، ترى أن اللغات التي تركز حقًا أكثر على معالجة السلاسل عادةً _ لا_ لها نوع حرف منفصل ، وسلسلة واحدة طولها واحد فقط ، مثل اللغات التي عملت عليها ، حيث كان كل شيء عبارة عن سلسلة ...)
لقد تركت مع Go & Objective C مما يجعل الأمر أصعب قليلاً ...
أعتقد أنك تسيء تفسير "البيانات" تمامًا ... فليس الأمر أن تسلسل الأحرف ليس مشكلة مهمة ، إنه ببساطة أنه بالنسبة للغالبية العظمى من اللغات ، يتم التعامل معه ويعمل كما هو متوقع ، وبالتالي لا تحصل على كل الشكاوى التي تحصل عليها بخصوص جوليا.

ليس لدى بايثون وبيرل وروبي نوع حرف.

simonbyrne آسف ، لقد أخطأت في قراءة ذلك ... كنت أفكر في O (n ^ 2) ، وهو ما رأيته في Julia مؤخرًا ... (لأن السلاسل غير قابلة للتغيير ، وإذا كان لديك حلقة تبني سلسلة ، يخصص الكثير من الذاكرة ، ويقضي الكثير من الوقت في عمل GC ...)

حتى لا تحصل على كل الشكاوى التي تتلقاها بشأن جوليا.

يأتي هذا في قوائم بريدية على دراجات هوائية كل بضعة أشهر

StefanKarpinski كان ذلك جزءًا من وجهة نظري ، أن اللغات التي تركز على معالجة السلاسل ليس لها نوع خاص من الأحرف ،

لأن السلاسل غير قابلة للتغيير ، وإذا كانت لديك حلقة تبني سلسلة ، فإنها تخصص الكثير من الذاكرة ، وتقضي الكثير من الوقت في عمل GC

أنت لا تريد أن تفعل هذا. يجب عليك الطباعة إلى كائن IOBuffer بدلاً من ذلك ثم أخذ السلسلة في النهاية. هذا مشابه لنمط StringBuilder في Java.

قد ينتهي الأمر بـ Stefan مثل جميع قادة C ++: يزعمون بصوت عالٍ أن استخدام الأعداد الصحيحة غير الموقعة لـ std :: vector كان خطأ فادحًا ارتكبوه ، لكن لا يزال معظم مبرمجي C ++ يعتقدون أن هذا هو ما يجعل C ++ لطيفة جدًا. الشهرة قادمة إلى جوليا ؛-)

بالمناسبة أنا أصوت لـ ++.

ScottPJones ، لم يتم توثيقها بشكل جيد ، إذا لم تتمكن من العثور على الوثائق في 10 دقائق من Googling على "لغة الأحرف المتسلسلة X". (بشكل عام ، إذا كنت تبحث عن "سلاسل متسلسلة" مقابل "أحرف متسلسلة" ، فمن الواضح على الفور أي شخص يهتم أكثر بأمره.)

stevengj Umm ... بالنسبة للأشخاص الذين يهتمون بها ، فهم عمومًا يعاملون كل شيء كسلاسل فقط ، لذلك لن ترى "أحرف متسلسلة" تظهر عند البحث. لا يعني ذلك أنه ليس مهمًا ، أو أنه تم تنفيذه بشكل كبير ... (بهذه الحجة ، يكون الضرب حسب التعريف تبادليًا ، لأن هذا ما سيخبرك به بحث Google!)

إنه نوع من الاختراق ولكن للسماح لـ Compat بالتعامل مع ++ يمكن أن يبحث عن هذا النوع من نمط AST:

julia> :('x'++'y') |> dump
Expr
  head: Symbol call
  args: Array(Any,(3,))
    1: Symbol +
    2: Char x
    3: Expr
      head: Symbol call
      args: Array(Any,(2,))
        1: Symbol +
        2: Char y
      typ: Any
  typ: Any

عامل التشغيل .. متاح أيضًا. لا يبدو أن أحدًا يحب التجاور / "" للتسلسل.

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

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

أنت لا تريد أن تفعل هذا. يجب عليك الطباعة إلى كائن IOBuffer بدلاً من ذلك ثم أخذ السلسلة في النهاية. هذا مشابه لنمط StringBuilder في Java.

StefanKarpinski هذا فقط ما عليك القيام به في Java أو Julia للأداء ، بسبب السلاسل الثابتة ... هذا لا يعني أنه سهل الاستخدام ، أو أن الناس سيتفهمون في البداية سبب بطء جوليا في المقارنة لبيثون تفعل شيئًا مثل بناء سلسلة ...
(لا أحب Java لمعالجة السلسلة أيضًا ، لهذا السبب)

StefanKarpinski ، لا يمكن لـ إفساد تعبيرات x + +y حيث x و y أرقام. من المؤكد أن هذا لا يحدث كثيرًا ، لكني أكره أن أرى @compat ينفذ تحويلًا قد ينتج عنه رمز غير صحيح.

أليست سلاسل الثعبان ثابتة أيضًا؟

ScottPJones لقد قمت بتدريس الرياضيات لسنوات. جوجل تقول أشياء غبية.

علامة الجمع +: في الرياضيات ، الاصطلاح هو أن + دائمًا عامل تبادلي
الأوقات *: في الرياضيات ، الاصطلاح هو أنه * يمكن أن يكون إما تبادليًا (كما هو الحال مع الأرقام) أو غير تبادلي (كما هو الحال مع المصفوفات). لهذا السبب لدينا حلقات تبادلية وغير تبادلية.

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

لا يبدو أن أحدًا يحب التجاور / "" للتسلسل.

المساحة البيضاء مكتظة بالفعل. سيتعارض مع سياقات الماكرو / hcat. وهو ما يقودني إلى نقطة أثرتها على ML:

لدى Julia بالفعل عاملين متسلسلين ، وهما h - و vcat . لماذا لا تستخدم hcat لتسلسل السلسلة ، بنمط MATLAB؟ هل يعقل بناء مصفوفة من السلاسل؟

أيا كان ( .. ، ++ ، [ ... ] ) ، فأنا أؤيد عامل تسلسل واضح ومتميز للسلاسل والأحرف.

يمكننا إضافة ++ كمعامل إلى 0.4 ، ثم نجعل الإيقاف يحدث بمجرد أن نكون في 0.5-dev. هل هناك عجلة حقيقية هنا؟

فورتران: // (يتم التعامل مع الأحرف والطول 1 بالتبادل)

يبدو كخيار "عقلاني" جيد لجوليا [1].

أتوقع أن بناء سلسلة مع * / string هو تقريبًا O (n * m) في عدد السلاسل التي يتم ضمها (n) وإجمالي عدد الأحرف التي يتم ضمها (m) . نوع من كائن منشئ السلاسل (cStringIO في python ، StringBuilder / StringBuffer في Java ، IOBuffer في Julia) ضروري للأداء الجيد عند بناء أي شيء كبير.

[1] للسياق:

> typeof(1//2)
Rational

تذكرني الحجة الصرفة هنا بكارثة .+ للمصفوفة + العددية. عندما تتعارض النقاء الفلسفي مع العرف اللغوي والتطبيق العملي ، تخسر النقاء.

آه ، مناقشة جيدة لبناء سلسلة O (n ^ 2) ومثل هذه إعادة: python: http://stackoverflow.com/questions/4435169/good-way-to-append-to-a-string

يعجبني حل إنشاء قائمة أو مصفوفة ثم استدعاء join إذا لزم الأمر.

أعرف أن الناس يبنون الأوتار طوال الوقت ، لكن يبدو أنه شيء يجب تجنبه. إذا كان الأمر يتعلق بـ I / O (عادةً ما يحدث) ، فمن الواضح أنك ستحصل على أداء أفضل أثناء إجراء الإدخال / الإخراج مباشرة ، بدلاً من إنشاء سلسلة أولاً ثم إرسالها. حتى أشياء مثل append المحسّن لـ cPython هي فقط _ amortized_ O (n) ، ومن المحتمل أن تتخلى عن عامل 2 أو نحو ذلك.

mbauman هذا يبدو معقولًا بالنسبة لي ، على الأقل.

+1 لمقترحmbauman . يبدو أن الجميع بخير مع ++ وامتلاك عامل تشغيل تسلسل عام هو أمر جذاب للغاية.

بافتراض تقديم ++ ، أعتقد أن نقاط stevengj على Compat تشير بشكل قاطع إلى أن * لا يمكن إهماله في 0.4.

vtjnash // لديه نفس المشكلة المتمثلة في وجود معنى بالفعل في Julia كمشغل ثنائي ... شيء أعتقد أنه سيكون من الجيد تجنبه ...

نظرًا لأننا نصمم من خلال شكاوى القائمة البريدية ، ضع في اعتبارك أننا لم نسمع بعد من كل أولئك الذين يتوقعون ++ ليكون عامل زيادة.

لا أعتقد أنني قلت من قبل أنه * بالنسبة إلى concat ، يجب إهماله على الفور ، فقط يجب أن يكون كذلك ، في وقت ما بعد .. أو ++ أو أيًا كان ما تم تقديمه

JeffBezanson لهذا السبب فضلت Lua .. ، لكن يبدو أن معظم الناس يفضلون رؤية ++ .
أعتقد أيضًا أنها ليست مشكلة كبيرة ، لأن أحدهما أحادي والآخر ثنائي.
(تمامًا مثل DataFrames المحملة بشكل زائد ~)

JeffBezanson عندما

ScottPJones ، إجراء S=""; for s in list; S*=s; end عملية O (n) للسلاسل الثابتة بدلاً من O (n ^ 2) يختلف تمامًا عن المناقشة هنا ؛ هل يمكنني تقديم نداء للتركيز؟

stevengj لقد كان timholy و @ johnmyleswhite من طرح O (n) .. ولسوء الحظ أخطأت في قراءة ذلك كـ O (n ^ 2) ، وهو ما رأيته لبناء سلاسل مقارنة باللغات الأخرى مثل Python. .. غلطتي!

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

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

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

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

هذا الخيط يرفع ضغط دمي ، وهي ليست مهمة سهلة ، لكني أشعر أنه مناقشة من نوع design-by-mailing-list ، أريد فقط إلقاء وزني (الذي تستخدمه جوليا يوميًا) خلف كل شيء تقريبًا stevengj يقول. أعتقد أن تغيير عامل التشغيل إلى ++ أمر جيد ، ولكنه سيؤدي فقط إلى جولة جديدة من الشكوى لأنه ليس مجرد + (ويبدو أنه زيادة) ، كما يشير JeffBezanson خارج. لا أفهم المشكلة مع string * char نظرًا لأن char s لم تعد أعدادًا صحيحة - هل هناك أي مشكلة؟

إذا كان المشغل سيتغير ، فإن mbauman لديه الفكرة الصحيحة عن الجدول الزمني. أعتقد أنه يجب أن يكون:

1. أضف كبديل لـ * الآن. لا يمكن لأي شخص يدعم 0.3 و 0.4 استخدامه. إن إضافة تحذير من الإهمال لـ *(string,string) سيكون غير مناسب لأن أي شخص يستخدم 0.4 مع حزمة تحاول دعم 0.3 سيتم التعامل معه معهم.
2. 0.4 يخرج. تبدأ العبوات في التحول من 0.3 / 0.4 إلى 0.4 / 0.5
3. تمت إضافة تحذير الإيقاف لـ 0.5 ، لذلك يمكن أن تتحول الحزم التي تدعم 0.4 و 0.5 فقط إلى ++ .
4. 0.5 يخرج. إزالة * من 0.6.

هل هذا حقا يستحق كل هذا العناء؟

تعد إضافة عامل تشغيل تسلسل تسلسلي ، والذي ليس لدينا ببساطة ، فكرة مشروعة. من الواضح أنه لن يتم استخدام * لإلحاق القوائم أو المصفوفات. ومع ذلك ، ربما يكون وجود عامل يدعو إلى حلقات O (n ^ 2) x ++= y كثيرًا. من الناحية الفنية ، يعتبر بناء الجملة والأداء متعامدين ، ولكن في الممارسة العملية يمكن أن يكون لبناء الجملة هذا النوع من التأثير.

IainNZ لا أعتقد أنه من الصحيح حقًا أن Char لم تعد أعدادًا صحيحة ، إنه مجرد إزالة عمليات معينة (* و / و ^) ، لكنني أعتقد أن هذا يؤدي فقط إلى مشكلات عدم اتساق أخرى ... أي لماذا يعمل + و - ولكن ليس * ...)

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

julia> Char <: Integer
false

تحرير: ... وأنا مع IainNZ بشأن ضغط الدم.

JeffBezanson ++ = y لن يدعو حلقات O (n ^ 2) أكثر من * = y حاليًا ، وقد يمنح المترجم فرصة أكبر لتحسين ذلك ربما؟

pao ، صحيح ، لقد لاحظت أن * توقف عن العمل بين 0.3 و 0.4 ، وأن +/- لا يزال يعمل ... لذلك لا بد من إضافة هؤلاء خصيصًا لنوع Char؟

أنا قلق أكثر بشأن انتشار المشكلة إلى أنواع أخرى ، على افتراض أن ++ تدعم المصفوفات والقوائم.

نتعامل الآن مع Char كنوع ترتيبي.

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

أعتقد أنه سيهدئ مخاوفي بالكامل تقريبًا إذا لم يكن لدينا مشغل ++= . يفترض الكثير من الناس ، ولا يمكنني لومهم حقًا ، أن عامل مثل += يتغير.

قد يكون لديك عامل تشغيل فرصة لتحسين أشياء مثل CPython أسهل ...

ليس من العملي حقًا تحسين S=""; for s in list; S*=s; end مثل CPython ، بغض النظر عن التهجئة. ليس لدى جوليا أعداد مرجعية ، لذلك لا توجد طريقة لوظيفة *(S,s) لمعرفة أنها تحتوي على المرجع الوحيد لـ S ومن ثم فإن S آمن للتحور. يمكن للمترجم أن يكتشف ذلك في بعض الحالات بالطبع ، لكن النقطة الأساسية في تصميم Julia هي أنه لا يميز الأنواع المضمنة على الأنواع المحددة من قبل المستخدم. علاوة على ذلك ، فإن تحسينات المترجم السحري تزيد من صعوبة التفكير في أداء الكود والتصميم المتوقع للرمز للحصول على أداء جيد (راجع CPython مقابل PyPy). لن يغير عامل التشغيل ++= أي شيء بخصوص هذا الأمر ، وكما يقول JeffBezanson أنه ربما يشجع الناس على الإفراط في استخدام تسلسل الصفيف أيضًا. انظر أيضا المناقشة في # 7052.

على أي حال ، لا أرى مشكلة كبيرة في أن بنية الكود الأمثل في Julia تختلف قليلاً عن بنية الكود الأمثل في CPython. ستكون مشكلة كبيرة إذا كان الحصول على أداء جيد في Julia أكبر من ذلك في CPython ، ولكن join(list) ليس صعبًا / معقدًا بشكل خاص ، ولا يتم الكتابة إلى IOBuffer() .

لاحظ أيضًا أن جوليا ليست غريبة بشكل خاص في التسلسل المتكرر O (n ^ 2) ؛ انظر على سبيل المثال Ruby or Go . حقيقة أن التسلسل (على عكس مثال append! ) لا يتغير أبدًا هو سلوك شائع سهل الفهم ويمكن التنبؤ به.

إن التحميل الزائد على += بالكامل في Python أمر مزعج للغاية بالمناسبة ، فإنه يفتح أخطاء التعرج الدقيقة مثل هذا:

>>> x = [1,2,3]; y = x
>>> x += [4]
>>> print(x,y)
[1, 2, 3, 4] [1, 2, 3, 4]
>>> x = x + [5]
>>> print(x,y)
[1, 2, 3, 4, 5] [1, 2, 3, 4]

أعتقد أن هذه المناقشة تقترب بالفعل من نهاية ذات مغزى (!!).

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

إنه لأمر مؤسف أننا لم نتمكن من استخدام "_" كمعامل سلسلة سلاسل. نظرًا لأن هذا نوع من ما يفعله على أي حال ، عند استخدامه في أسماء المتغيرات ...

إذا كان عامل تشغيل سلسلة نصية ، فلا يمكنك استخدامه في أسماء المتغيرات ...

برنامج cormullion في M [umps] أو CacheObjectScript إذن! : ابتسامة عريضة: بجدية ، كان وجود عامل تشغيل منفصل للتسلسل ، والذي لم يتم استخدامه لأي شيء آخر ، أمرًا رائعًا ، على الرغم من أنني كنت أتمنى في بعض الأحيان وجود شخصية أخرى متاحة ، لأن الأشخاص القادمين من أي مكان آخر يرون this_is_foo_bar ويعتقدون أنها قد تكون الاسم ... (لكن M يعود إلى منتصف الستينيات ، قبل اصطلاحات اسم متغير / ماكرو C)

مجرد سؤال ... ورجاءً لا يزعج أحد! هل يمكن استخدام تركيبات مثل $+ $/ $* كمعامل؟ هل سيواجه هؤلاء المشكلة التي تم طرحها مقابل ++ (أي a + +b )؟ (إلى جانب كونها _ قليلاً _ مربكة للوهلة الأولى لمبرمجي C / C ++ / C # / Java ...)

أشبه $ باعتباره (جزءًا من) عامل سلسلة سلسلة ، وله تشابه جميل مع استخدام $ كمعامل استيفاء للسلسلة و $ يشبه S للسلسلة.

إذا كان بإمكاني اكتشاف (ربما مع بعض المساعدة :-)) كيفية السماح لمحلل النظام بالسماح $ + $ * $ / ، وما إلى ذلك كرموز ، فسأقوم بعمل شوكة للأشخاص لتجربة ذلك ، وانظر كيف يفعلون ذلك يعجب ب...

إنه في الواقع سهل للغاية. أعتقد أن كل ما تحتاجه هو إضافته إلى قائمة المشغلين على مستوى الأسبقية المناسب: src / parser. scm: 16 . لا تحتاج حتى إلى إعادة بناء جوليا بالكامل لاختبارها - فقط make -C src وسيستغرق الأمر 5 ثوانٍ. أعتقد أن $$ مفتوح أيضًا.

إذا كان من الصعب تذكر * ، لا أرى كيف يكون $+ أسهل. أيضًا ، أعتقد أنه من الأفضل فقط تعليم أن IOBuffer هو تجريد منشئ الأوتار في Julia وأن يتم التعامل معه ، بدلاً من وجود سلسلة قابلة للتغيير (باستخدام طرق append! و insert! ) و الكائن IOBuffer (مع طرق print و write ) ويطلب من المستخدم محاولة اختيار النوع المناسب.

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

أعتقد أن تذكر $$ سيكون أسهل بكثير من تذكره على سبيل المثال $+ .

فقط بعض الأفكار:

1. إذا كانت هناك مشكلة في تنفيذ ++ ، فلماذا لا ** بدلاً من ذلك؟ [1]
2. من فضلك لا $ مجموعات! IMHO هذا مشفر.
3. يعتمد ** على * الفعلي و ++ .

أعتقد أن الحصول على "a" ** "b" للحصول على "ab" (أو تسلسل تسلسلات أخرى) لا يبدو أمرًا سيئًا.

• [1]: يستخدم Python و Ruby ** للأُس بدلاً من ˆ (حتى أن هناك تحذيرًا في بناء الجملة):

julia julia> ** ERROR: syntax: use "^" instead of "**"

يمكن فقط توثيقها باختلاف اللغات الأخرى في الأسئلة الشائعة.

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

1) لا يمكن الخلط بينه وبين أي عامل رياضيات (على الأقل باللغات الرئيسية التي أعرفها) ،
على عكس ++ ، ** ، + ، * ، <> ، || ، & ، ~ المستخدمة في لغات أخرى.
2) لا تفرط في تحميل شيء آخر وبالتالي يمكن استخدامها كعامل سلسلة عام ،
أي vcat للنواقل ...
3) ليس به مشاكل التحليل (على الأقل ، التي أدركت حتى الآن) ، التي بها ++ ، والتي
أعتقد أن @ StefanKarpinski طرح.
4) تذكرنا بكل من "سلسلة" $ و بالإضافة إلى +.

بالنسبة للأشخاص الذين يتلاعبون بالسلسلة ، من الصعب للغاية محاولة برمجة كل شيء باستخدام IOBuffers ... لا يبدو الرمز بديهيًا على الإطلاق ، ولا يحتوي على عمليات السلسلة التي تريدها ، وقد يكون لها عبء أكبر من عندما تريد ببساطة إجراء بعض العمليات مثل:
`mystr [5:10] =" fish "# على سبيل المثال ، استبدل السلسلة الفرعية بين الحرفين 5 و 10 بـ" fish "`

toivoh على الأقل بالنسبة للأشخاص القادمين من إحدى اللغات المستخدمة في التلاعب بالسلسلة / قاعدة البيانات ، فإن $$ قد يربك الأشخاص ، فهذا يشير إلى استدعاء دالة صريح ... ولا يحتوي على أي شيء يشير إلى التسلسل على عكس لتكرار سلسلة أو تقسيمها أو تقطيعها بواسطة حرف أو سلسلة فرعية ... على سبيل المثال ، قد يعني $* التكرار ، و "foo" $* 3 سيحصل على "foofoofoo" و "foo,bar,baz" $/ "," (أو حتى ',' ) ستعيد المجموعة ("foo","bar","baz") ، والتي أعتقد أنها ستكون لطيفة جدًا ؛-)

يتم استخدام @ Ismael-VC ** بشكل متكرر _very_ للتعبير عن الأس ... السبب الكامل لإثارة بعض هذه الفوضى هو تجنب الالتباس قدر الإمكان ، سواء بالنسبة للأشخاص القادمين من خارج جوليا ، وكذلك بالنسبة لجوليان ، حيث يوجد زيادة في التحميل العامل * بشيء مختلف تمامًا من الناحية المفاهيمية يمكن أن يسبب الصداع.
إذا رأيت ** ب في الكود ، فهل ستفكر حقًا أولاً في تسلسل السلسلة؟
أولاً ، من المحتمل أن تعتقد أنه أسي ، إذا كنت قد أتيت من العديد من اللغات الأخرى ...
ثانيًا ، لا يوجد ما يشير حتى إلى أنك تقوم بعملية سلسلة.

قد يعطي + على السلاسل خطأ ، ERROR: syntax: use "$+" instead of "+"
يمكن إهمال السلاسل * في وقت ما (لا داعي للاندفاع ، إذا كان لدينا بنية متسقة جديدة ينتقل إليها الأشخاص) ، ويمكن أن تقول: ERROR: syntax: use "$+" instead of "*" ،
نفس الشيء لـ "^" ... ERROR: syntax: use "$*" instead of "^" .

mbauman مساعدة عظيمة !!! فقط بضع إضافات بسيطة لتقديم الجداول بالفعل ، قمت بعمل -C src ، نعم ، بسرعة فائقة (أتمنى لو كنت قد عرفت عن ذلك من قبل ؛-)) ثم فعلت $+ = string (وهو ما أدرك أنه ربما كن شديد التبسيط) ، لكن مهلا ، لقد نجح الأمر! أوه ، كل الحمد لجمال وقوة جوليا! ؛-)
(والشهرة لمن كتب المحلل اللغوي ... اعتدت أن أتقاضى رواتبنا كـ UTA لمساعدة الطلاب في كود المخطط الخاص بهم في 6.001 ... حتى بعد عدم استخدام المخطط في 30 عامًا ، بدا هذا الرمز مفهومًا جدًا)

الشيء الوحيد الذي أحاول اكتشافه الآن هو كيفية جعل $ + يتصرف مثل vcat على المتجهات ...
ساعدنى من فضلك؟

نظرًا لأن $ هو رمز الاستيفاء ، فإن $+ يعني بالفعل إقحام + و $$ تم استخدامه بالفعل كمعامل للاستيفاء مرتين (على سبيل المثال من الخارج نطاق).

وإضافة طريقة لهذه العملية لا يغير حقيقة أن العملية هي O(n*m) وبالتالي غير مرغوب فيه للتدريس

أنا قلق فقط من أنها إساءة استخدام معنى الوظيفة العامة *.

لا أرى في هذا إساءة استخدام لمعنى * . من ناحية أخرى ، سيكون من المثير للاهتمام (إذا كانت لعبة) أن تتم كتابة تحول قيصر على النحو التالي (((uppercase(string) - 'A') + shift) % 26) + 'A' . نظرًا لأن + هو عنصر حكيم ، فهذا معقول (بينما .* كان من الممكن أن يكون عامل ضرب سلسلة العناصر). أعتقد أن السؤال العام الذي يطرحه هذا الأمر هو ما إذا كانت الحالة string * non-string يجب أن تقوم بترقية غير سلسلة إلى سلسلة ، أم أنها صالحة للاستخدام فقط عند دمج السلاسل.

vtjnash هذا ليس صحيحا. يعني $ ONLY رمز الاستيفاء ضمن سياق سلسلة حرفية .... نفس الشيء مع $$ . خارج السلسلة الحرفية ، عادةً ما يعني $ أحادي XOR في Julia ، و
$$ ، $+ ، $* ، $/ لا تعني شيئًا على الإطلاق. لم يتم تحليل هذه على الإطلاق في الوقت الحالي. ومن المثير للاهتمام أن شخصًا ما أضاف بالفعل دعمًا لتحليل .. ، لكن لا يتم استخدامه لأي شيء في الوقت الحالي.

ScottPJones الأمر أكثر تعقيدًا من ذلك: http://docs.julialang.org/en/latest/manual/metaprogramming/#interpolation

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

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

vtjnash حسنًا ، هذا غريب ... لقد رأيت حديثًا عن الاستخدام .. لأشياء مختلفة ، واعتقدت أنه كان مدعومًا بالفعل في المحلل اللغوي لهذا السبب (بالنسبة للحزم التي تختبر الأفكار التي استخدمتها)

ScottPJones ، ربما لم يكن الأمر واضحًا ، لكن vtjnash كان يشرح لماذا .. قابل للتحليل ولكن غير مستخدم. تعريفه واستخدامه جيد:

julia> ..(a, b) = a:b
.. (generic function with 1 method)

julia> 1..4
1:4

لقد تخيلت بالفعل أنه يمكن استخدام .. لشيء ما ، ربما فترات أو تسلسل. تم اقتراحه لـ "سلبيات" أيضًا (# 3160).

إذا كان الأمر متروكًا لي ، فأنا أفضل الحصول على string() . إنه يتجنب هذا النقاش ، فهو يحول الأشياء بشكل لا لبس فيه إلى سلاسل (بدلاً من معاملتها كتسلسلات) ، ويساعد على تثبيط بناء الأوتار O (n ^ 2). string(string(string(a,b),c),d) غير فعال كما هو. مع عامل التشغيل ، يصبح من المغري الكتابة

a ++= b
a ++= c
a ++= d

باستخدام صيغة الدالة ، فإن الطريقة الواضحة للكتابة هي string(a,b,c,d) . بالطبع هذا لا "يحل" بناء الأوتار O (n ^ 2) ، لكنني أعتقد أنه يساعد.

JeffBezanson :: +1:

أيضًا ، بشكل عام ، إذا أصر الأشخاص على infix لوظيفتهم المفضلة ، فقد لا يكون لدى Julia عدد كافٍ من المشغلين لكل شيء (يقتصر على ASCII). يعكس الكثير من المناقشة أعلاه ما يلي: من الصعب العثور على عملية Infix op لتسلسل السلسلة لأنه لا يوجد الكثير للاختيار من بينها. بالنظر إلى string ، $ -interpolation، @sprintf والمكتبات (على سبيل المثال التنسيق ) ، هل يلزم إجراء infix لسلسلة السلسلة؟

في 3 مايو 2015 الساعة 16:41 ، كتب Tamas K. Papp [email protected] :

JeffBezanson https://github.com/JeffBezanson : [الصورة:: +1:]

أيضًا ، بشكل عام ، إذا أصر الناس على وضع infix لوظيفتهم المفضلة ،
فقد لا يكون لدى Julia عوامل تشغيل كافية لكل شيء (تقييد
إلى ASCII). يعكس الكثير من المناقشة أعلاه ما يلي: من الصعب القيام بذلك
العثور على infix op لسلسلة السلسلة لأنه لم يتبق الكثير منها
اختر من. بالنظر إلى السلسلة ، $ -interpolation ، sprintf والمكتبات (على سبيل المثال
التنسيق https://github.com/lindahua/Formatting.jl) ، هو عملية infix op
لسلسلة concat ذلك ضروري؟

يجب على شخص ما أن يقول ذلك: منذ إضافة الرموز التعبيرية ، لم لا: smile_cat:
للتسلسل :)

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

JeffBezanson هذا النوع من التعليقات هو ما يزعجني حقًا:

إذا كان الأمر متروكًا لي ، فأنا أفضل وجود سلسلة فقط ()

ما هو شعورك إذا قلت إن جوليا لا ينبغي أن تمتلك. * ./ إلخ؟
هل ستكون سعيدًا دائمًا عندما تفعل شيئًا مثل matrix_multiply (أ ، ب)؟

وأيضًا ، فإن حجتك حول الكفاءة هي استعلاء إلى حد ما ... فأنت تخبر الناس أنك تعرف أفضل منهم ، حول ما هو منطقي لبرمجتهم.
كما أنني لا أرى أنه يساعد حقًا ... أجد أن الناس سيبرمجون بشكل سيء بغض النظر عن الأدوات التي تمنحهم إياهم لأداء أفضل. أرى الكثير من O (n ^ 2) [أو O (n log n) فقط لأن التخصيص يرتفع بمقدار 2 ، ولكن هذا ليس جيدًا أيضًا] حيث يتم إنشاء السلاسل بالدفع! ... (و لقد حاولت إصلاحها ، مع بعض النتائج الجيدة إلى حد ما للأداء).
إذا كان .. = أو ++ = أو $ + = عامل تسلسل متجه عام ، فإن a ++ = b هو أيضًا بشكل أساسي نفس طريقة الدفع! (a، b).
هل ستقول بعد ذلك أن الضغط! (أ ، ب) يجب إزالته ، لأنه يمكن أن يؤدي إلى كود O (n ^ 2) ، والذي رأيت بالفعل أمثلة حقيقية عنه في الكود في Base؟
عامل التشغيل أيضًا منطقي تمامًا للإضافة إلى سلسلة قابلة للتغيير (أو IOBuffer) ... لماذا تستمر في رؤيتها من حيث أداء نوع واحد فقط؟

tpapp أنا آسف ، لكن هذه الحجة تبدو سخيفة بعض الشيء بالنسبة لي ... بالنظر إلى أن 1) قام محلل جوليا بالفعل بتعريف المئات من أحرف Unicode الغامضة التي يمكنك استخدامها كمعاملين infix ... انتقل إلى src / julia-parser .scm. 2) تسلسل السلسلة هو عملية أساسية في معظم اللغات ... باستخدام استيفاء سلسلة أو سلسلة أو sprintf قبيح مقارنة بوجود عامل infix بسيط ، قد لا يعمل بشكل جيد [يجب أن أرى ما الذي يولده الرمز

elextr نظرًا لمئات عوامل التشغيل التي تسمح بها جوليا بالفعل في المحلل اللغوي ، ربما يجب على شخص ما إضافة _ كل _ ممكن حرف Unicode كعامل تشغيل! ؛-)

kmsquire نعم ، لقد فهمت ذلك ، وقد علقت بالفعل في مكان آخر على القدرة على فعل ذلك بالضبط مع .. (كانت المشكلة هي .. = لم يتم التعامل معها في المحلل اللغوي).

أعتقد أن مشغلي يونيكود يتم اختيارهم من مجموعة فرعية معينة بناءً على أكواد الفئات. أنت حر في اختيار مشغل يونيكود مثل ⊞ وتفعل ما تريد به في الكود الخاص بك (ومن السهل جدًا كتابة ذلك في Julia REPL ، \boxplus ثم اضغط على علامة التبويب - العديد من المحررين لديهم مكونات إضافية لهذه الوظيفة). في معظم الحالات ، قد يكون لمشغلي unicode معاني خاصة بالتطبيق ، لذلك لم نقم بتعيين تعريفات قياسية في Julia لغالبيتهم.

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

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

يعرّف المحلل اللغوي لـ Julia بالفعل المئات من أحرف Unicode الغامضة التي يمكنك استخدامها كمعاملين infix

للمرة الثانية ، ScottPJones ، هذه ليست مجرد أحرف عشوائية

استمر في القول إن push! هو O (n ^ 2) لكنه ليس كذلك. لا. لا. ليست مسألة رأي.

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

من المضحك أنك ذكرت matrix_multiply(a,b) ، لأننا حتى الآن يسعدنا أن نشارك هذا العامل ذاته مع تسلسل السلسلة!

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

tkelman في المحرر الخاص بي ، تظهر معظم هذه الأحرف في julia-parser.scm على شكل فراغات :- (لقد جعل التحرير أمرًا صعبًا بعض الشيء!

هناك الكثير من العمليات المفيدة التي تستمر في الظهور بشكل متكرر ، حيث سيكون من الجيد أن يكون لديهم بناء جملة عامل / محدد / قوس غير يونيكود لهم ، ولكن من النادر العثور على شيء قابل للاستخدام.

هذا ما أزعجني عندما قيل لي إن ~ غير متوفر ، لأنه سبق أن طالبت به DataFrames.jl.

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

نعم ، أعتقد أن هذه فكرة جيدة جدًا.

JeffBezanson لم أقل أنهم كانوا عشوائيين ، فقط أنهم كانوا غامضين ... حوالي نصفهم لم يتم عرضهم في المحرر الخاص بي ... شخص آخر ، أنت ؟، اتهمت فكرتي باستخدام $+ و $* و $/ أنها "دوائر عشوائية" ، بعد أن أوضحت بالفعل أسبابي (على غرار .+ ، .* ، ./ )
لقد تحدثت أنت بنفسك عن O (n ^ 2):

تعد إضافة عامل تشغيل تسلسل تسلسلي ، والذي ليس لدينا ببساطة ، فكرة مشروعة. من الواضح أنه لن يتم استخدام * لإلحاق القوائم أو المصفوفات. ومع ذلك ، ربما يتطلب وجود عامل تشغيل حلقات O (n ^ 2) x ++ = y كثيرًا. من الناحية الفنية ، يعتبر بناء الجملة والأداء متعامدين ، ولكن في الممارسة العملية يمكن أن يكون لبناء الجملة هذا النوع من التأثير.

أيضًا ، أرغب في استخدام ..= أو $+= على السلاسل القابلة للتغيير (أو المتجهات ، أو IOBuffers) ، وليس على السلاسل الثابتة.
أعتقد أن لديك:

myStringBuffer ..= ".txt"

هو _very_ واضح ومقروء ومفيد!

يرجى الرجوع وقراءة ما قلته بالفعل عن push! ... قلت أنه إذا لم يكن الأمر يتعلق بالطريقة التي يعمل بها مخصص الذاكرة ، فسيكون O (n ^ 2) ، ولكن بسبب خدعة (والتي يمكن أن تضيع الذاكرة) لزيادة الحجم بواسطة قوى 2 ، فهي فقط O (n log n).

لقد كنت سعيدًا بمشاركة matrix_multiply مع تسلسل السلسلة ، ولكن بالنسبة لي ، هذا أمر محير ، ويمنع معالجة السلاسل والمتجهات بطريقة متسقة في الأماكن التي يكون من المنطقي فيها.
لقد رأيت الكثير من التعليقات على Google و GitHub حول كيف فاجأ * للتسلسل الناس في البداية ...

myStringBuffer .. = ".txt"
هو واضح جدا ومقروء ومفيد!

أوافق ، وأكره القيام بذلك ، لكن للأسف ستصاب بخيبة أمل: تم تخفيض a += b على الفور إلى a = a+b ، لذلك لا يمكنك تحديد += بشكل منفصل عن + (نفس الشيء بالنسبة لجميع المشغلين الآخرين في هذا النموذج). لدعم هذا الأمر ، سيتعين علينا إجراء استثناء لـ ..= .

أيضًا ، نقطة دقيقة جدًا: أداء push! لا يعتمد على كيفية عمل مخصّص الذاكرة. إنه جزء من تنفيذ بنية البيانات لطلب مساحة أكبر بشكل صريح ، وتتبع مقدار فترة الركود المتاحة. هذا الأداء قابل للنقل لأي نوع من التخصيص أو مخطط GC ، على عكس الأساليب القائمة على العد المرجعي.

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

أوافق ، وأكره القيام بذلك ، ولكن لسوء الحظ ستصاب بخيبة أمل: يتم تخفيض a + = b على الفور إلى a = a + b ، لذلك لا يمكنك تحديد + = بشكل منفصل عن + (نفس الشيء بالنسبة لجميع عوامل التشغيل الأخرى لـ هذا من). لدعم هذا ، يجب علينا عمل استثناء لـ .. =.

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

شكرا على تلك المعلومات.

حول push! ، كنت أتابع ما قيل لي ... من الجيد أن تعرف أن هذا يتم التحكم فيه فقط من خلال تنفيذ هيكل البيانات ، ويمكن تغييره (لا أريد السلاسل _ دائمًا_ تتضاعف في الحجم ، عندما يكون الحجم العديد من الميجابايت ، فقط لأنني أضفت حرفًا إضافيًا واحدًا (مثل إنهاء \0 ؛-))

nitpick الصغرى: إنشاء تسلسل بـ push! ، والذي يضاعف حجم المخزن المؤقت في كل إعادة تخصيص ، هو في الواقع O(n) الوقت المستهلك في حجم النتيجة ؛ كل إعادة تخصيص من حجم k إلى 2k ويدفع ثمنها k/2 الدفعات إعادة تخصيص الحرة التي قبلها.

toivoh أخبرني شخص آخر أنه تم

مجموع قوى 2 حتى N وتشمله هو 2N-1 ، وهو O (N). بالطبع يمكن أن يكون push! بطيئًا في الممارسة بسبب إمساك الدفاتر الإضافية ، ويؤدي إلى إهدار الذاكرة.

ما الذي سيتضمنه إجراء استثناء لـ ..= ؟

يرجى الاطلاع على https://github.com/JuliaLang/julia/issues/249 و https://github.com/JuliaLang/julia/issues/3217 و https://github.com/JuliaLang/julia/issues/7052 ، آخرها تم بالفعل ربطه هنا. لا أعتقد أن تغيير الطريقة التي يعمل بها أي مشغل op= هو أمر مرجح هنا بشكل خاص (بما في ذلك المشغلين الذين لم يتم تعيينهم بعد). نظرًا لوجود حزم بالفعل لإجراء عمليات موضعية على المصفوفات ، أعتقد أن أفضل رهان لك هو متابعة كتابة حزمة للعمليات الموضعية على السلاسل بطريقة لا تتطلب حالات خاصة في جوليا الأساسية.

ScottPJones : نعم ، يرجى تلخيص الأمر! دعونا نتجاهل نسخ كل بايت لأنه يدخل المخزن المؤقت في المرة الأولى (نعلم أن هذا الجزء هو O(n) ). لنفترض أننا بدأنا بمخزن مؤقت بسعة 16 بايت من البيانات ، وأنه كان علينا بالفعل عمل نسخة من 16 بايت. نحن نعيد التخصيص والنسخ ، حتى 32 نسخة في المجموع. عندما يكون المخزن المؤقت 32 بايت ، فإننا نعيد تخصيصه وننسخه مرة أخرى ، بحيث يصل إجمالي النسخ إلى 64 نسخة ، وفي المرة التالية 128 ، وهكذا. لذا ، نعم ، يجب عليك عمل نسخ متعددة ، ولكن في هذه الحالة ينطبق هذا فقط على جزء صغير من البيانات بحيث لا تزال التكلفة الإجمالية O(n) .

يتوقف هذا على حقيقة أنك تقوم بتنمية المخزن المؤقت بواسطة عامل معين على الأقل في كل مرة ، إذا نمت بمقدار ثابت ستحصل على O(n^2) . لذلك إذا كنت لا ترغب في تخصيص 2 ميغا بايت لسلسلة واحدة ميغا بايت ، أعتقد أن أفضل رهان لك هو تخصيص المقدار الذي تحتاجه مسبقًا (أو أكثر قليلاً ، إذا كان يمكنك المبالغة في تقديره فقط).

toivoh موافق ... لقد رأيت التعليقات هنا حول * = كونك O (n ^ 2) للسلاسل ، لقد رأيت الأداء السيئ

push! و *= ليستا عمليات ذات صلة. push! هو O(n) مستهلك عند تنفيذه كعملية نمو٪ ، تسلسل السلاسل ليس O(n) لأنه لا توجد عمليات مجانية ممكنة ، كل تركيبة سلسلة جديدة تتطلب نسخ كل من القديم و بيانات جديدة إلى سلسلة جديدة. يتم نسخ السلسلة الأولى N مرة ، ويتم نسخ السلسلة التالية N-1 مرة ، ... يتم نسخ السلسلة الأخيرة مرة واحدة - وهي O(N^2) .

في المحرر الخاص بي ، تظهر معظم هذه الأحرف في julia-parser.scm على شكل فراغات :- (لقد جعل التحرير أمرًا صعبًا بعض الشيء!

أعتقد أن الوقت قد حان لتجد محررًا جديدًا ، أو على الأقل تنزيل خط أفضل https://github.com/JuliaLang/julia/blob/master/README.windows.md#unicode -font-support
ظهر هذا القلق في الأصل حيث تم اقتراح إضافة المشغلين الجدد ، مع الاستنتاج بأن أي محرر لا يدعم unicode في عام 2015 ربما كان غير ذي صلة بالموضوع. هناك الآن ملحقات جوليا لمعظم المحررين المشهورين الذين يدعمون \pi<tab> -> π .

الوقت الإضافي: أعتقد أنه يجب أن يكون push!(mutablestring, character) أو append!(mutablestring, string) . حيث أن push! يتضمن تغييرات حسب العناصر ، بينما append! يعني ضم كائنين متشابهين. أعتقد أن الشكل غير المتحول لـ append! هو تقريبًا vcat ، لذلك من المفترض أن يكون vcat(string, string) => string عملية ذات مغزى.

vtjnash كنت أتحدث عن وجود عامل إلحاق سلسلة يعمل أيضًا على المتجهات ...
ليس عامل التشغيل الحالي *= ، وأنا أعلم كل شيء عن مشكلة O (n ^ 2) ... لقد ارتكبت الخطأ للتو ، ولم أكن أعرف فقط كيف تم تخصيص ذاكرة Julia لمصفوفة مع دفع !، أنه كان O (ن ^ 2)
(بالنظر إلى الأداء الذي رأيته ، كان افتراضًا سهلاً)

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

الوقت الإضافي: أعتقد أنه يجب أن يكون دفع! (سلسلة متغيرة ، حرف) أو إلحاق! (سلسلة متغيرة ، سلسلة). منذ الدفع! يتضمن تغييرات من حيث العناصر ، في حين أن إلحاق! يعني الجمع بين كائنين متشابهين. شكل إلحاق غير متحور! أعتقد أن vcat تقريبًا ، لذا من المفترض أن تكون سلسلة vcat (سلسلة ، سلسلة) => عملية ذات معنى.

أعتقد أن معظم الأشخاص الذين يستخدمون "سلسلة" مثلي يعتبرون أن الحرف هو في الحقيقة مجرد سلسلة مكونة من عنصر واحد ،
أو السلسلة هي مجرد مصفوفة من الأحرف ... فكر في C ، C ++ ، Go ، Haskell ، ... كل اللغات التي لا تحتوي حتى على نوع حرف منفصل (أنت فقط تستخدم سلاسل بطول 1) ...
جعل هذا التمييز لا يحدث منذ ذلك الحين بالنسبة لبرمجتي ، وهو ليس ثابتًا حتى الآن في جوليا ...

julia> string("foo",'\n')
"foo\n"
julia> "foo" * '\n'
ERROR: MethodError: `*` has no method matching *(::ASCIIString, ::Char)
Closest candidates are:
  *(::Any, ::Any, ::Any)
  *(::Any, ::Any, ::Any, ::Any...)
  *(::AbstractString...)
julia> "foo" * "\n"
"foo\n"

هذا هو السبب في أنني أعتقد أن هناك حاجة إلى مشغل جديد ، من شأنه أن يعمل باستمرار في جميع هذه الحالات ... ويمكنه حتى العمل على IOBuffers ...

MyBuff ..= myline
.... other code ...
MyBuff ..= '\n'
MyBuff ..= "Scott was here!"

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

MyString::UTF8String = "My string"
... code ...
MyString ..= "\n My bad!"
-> would get a compile time error... (or would it be a run-time error?)

عند الحديث عن .. ، تجدر الإشارة إلى أن # 5715 لا يزال يحدث في الإصدار 0.4:

#  Version 0.4.0-dev+4629 (2015-05-04 00:27 UTC)

julia> ..(a, b) = a * b
.. (generic function with 1 method)

julia> "a".."b".."c"
ERROR: syntax: extra token ".." after end of expression

TL ؛ DR (حاولت إجراء مسح ضوئي وقراءة أكثر .. وكل ذلك في منتدى جوليا الذي بدأته ، والآن أكتشف هذا الموضوع).

"أ * ب * ج ، على الأقل ليس أكثر مما يوجد بسلسلة (أ ، ب ، ج)"

لست متأكدًا مما يعنيه هذا تحويل a_b_c إلى سلسلة (أ ، ب ، ج) ، هذا تطبيق واحد لوظيفة السلسلة (أو ثلاثة).

لم أفهم مع أو ضد عوامل التشغيل + أو *. ما لم يتم استخدام + ، ليس لدي تفضيل لأي شخص آخر. فقط تعرف || يستخدم في SQL أو مجرد دالة concat (أ ، ب) أو قطة (أ ، ب). يمكنني الذهاب بدون مشغل.

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

PallHaraldsson راجع https://github.com/JuliaLang/julia/issues/2301#issuecomment -13573303 لمعرفة سبب عدم استخدامنا RopeStrings افتراضيًا. ولكن ينبغي إجراء مزيد من المناقشة حول أداء السلسلة في قضية منفصلة.

يبدو لي أن السلاسل في Julia متشابهة من الناحية التركيبية مع مصفوفات الأحرف (على سبيل المثال ، يمكن فهرسة السلسلة / تقسيمها بنفس الطريقة التي يمكن بها المصفوفة). لذلك أعتقد أن دلالات append! قد تكون أكثر ملاءمة من push! عندما يتعلق الأمر بتسلسل السلاسل.

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

ربما يجب علينا ببساطة إهمال عاملي التشغيل ^ و * وترك التسلسل للوظائف المسماة صراحةً لتجنب الالتباس.

-100 لإزالة * لسلسلة السلسلة. إنه مفيد جدًا في الممارسة ويجعل الكود سهل القراءة. الحجة القائلة بأنه يمكن أن تكون غير فعالة ليست صحيحة في رأيي. في هذه الحالة ، يجب أيضًا إزالة إضافة ثلاثة متجهات a+b+c والتي تعتبر أيضًا غير فعالة بسبب إنشاء الموقتات.

tknopp لا أوافق على أن * يجعل الكود قابلاً للقراءة للغاية ، لأنه مفاجأة لكل شخص جديد يأتي إلى اللغة ، ويجعل الناس يفكرون أكثر في التكرار ، بدلاً من التسلسل ، فضلاً عن كونه مربكًا بشأن ما إذا كان الأشياء التي يتم تطبيقها عليها هي سلاسل أو ناقلات أو أرقام قياسية ...
أعتقد أن الاقتراح الذي يبدو أنه يحظى بأكبر قدر من الدعم هو استبدال * بـ ++ ، a la Haskell.

يجب أن تكون هذه القضية مدفوعة بالخبرة العملية وليس من وجهة نظر أكاديمية. في السنوات الماضية لم يكن هناك الكثير من المناقشات حول * كونه الشيء الخطأ. لماذا توجد مشكلة فجأة؟

من حيث المبدأ ، سأكون بخير مع + لكني لا أرى أن هناك مبررًا كافيًا بأن + سيكون أفضل.

بالمناسبة ، استخدام * شائع جدًا في علوم الكمبيوتر النظرية (قواعد النحو الرسمية). هنا * مع السلسلة الفارغة "" تشكل أحادية.

بدأت أعتقد أنه يجب علينا فقط أن نطلب اتخاذ قرار نهائي من قبل السلطات الموجودة ثم التوقف عن القلق بشأن هذا الموضوع.

tknopp كما قيل عدة مرات في هذا الموضوع ، لن يكون + اختيارًا جيدًا لبعض الأسباب نفسها التي جعلت * اختيارًا جيدًا. كان هناك أيضًا عدد من المناقشات حول أن * مربك ، وما إلى ذلك. ++ سيعمل لأنه عامل أحادي فقط في لغات أخرى ، باستثناء Haskell ، حيث هو عامل التسلسل.

johnmyleswhite : نعم أوافق. لكنني اعتقدت أنهم فعلوا ذلك منذ عدة سنوات. في مرحلة ما على المرء أن يلتزم بالاختيار.

حسنًا ، ربما ستقرر الصلاحيات القائمة إغلاق هذه القضية.

O (n) لـ a * b * c * d ... التسلسل ليس جيدًا.

في هذه الحالة ، يجب أيضًا إزالة إضافة ثلاثة نواقل أ + ب + ج والتي تعتبر أيضًا غير فعالة بسبب إنشاء الموقتات.

هل من الممكن أن يتم تخفيض عوامل التشغيل المتكررة إلى +(a, b, c) / *("a", "b", "c") ؟ عندما يكون هذا منطقيًا / يتم تعريفه ...

_ (IMO السفينة قد أبحرت عليها * لسلسلة سلسلة ، أي حجة لكسر كود الجميع يجب أن تكون قوية.) _

هل من الممكن خفض عوامل التشغيل المتكررة إلى + (أ ، ب ، ج) / * ("أ" ، "ب" ، "ج")؟ عندما يكون هذا منطقيًا / يتم تعريفه ...

أليس كذلك؟

julia> Meta.show_sexpr(:("a" * "b" * "c"))
(:call, :*, "a", "b", "c")

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

ما إذا كانت السفينة قد أبحرت على مشغلي سلسلة جديدة أم لا ، * و + مجرد مشغلين ثنائيين؟

قد اكون مخطئا:

جوليا> أ = 10

جوليا> تفريغ (:( a_a_a))

اكسبر
الرأس: رمز النداء
args: صفيف (أي ، (4 ،))
1: الرمز *
2: الرمز أ
3: الرمز أ
4: الرمز أ
النوع: أي

جوليا> println (أ ، أ ، أ)
101010

julia> println (a_a_a) # ليس كما لو أن a هو السلسلة "10"
1000

تمامًا مثل println والعديد من الوظائف ، بما في ذلك b = string (a ، a ، a) ، هذا
المتسلسلة ، لست متأكدًا من أننا بحاجة إلى المزيد من العوامل للقيام بذلك؟ لا يمكن أن يكون
الطريقة الموصى بها؟

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

[هناك نقطة مسبقة ، للتسلسل ، لا تحتاج إلى مزيد من البحث
أن Informix 4GL :)]

ScottPJones : "++ عامل تسلسل عام (ليس فقط للسلاسل)" ، ماذا تقصد؟ إذا كان 1 ++ 1 يجب أن يكون "11" وليس 2 ، فهذه فكرة سيئة؟

PallHaraldsson كما قلت ، أردت عامل تسلسل عام للسلاسل والمتجهات (مثل vcat ). لم أقل أبدًا أنني أردت استخدام هذا المشغل للكميات (أعتقد أنها لن تكون فكرة جيدة ،
فهو يجعل الأمور أكثر قابلية للارتباك).

يوجد عدد من مشكلات الاتساق في الوقت الحالي ، مثل:

julia> b"a" * b"b"
ERROR: MethodError: `*` has no method matching *(::Array{UInt8,1}, ::Array{UInt8,1})
Closest candidates are:
  *(::Any, ::Any, ::Any)
  *(::Any, ::Any, ::Any, ::Any...)
  *{T<:Union(Float64,Complex{Float32},Complex{Float64},Float32),S}(::Union(SubArray{T<:Union(Float64,Complex{Float32},Complex{Float64},Float32),2,A<:DenseArray{T,N},I<:Tuple{Vararg{Union(Range{Int64},Int64,Colon)}},LD},DenseArray{T<:Union(Float64,Complex{Float32},Complex{Float64},Float32),2}), ::Union(SubArray{S,1,A<:DenseArray{T,N},I<:Tuple{Vararg{Union(Range{Int64},Int64,Colon)}},LD},DenseArray{S,1}))
  ...

julia> vcat(b"a", b"b")
2-element Array{UInt8,1}:
 0x61
 0x62

عامل التسلسل العام ، كما كنت أقترح ، سواء كان ++ أو .. أو أي شيء آخر ، من شأنه القضاء على هذا النوع من السلوك غير المتسق.

@ scottjones : "لم أقل أبدًا أنني أريد استخدام هذا العامل
الحجميات "- هل استبعاد الأرقام فكرة جيدة (أو سيئة)
تم التعامل معه بالفعل:

julia> طباعة ("Páll"، 1.0، 1)
Páll1.01.2018
julia> سلسلة ("Páll" ، 1.0 ، 1)
"Páll1.01"

PallHaraldsson المشكلة هناك أن كلا من print و string يفعلون أكثر بكثير من مجرد التسلسل ، إنهم "يشددون" حججهم ... لست متأكدًا من أن هذا يجب أن يحدث _ ضمنيًا_ مع عامل تسلسل عام. لا يحدث ذلك مع * حاليًا عند استخدامه كمعامل لسلسلة السلسلة أيضًا.
راجع للشغل ، أنت بحاجة إلى معرفة كيفية اقتباس الأشياء هنا باستخدام Markdown ... أظهر لي الأشخاص هنا كيف أستخدم علامات الاقتباس الثلاثية متبوعة بجوليا حول مقتطفات رمز جوليا ، ووضع سطر فارغ بعد اقتباس شخص ما بـ > وتعليقك.
أي شيء مثل:

@ scottjones :

لم أقل أبدًا أنني أريد استخدام هذا العامل في الحجم

هل من الجيد (أو السيئ) استبعاد الأرقام - التي تم التعامل معها بالفعل:

julia> print("Páll", 1.0, 1)
Páll1.01
julia> string("Páll", 1.0, 1)
"Páll1.01"

ScottPJones ، للأسف لا يبدو أن الاقتباس يعمل عند الرد بواسطة
البريد الإلكتروني ، حتى لو قمت بالتعديل بعد الحقيقة (اختبار هذا هنا).

print("Hi GitHub!  Is this quoted")

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

في كلتا الحالتين ، باستخدام واجهة GitHub ، بدلاً من الرد بالبريد الإلكتروني ،
يساعد في كل من هذه الأشياء.

السبت، 13 يونيو 2015 في 05:24، سكوت P. جونز [email protected]
كتب:

PallHaraldsson https://github.com/PallHaraldsson المشكلة موجودة
أن كلا من الطباعة والسلسلة تؤديان أكثر بكثير من مجرد التسلسل ، فهم
"شددوا" حججهم ... لست متأكدًا من أن ذلك يجب أن يحدث
_ ضمنيًا_ مع عامل سلسلة عام. لا يحدث ذلك
مع * حاليًا عند استخدامها كمعامل لسلسلة السلسلة أيضًا.
راجع للشغل ، عليك أن تتعلم كيفية اقتباس الأشياء هنا مع Markdown ...
أظهر لي هنا كيف أستخدم اقتباسات ثلاثية متبوعة بجوليا
حول مقتطفات كود جوليا ، ووضع سطر فارغ بعد اقتباس شخص ما
مع> وتعليقك.
أي شيء مثل:

@ scottjones https://github.com/scottjones :

لم أقل أبدًا أنني أريد استخدام هذا العامل في الحجم

هل من الجيد (أو السيئ) استبعاد الأرقام - الموجودة بالفعل
معالجة:

julia> طباعة ("Páll"، 1.0، 1)
Páll1.01.2018
julia> سلسلة ("Páll"، 1.0، 1) "Páll1.01"

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

آخ ... لم أكن أعرف أن PallHaraldsson كان يستجيب عبر البريد الإلكتروني ، ولم يكن هذا البريد الإلكتروني لديه هذه المشكلة (أستخدم تطبيق CodeHub عندما لا أكون على الكمبيوتر المحمول ... لكن ليس هذا).
نعم ، هذا هو سكوت جونز مختلف تمامًا ... ولا حتى سكوت أيه جونز الذي كان طالبًا في معهد ماساتشوستس للتكنولوجيا عندما كنت طالبًا جامعيًا ، والذي عاش أيضًا في أرلينغتون بعد ذلك!

لول ، نعم ، كان هذا محيرًا! لقد قابلت "نفسي" عدة مرات على مر السنين ، لذا فهذه ليست المرة الأولى التي يحدث فيها هذا النوع من الارتباك. :)

في صحتك،

سكوت

في 13 حزيران (يونيو) 2015 ، الساعة 11:37 صباحًا ، كتب سكوت ب. جونز < [email protected] [email protected] >:

آخ ... لم أكن أعلم أنPallHarald ssonhttps: //github.com/PallHaraldsson كان يستجيب عبر البريد الإلكتروني ، ولم يكن هذا البريد الإلكتروني لديه هذه المشكلة (أستخدم تطبيق CodeHub عندما لا أكون على الكمبيوتر المحمول الخاص بي ... لديها مشاكلها الخاصة ، ولكن ليس ذلك).
نعم ، هذا هو سكوت جونز مختلف تمامًا ... ولا حتى سكوت أيه جونز الذي كان طالبًا في معهد ماساتشوستس للتكنولوجيا عندما كنت طالبًا جامعيًا ، والذي عاش أيضًا في أرلينغتون بعد ذلك!

-
يمكنك الرد على هذه الرسالة الإلكترونية مباشرةً أو عرضها على Gi tHubhttps: //github.com/JuliaLang/julia/issues/11030#issuecomment -111727642.

لما يستحق ، أنا حقًا أحب * كتسلسل سلسلة. أولاً ، إنه يطابق الترميز المستخدم في قابلية الحوسبة والتعقيد واللغات بواسطة Davis et al. كما أنه يمنحك تسلسلًا متجاورًا مجانًا (ليس هذا ما رأيته من قبل ، إنه أنيق فقط). أجد نفسي أستخدم * طوال الوقت ، ورأيته مستخدمًا في الكثير من الأماكن الأخرى ، لذلك أعتقد أن حجم التغيير في الكود لهذا الإهمال سيكون هائلاً ، مع (على الأقل IMHO) فائدة قليلة.

أعتقد أننا يجب أن نحتفظ فقط بـ * للسلاسل ، ولكن ربما نضيف ++ لاحقًا كمعامل تسلسل عام (والذي من شأنه أن يدعم السلاسل بالإضافة إلى الأشياء الأخرى).

قد نضيف ++ كمعامل تسلسل عام في المستقبل ، ولكن يبدو أن التخلص من * و ^ للسلاسل لن يحدث. سأقول إنني لم أعد مهتمًا بشكل خاص بـ "المعاقب" على * ، كما أنني لم أعد أعتقد في الواقع أن هذا يعد عقابًا بعد الآن - في الجبر المجرد ، الضرب (يمثله * أو تجاور) غالبًا كعملية جماعية غير تبادلية على أشياء ليست أرقامًا. كانت المشكلات الرئيسية هنا من حقيقة أن عملية Char <: Number ولكن العملية * لـ Char كانت غير متوافقة مع * لـ Number . الآن بما أن Char ليس نوعًا فرعيًا من Nubmer ، لم تعد هذه مشكلة.

سأحتفظ ب * لسلسلة السلسلة للسبب الأصلي.

هذا ما تقوله ويكيبيديا عن التعبيرات النمطية كعمليات جبرية:

بالنظر إلى التعبيرات النمطية R و S ، يتم تعريف العمليات التالية عليها لإنتاج التعبيرات العادية:
(التسلسل) تشير RS إلى مجموعة السلاسل التي يمكن الحصول عليها من خلال ربط سلسلة في R وسلسلة في S. على سبيل المثال ، {"ab"، "c"} {"d"، "ef"} = {"abd "،" abef "،" cd "،" cef "}.
(بالتناوب) R | تشير S إلى اتحاد المجموعات الموصوفة بواسطة R و S. على سبيل المثال ، إذا وصفت R {"ab" و "c"} ووصف S {"ab" و "d" و "ef"} والتعبير R | يصف S {"ab"، "c"، "d"، "ef"}.
(Kleene star) يشير R * إلى أصغر مجموعة شاملة موصوفة بواسطة R والتي تحتوي على ε ويتم إغلاقها تحت سلسلة السلسلة. هذه هي مجموعة كل السلاسل التي يمكن تكوينها من خلال ربط أي عدد محدد (بما في ذلك الصفر) من السلاسل من المجموعة الموصوفة بواسطة R. على سبيل المثال ، {"0" ، "1"} * هي مجموعة كل السلاسل الثنائية المحدودة ( بما في ذلك السلسلة الفارغة) و {"ab" و "c"} * = {ε و "ab" و "c" و "abab" و "abc" و "cab" و "cc" و "ababab" و " abcab "،…}.

في الجبر الخطي ، يوجد عامل تشغيل أحادي ، العامل المساعد ، غالبًا ما يُشار إليه بـ * . في Julia بالإضافة إلى Matlab ، يتم إعطاء عامل التشغيل المساعد من خلال عرض أسعار واحد ( ' ) ، نظرًا لأن * يُستخدم عمومًا للتكرار. لذلك أقترح أن تكون عوامل تشغيل السلسلة في جوليا ( *,+,' ) للتسلسل ، والتناوب ، ونجم Kleene على التوالي.

كما أشار stevengj ، فإن الجدل بين + ومنافسيه يدور حول التقاليد وليس الصواب. وقد أثبتت البيانات + كمعامل لسلسلة السلسلة هو أكثر الاصطلاحات المقبولة على نطاق واسع في عالم البرمجة (C ++ / C # / Java / Python / Javascript وغيرها الكثير). ومن الواضح أن جميع الخيارات الأخرى أقل شيوعًا ، سواء أحبها البعض أم لا.

ثم السبب الرئيسي الذي يمكنني التفكير فيه بشأن الاحتفاظ بـ * هو أن إهماله سيؤدي إلى كسر الكود الحالي مثل “abc” * “efg” . هل يمكن لأي شخص أن يشرح ما هو + سيتعطل إذا تم استخدامه كمعامل سلسلة في Julia ، لمساعدتي على فهم الخلفية بشكل أفضل؟ (أنا أفهم أن تسلسل السلسلة ليس عملية تبادلية.)

لن ينكسر أي شيء ، وإذا كنت تريده حقًا ، يمكنك تحديد + للقيام بذلك. ومع ذلك ، فهي مجرد رياضيات سيئة. في الجبر ، دائمًا ما يكون + عملية تبادلية - وسلسلة السلسلة ليست تبادلية. يمكنك أن ترى بعض الالتباس الذي يسببه هذا لأن + لا يؤدي إلى طريقة طبيعية لتكرار السلاسل. هل تكتب "hi" * 5 أو 5 * "hi" ؟ لا أحد له معنى حقًا. قارن هذا بـ * للتسلسل حيث من الواضح أنه يجب عليك كتابة "hi"^5 . في أي حال، على الرغم من أننا قد يعرض ++ لسلسلة (بما في ذلك سلاسل)، نحن لا تنوي استخدام + لسلسلة سلسلة بغض النظر عن عدد اللغات قد اختاروا هذا النحو.

أقترح استخدام . لسلسلة سلسلة تتطابق مع PHP. مع getfield القابل للتحميل الزائد ، سيكون قابلاً للتنفيذ بشكل تافه:

getfield(x::String, y::String) = string(x, y)
"a"."b"."c"

يمكننا استخدام .. للتكرار " "..5

تضمين التغريدة
شكرا على الشرح! لقد أصبحت أكثر منطقية بشأن الخلفية الآن.

(1) إذا تم استخدام * لتسلسل السلسلة ، فإن ^ سيكون عملية منطقية وطبيعية لتكرار السلسلة.
(2) إذا تم استخدام + لسلسلة السلسلة ، فسيكون * النتيجة المنطقية لتكرار السلسلة.
بالنسبة للخيار (1) ، أوافق على أن ^ عامل بديهي لتكرار السلسلة. بالنسبة إلى (2) ، حتى * هي النتيجة المنطقية ، فقد لا تكون بديهية بما يكفي (مثل "hi" * 3 == "hihihi").

هل تكتب "hi" * 5 أو 5 * "hi" ؟

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

وأدركت أن إنشاء مشغلين جدد أمر مثير للجدل / خطير حقًا ، في حين أن دعم المزيد من واجهات برمجة التطبيقات أمر مرحب به عادةً :)

تحرير: تم العثور على سلسلة رسائل أخرى قدمت / و \ للسلاسل. وهذا يساعدني على فهم أفضل لسبب اختيار * لتسلسل السلسلة.