Data.table: التكامل مع magrittr

DT[, a := some.function(a)]

يعمل بشكل جيد

لكن إيمهو

Complicated_data_table_variable_name[, a_very_very_very_very_long_variable_name := some.function(a_very_very_very_very_long_variable_name)]

ليس جيدًا تمامًا. أحب فكرة إضافة وظيفة الراحة هذه.

ولكن ربما يكون %:>% أفضل من %<>% ؟

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

shortname <- "a_very_very_very_very_long_variable_name"
DT[, (shortname) := some.function(get(shortname))]

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

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

لأولئك منكم المشتركين في هذا الموضوع ، يرجى تجاهل التعليق الأخير (تم حذفه الآن). كانت سخيفة.

عند البناء من تعليق @ and3k ، أرى بعض القيمة لـ:

DT[, a %:=>% some.function]

أعتقد أن القراءة أفضل (مثل := و %>% معًا). إنها "غليون سعيد"؟ أنا معجب بالجهود المبذولة لتقليل تكرار الاسم المتغير ، كما هو مكتوب هنا: http://stackoverflow.com/a/10758086/403310

الجزء => من عامل التشغيل :=> له معنى إضافي ، ربما :=: ؟

DT[, a %:=:% some.function]

أو :=. الذي يُعيّن مباشرة كـ := متبوعًا بـ . تم تمريره إلى المرح

ما المعنى الإضافي الذي يمتلكه => ؟ > جميل لأنه ينقل تمرير LHS كوسيطة إلى RHS. وهذا هو سبب تغيير هادلي من %.% إلى %>% .

كنت أفهم أن جزءًا كبيرًا من الدافع للانتقال إلى %>% هو أنه من الأسهل بكثير الكتابة من %.% (أظن في كثير من الأحيان محاولة كتابة %.% من شأنه أن يؤدي بطريق الخطأ في %>% ).

أعني عامل التشغيل الأكبر أو المتساوي.
وماذا عن %:>% ؟ سيكون هذا أسهل في الكتابة من %:=>% أو %:=:% .
و 3 k ذكر ذلك أعلاه بالفعل.

تصويتي هو %:>% أو :> .

يوجد % فقط لأن R لا يسمح بعوامل infix في البرية ، أليس كذلك؟ قد يحافظ أيضًا على المشغلين داخل DT[] البخل.

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

شكرًا ، %:>% يبدو جيدًا بالنسبة لي.

مجرد فضول ، لماذا لا يتم تحليل :> بينما يتم تحليل := داخل [....] ؟ := غير صالح لبناء جملة R أيضًا ، أليس كذلك؟

@ my-R-help هو بناء جملة صالح ، راجع هذا لماذا: = مسموح به كمعامل infix؟

+1 أوافق على طلب ميزة OP واستخدام صيغة Magrittr. إنه الخيار الأفضل والأكثر وضوحًا لعدة أسباب.

• يستخدم الناس بالفعل DT بكثافة مع itmagrittr
• إن بناء جملة ماغريت موجود في كل مكان في هذه المرحلة ... وقد يحصل على مفتاح الاختصار rstudio الخاص به ... وأي اختيار نحوي آخر سينتهي على الأرجح بالارتباك.

أنا أشجعك بشدة على عدم المبالغة في التفكير في هذا FR من خلال تقديم عامل تشغيل جديد يكون اختياره هو اختيار Magrittr التعسفي ..

أنا أشجعك بشدة على عدم المبالغة في التفكير في هذا FR من خلال تقديم عامل تشغيل جديد يكون اختياره هو اختيار Magrittr التعسفي ..

ctbrown الاقتراح لمشغل الأنابيب الذي يقوم بشيء مختلف عن الفانيليا %>% من Magrittr ، وهي حزمة لديها أيضًا العديد من مشغلي الأنابيب الآخرين. طالما أنها لا تتعارض مع أي من هؤلاء ، ما هي المشكلة؟

أعتقد أن طلب FR الخاص بـ OP كان واضحًا بما فيه الكفاية ، أي
لاستخدام %<>% على وجه التحديد باعتباره أنبوب التوجيه والتعيين المدمجين
المشغل أو العامل. من المفترض أن هذا يرجع إلى أن magrittr يعرّف بالفعل %<>% لـ
هذا الغرض بالتحديد. نظرًا لأن ماغريت يبدو هو الأنبوب السائد
التنفيذ ويبدو أن العديد من الأشخاص يستخدمون٪ <>٪ وطلابي و
الزملاء بينهم. لا معنى لتقديم آخر
المشغل لنفس الغرض بالضبط. من المنطقي أكثر أن تختار أ
بناء جملة يتوافق مع ما تعرض له المجتمع أو تعرض له بالفعل
متبنى. انظر وجهة نظري حول الوجود في كل مكان.

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

يوم الخميس ، 27 أكتوبر 2016 الساعة 11:41 صباحًا ، franknarf1 [email protected]
كتب:

أنا أشجعك بشدة على عدم التفكير في هذا FR من خلال تقديم ملف
المشغل الذي كان اختياره هو اختيار Magrittr التعسفي ..

ctbrown https://github.com/ctbrown الاقتراح لمشغل الأنابيب
يفعل شيئًا مختلفًا عن الفانيليا٪>٪ من Magrittr ، أ
الحزمة التي لديها أيضًا العديد من مشغلي الأنابيب الآخرين. طالما أنها لا تفعل ذلك
تتعارض مع أي من هؤلاء ، ما هي المشكلة؟

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/Rdatatable/data.table/issues/1208#issuecomment -256732710 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AC5xaxIp36dTUCz9d5a5mU7CJUV6PaxCks5q4PBDgaJpZM4FSJR5
.

هل يتم تعيين %<>% بالرجوع إليه؟ إذا لم يكن الأمر كذلك ، فهم في الواقع _ لا _ يفعلون نفس الشيء بالضبط.

من الناحية الفنية ، أنت على صواب ، لا تقوم٪ <>٪ الخاصة بـ magrittr بتعيين مرجع ثانوي ،
لكن هذا خارج الموضوع. ضمن توقعات المستخدمين ، لا يوجد
اختلاف. التخصيص سواء كان المرجع الثانوي أو بالقيمة هو ملف
قضية التنفيذ ليست واجهة واحدة. اقترح البروتوكول الاختياري المعتمد
واجهة magrittr ولم تقترح بالضرورة التنفيذ.
رأيت الجدارة في اقتراح OP. انظر الأسباب أعلاه. انا لست
انظر إلى الأساس المنطقي في اعتماد شيء مثل '٪:>٪ or anything as arbitrary. The merit of this has not been articulated. The ٪ <>٪ `
عامل التشغيل موجود بالفعل ويتم الترويج له بنشاط بواسطة magrittr (المرتبة 12 على الأكثر
حزمة شعبية وفقًا لـ METACRAN.) بقدر أي شيء يبدو أن هذا
كن المعيار (داخل مجتمع R). الشيء الجميل في المتابعة
الممارسة المتبعة تقلل من ارتباك المستخدم والحاجة إلى
وثائق شاملة. تحصل على: "أوه ، هذا هو نفسه ماغريت ، أنا
تعرف على هذا الأنبوب الأمامي ويقوم بمهمة "، بدلاً من" ما هذا
غريب٪:>٪؟ هل هذا رمز جديد للمهرج؟ "

يوم الخميس ، 27 أكتوبر 2016 الساعة 2:18 مساءً ، Michael Chirico [email protected]
كتب:

هل٪ <>٪ يعين حسب المرجع؟ إذا لم يكن الأمر كذلك ، فهم في الحقيقة _ لا _ يفعلون
نفس الشيء بالضبط.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/Rdatatable/data.table/issues/1208#issuecomment -256772769 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AC5xa3ssE14PcamL2U9HlvCdfA8-7Iz8ks5q4RUagaJpZM4FSJR5
.

في حدود توقعات المستخدمين ، لا يوجد فرق.

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

"أسبابك أعلاه" لا تصمد معي. لا يتعارض تطبيق Magrittr بطريقة أو بأخرى مع مشغل أنابيب غير متداخل للقيام بشيء مميز ولكنه مرتبط. بالنسبة لي - وهذا مجرد انطباعي ، تمامًا مثل كل ما قلته هو لك - يبدو هذا متوافقًا تمامًا مع "الممارسة الراسخة" لـ magrittr (والتي أستخدمها تقريبًا بقدر ما أستخدم البيانات. ).

من الممكن تمامًا أن يتم تعيين الاستخدام في هذا السياق إلى كائنات متعددة (أعمدة) في وقت واحد ، وهو ما توافق بالتأكيد على أنه مختلف تمامًا عن %<>% ..؟ أعني

DT[, (cols) %:>% lapply(as.character) ]

وإلى جانب التعديل بالإحالة وربما تعديل العديد من الأشياء في وقت واحد ، لدينا حقيقة أننا نقوم بتعديل جزء من الشيء (جدول البيانات) ، والذي يختلف تمامًا عن %<>% .

على أي حال ، نظرًا لأن المطورين لم يظهروا أي علامة على القيام بهذه المهمة في أي وقت قريب (من خلال وضع علامة على هذا FR بأولوية أو معلم رئيسي) ، فماذا عن إعادة النظر في هذا إذا كان يتحرك بالفعل إلى الأمام؟

ctbrown _by-reference_ لا يختلف فقط في التنفيذ ، ويجب تمييزه عن وظائف _by-value_ في واجهة المستخدم. هذا هو بيت القصيد من وظائف set* و := عامل في data.table ، للتواصل بوضوح مع المستخدمين ما هو في الواقع يعدل مدخلات الوظيفة. من الصعب الحكم على معيار داخل مجتمع R بعد هذه الفترة القصيرة ، تتم كتابة طلبات R لعقود من الزمن ومن السابق لأوانه الحكم على "معيار جديد" ، وهو في النهاية AFAIK حول تنسيق الكود (التداخل / إلغاء التداخل) ، أرجوا أن تصحح لي إذا كنت مخطئا. كما قلت عدة مرات قبل أن أجد أنابيب magrittr رائعة حقًا للاستخدام التفاعلي عندما أرغب في تقديم جزء كبير من الكود ، ولكن ليس ضروريًا حقًا عند كتابة حزم R حيث يكون التركيز الرئيسي هو الوظيفة. IMO إذا كان هناك شيء يمكن تعديله في مكانه ، فيجب أن يكون له عامل تشغيل مختلف عن ذلك الذي لن يتم تعديله في المكان.

@ franknarf1 ،

أولاً ، لم يكن هناك أي ادعاء يتعلق بالتحدث نيابة عن مستخدمي ALL R. هذا تأكيد سخيف. كانت الإشارة إلى "توقعات المستخدمين" تخصني ، ويفترض أن OP's والعديد من طلابي الذين جربوا بالفعل dt[ , var %<>% ... ] ويسألون لماذا لا يعمل. علاوة على ذلك ، فإن إجبار المستخدمين على "التعرف على الاختلاف أثناء تعلمهم استخدام data.table" يعد أمرًا خطيرًا إذا كان DT يمكن أن يعمل كما قد يتوقع المرء. هذا يؤدي إلى تصميم البرامج السيئ.

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

بالإضافة إلى ذلك،

• يمكن أيضًا تنفيذ %<>% للتعامل مع الحجج المتعددة وسيظل منطقيًا تمامًا ضمن السياق مع الالتزام بتوقعات OP وتوقعات الآخرين. لم يحدد اقتراح OP حقًا ما إذا كان يريد تعديل حجج متعددة.
• سواء كنت تقوم بالتعديل جزئيًا أو كليًا ، فهي عبارة عن nit - فأنت تقوم دائمًا بتعديل جزء من شيء ما ، أي بيئة.
• يعتبر إجراء أو تقاعس المطورين عن رد فعل الآخرين ولا يتعلق بمزايا اقتراح / طلب OP. هذه حجة ضعيفة إلى حد ما من أجل السلطة التي لم تقدم حقًا رأيًا في أي من الاتجاهين.

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

كل شخص يستخدم data.table يجب أن يتعلم في وقت ما أو آخر حول استخدام := (ربما بعد وقت قصير جدًا من البدء). أوه لا ، عصبي! لماذا ليس <- أو = ؟

الإجابة على هذا من أول الأشياء التي يتعلمها أي شخص حول استخدام data.table . إنه موضوع المقالة القصيرة الثانية للمقدمة .

%<>% مقابل %<:>% (أو أيًا كان ما قد ينتهي به الأمر) هو نفس التمييز تمامًا. لذلك تم تغطية الجواب بواسطة مات هنا:

http://stackoverflow.com/questions/7033106/why-has-data-table-defined-rather-than-overloading

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

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

فيما يتعلق بالوظائف set* ، قد تشير هذه إلى مرجع ، لكن من الغريب ملاحظة أنه لم يتم تسميتها set*ByRef والتي كان من الممكن أن تكون أكثر وضوحًا. يبدو أن الوظائف موجودة في الغالب لإجراء عملية فعالة ، وتحويل DF إلى DT وضبط مفتاح. يبدو أنه يمكن اعتبارها للإشارة إلى عملية مرجعية ثانوية.

بالنسبة إلى := ، أعتقد أنني أذكر mattdowle الذي سئل في := بدلاً من = . IIRC ، قال إنه لا يمكنه استخدام = و := كان متاحًا. IIRC ، كان يفضل استخدام = .

WRT ، المعيار في مجتمع R - يشتهر بافتقاره للمعايير - إن Magrittr جيد كما هو: يتم استخدامه ومناقشته في كل مكان. يقترح البروتوكول الاختياري إمكانية التشغيل البيني معه سيكون ميزة رائعة. أنا موافق. إذا كانت لديك أي شكوك حول هذا الأمر ، فقم بإلقاء نظرة على

تندرج الحجة التي تقدمها تحت: "DT يختلف عن magrittr لأن الإسناد هو عن طريق المرجع ، لذا فإن بناء الجملة مختلف". الذي لا يزال الجواب: التنفيذ مختلف ، صحيح. ولكن يجب أن تكون الواجهة هي نفسها لأنها نفس العمليات بشكل فعال لمعظم المستخدمين ، وتتوافق مع توقعات المستخدم والتي يمكن استنتاج عمليتها الحقيقية من السياق.

كان بإمكان

أنا سعيد لأنه لم يفعل. يُترجم القفل في "وظيفية بحتة" ببساطة إلى إسقاط بعض الميزات المهمة التي يمكن للمستخدم الآن استخدامها لكتابة رمز أسرع وأكثر كفاءة في الذاكرة. لديّ مشاريع (مثل التشكل ) والتي سيكون من غير العملي استخدامها في إطار عمل "وظيفي بحت".

تضمين التغريدة
انا موافق تماما. لكننا بدأنا في الابتعاد عن الاقتراح الأصلي إلى مزايا DT.

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

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

• اختيار المشغلين تعسفي. حاول مات داول عدة مرات قبل := . لقد جرب أولاً الأشياء الواضحة التي كانت ستتماشى أكثر مع المعيار أولاً: <- ، <<- ، := تم العثور عليها للتو لأنها كانت متاحة والبدائل التي تم إنشاؤها لبناء الجملة القبيح . كان من الواضح أنه يفضل المشغلين الحاليين على تعريف واحد جديد.
• سيعرف المستخدم أنه يفهم من السياق أن التعيين يحدث إسناد مرجعي ، لكن لا يهم كيف يحدث.
• إلخ.

أولاً ، لم يكن هناك أي ادعاء يتعلق بالتحدث نيابة عن مستخدمي ALL R. هذا تأكيد سخيف. كانت الإشارة إلى "توقعات المستخدمين" تخصني ، ويفترض أن OP's والعديد من طلابي

إن الإشارة إلى "المستخدمين" عندما تقصد نفسك حقًا هو أداة خطابية تؤدي إلى نتائج عكسية وتشتيت الانتباه. ربما لاحظت أيضًا أن OP قال " %:>% يبدو جيدًا بالنسبة لي."

يعتبر إجراء أو تقاعس المطورين عن رد فعل الآخرين ولا يتعلق بمزايا اقتراح / طلب OP. هذه حجة ضعيفة إلى حد ما من أجل السلطة التي لم تقدم حقًا رأيًا في أي من الاتجاهين.

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

بقدر ما تذهب الحجج الموضوعية:

• أعتقد أنه من غير المحتمل جدًا أن تستخدم magrittr %<>% لتعديل كائنات متعددة على LHS ، مثل list(x, y) %<>% log ، وهو ما يماثل DT[, c("x", "y") := lappy(.SD, log), .SDcols = c("x","y")] .
• وبالمثل ، فإن تلميحك هو أول تلميح رأيته أنه يمكن استخدام %<>% لتعديل جزء من كائن مثل x[ 2:4 ] %<>% log ، وهو مشابه لـ DT[ 2:4, x := log(x) ] .

أتطلع إلى رؤية FRs لهذه الميزات على https://github.com/tidyverse/magrittr/issues وآمل أن يمروا ، لأنني سأستخدم هذه الوظيفة بالتأكيد.

@ franknarf1 ،

نقطة مأخوذة ؛ لقد فاتني أن OP قال أن "٪:>٪ تبدو جيدة بالنسبة لي."

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

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

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

بالنسبة للحجج الموضوعية ، يبدو أنهم يدافعون عن زيادة وظائف magrittr أكثر من العنوان المقترح %<>% syntax. (في ملاحظة شخصية ، أتفق معك في أنه يجب على أعضاء Magrittr تنفيذ اقتراحاتك ، لا سيما الأولى. لست متأكدًا مما إذا كنت سأستخدم الثانية كثيرًا.) بغض النظر عن الاقتراح المقدم إلى أعضاء magrittr ، فلا يوجد شيء غير متسق من DT من اعتماد تحسيناتك واستخدام عامل التشغيل magrittr %<>% . وما زلت بحاجة إلى قراءة حجة مقنعة لتفوق %:=% (أو بديل) على %<>% .

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

حجة لصالح %:>% :

• أن تخصيص توجيه DT سوف ينفذ التخصيص حسب المرجع. يجب تمييز هذا في المشغلين لأنه يوضح للمستخدمين كيفية تنفيذ التخصيص. قد يؤدي هذا إلى تجنب الارتباك غير الضروري.
• قد تكون هناك بعض الحالات (مثل التخصيص المتعدد ، والتعيين الجزئي) حيث قد تضيف DT ميزات إضافية لم يتم دعمها (حتى الآن) بواسطة magrittr. وبالتالي ، من الأفضل التمييز بين العمليات.
• %<>% تعسفي مثل أي خيار آخر ، %:>% يشبه DT.

الحجج لصالح %<>% :

• لقد نفذت شركة magrittr بالفعل مشغلي تخصيص الأنابيب إلى الأمام ، وهي مستخدمة على نطاق واسع وبقدر ما يبدو أن أي شيء يعتبر معيارًا. اتباع معيار ، مهما كان ضمنيًا ، يعني أنه يتم تقليل أعباء مطوري DT في مقدار التوثيق والشرح الضروري لوصف المشغل الجديد.
• يستخدم المستخدمون بالفعل magrittr مع DT في RHS := . علاوة على ذلك ، تشير بعض الأدلة إلى أن المستخدمين يتوقعون / حاولوا استخدام صيغة magrittr %<>% . اعتماده سيتوافق مع توقعات هؤلاء المستخدمين.
• سيكون نقل الكود من dplyr / magrittr <--> DT أبسط وأسهل ، لأنه في بعض الحالات قد يكون بناء الجملة متشابهًا.
• تؤدي زيادة عدد المشغلين إلى تعقيد إضافي. في هذه الحالة ، لا داعي للتعقيد لأن المشغلين يجب أن يحددوا الإجراء ويحتاجون بالضرورة إلى تحديد التنفيذ - هذه هي الطريقة التي تعمل بها الطرق العامة.
• %:>% تعسفي مثل %<>% .

سيكون نقل الكود من dplyr / magrittr <--> DT أبسط وأسهل ، لأنه في بعض الحالات قد يكون بناء الجملة متشابهًا.

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

هذه هي نفس المشكلة عند نسخ data.table مقابل نسخ data.frame (dt2 <- dt) ، فجأة تخدش رأسك حول سبب تحديث dt الأصلي الخاص بك عندما كنت تعمل فقط في الثانية.

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

tensibai،

مفهوم. وبالتالي فإن "قد يكون" جزءًا من التأكيد.

في يوم الأربعاء 2 نوفمبر 2016 الساعة 1:32 صباحًا ، كتب Tensibai [email protected] :

سيكون نقل الكود من dplyr / magrittr <--> DT أبسط وأسهل ،
لأنه في بعض الحالات قد تكون البنية متشابهة.

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

هذه هي نفس المشكلة عند نسخ data.table مقابل نسخ data.frame
(dt2 <- dt) ، فجأة تخدش رأسك حول سبب وجود dt الأصلي
تم تحديثه عندما كنت تعمل فقط في الثانية.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/Rdatatable/data.table/issues/1208#issuecomment -257801913 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AC5xaxyWXkh4C7i5-GtjMFiQ0AY2L5BLks5q6EqIgaJpZM4FSJR5
.

شكرا على كل تعليقاتك وردود الفعل.

مجرد شيء بسيط (ربما أفتقد شيئًا ما): هل يحدث فرقًا في هذه الحالة المحددة سواء كان التعيين بالإشارة أو بالقيمة؟ ما نريد القيام به هو تحديث عمود (أو عدة أعمدة) داخل data.table. يعرف المستخدم أنه سيتم الكتابة فوق العمود القديم في كلتا الحالتين. ليس هناك مجال لسوء الفهم ، أليس كذلك؟ في المقابل ، يختلف هذا كثيرًا عن DTa=DTb مقابل DTa=copy(DTb) (وهو ما لا أتحدث عنه في طلب الميزة هذا) ، حيث نتعامل مع data.table نفسه ، وأين إنه يحدث فرقًا سواء قمنا بتعيينه بالإشارة أو بالقيمة.

@ my-R-help ،

حدسك صحيح.

أنها لا تحدث فرقا للمستخدم كيفية هذه العملية _implemented_. النتائج هي نفسها من منظور المستخدمين - أعيد تعيين القيم الموجودة في العمود. كانت هناك بعض الحجج التي تنص على أنه يجب أن يكون هناك بعض التمايز ، ولم يكن هناك تفسير مقنع لـ _لماذا_.

اقتراحك باعتماد بناء الجملة %<>% اقتراح سليم. يفترض بشكل صحيح أن التنفيذ يختلف عن _interface_ وبما أن هناك ممارسة شائعة وموجودة لإجراء العملية ، فيجب اعتمادها. هذا ، في الواقع ، يتبع ممارسات تصميم البرامج الجيدة.

(كملاحظة جانبية ، شعرت بالإحباط قليلاً عندما قلت ، "شكرًا (SIC) ،٪:>٪ تبدو جيدة بالنسبة لي." ولم أدافع بقوة أكبر عن الحدس الأولي والاقتراح. على أي حال ، شكرًا على الاقتراح. إنه رائع سواء تم تنفيذه في DT أم لا ،)

شكرا لردك كريستوفر.

فقط للتوضيح ، لدي شخصيًا تفضيل لـ %<>% لأنه أكثر اتساقًا مع magrittr ويبدو أن الكثير من الناس يستخدمونه. ومع ذلك ، إذا كان مطورو data.table يفضلون مشغلًا آخر (مثل %:>% ) ، فيمكنني أيضًا التعايش مع ذلك (على الرغم من أنني شخصياً أفضل طريقة magrittr).

ربما كان علي أن أصيغها بهذه الطريقة. آسف إذا تسبب في أي لبس.

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

لا فرق للمستخدم في كيفية تنفيذ هذه العملية. النتائج هي نفسها من منظور المستخدمين - أعيد تعيين القيم الموجودة في العمود.

ما زلت أشعر أن هناك مساحة لبندقية القدم مع الصلات.

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

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

_المكافأة_ عند البحث عن عامل التشغيل ستنتهي في صفحة DT تشرح المحاذير / القيود بلا شك بدلاً من وجود خيارين في المساعدة.

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

الاعتراض الرئيسي هو: أن شخصًا ما يفكر في أن %<>% سيتصرف بنفس الطريقة التي يتصرف بها خارج DT سوف يصبح مجنونًا عندما يخدش أعمدة DT الخاصة به عندما لا يكون ذلك مقصودًا.

TL ؛ DR: البرمجة ليست تجربة مستخدم ، يجب أن تكون محددًا بشأن ما تريد ، وبالتالي لا ينبغي أن تحدث إعادة استخدام الأسماء المعروفة.

Tensibai ،

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

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

بالنسبة إلى:

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

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

شخص. يتحدث ()
"مرحبا بالعالم"
كلب. يتحدث ()
"اللحمة"

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

الاقتراح بأن:

أنا لا أوافق بشدة على أنه لا ينبغي للمبرمج أن يهتم بالتنفيذ وراء الوظيفة.

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

مكافأة البحث عن عامل التشغيل ستنتهي في صفحة DT تشرح محاذيرها / قيودها بلا شك بدلاً من وجود خيارين في المساعدة.

هذه ليست مكافأة ، ولكنها مسؤولية من خلال أ) إدخال الارتباك (كيف يختلف هذا عن حزم Magrittr الشائعة جدًا ، تمامًا؟) و (ب) خلق الحاجة إلى وثائق إضافية غير ضرورية في المقام الأول. إذا كانت صيغة magrittr ، يمكن لمطوري DT أن يقولوا: "اذهب إلى هناك واقرأ هناك مستندات و vignette ؛ يدعم DT ما يفعلونه هناك." هذا التعاون والاقتراض المتقاطع يرفع قيمة DT و magrittr والنظام البيئي R. )

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

للتلخيص ، حتى يمكن حل المشكلة في النهاية.

كل ما نحتاجه هو التعامل مع الترجمة التالية.

DT[, a %<:>% fun] ## or "%:>%"

DT[, a := fun(a)]

هل هذا صحيح؟

كيف يجب أن يتصرف إذا لم يكن a رمزًا ولكنه متغير حرف؟

DT[, "a" %<:>% fun]

DT[, "a" := fun(a)]   ## this?
DT[, "a" := fun("a")] ## or this?

ماذا لو لم يكن طوله 1؟

DT[, c("a","b") %<:>% fun]

DT[, c("a","b") %<:>% fun(a, b)]
DT[, c("a","b") %<:>% fun("a","b")]
DT[, c("a","b") %<:>% lapply(list(a, b), fun)]
DT[, c("a","b") %<:>% lapply(c("a", "b"), fun)]

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