Data.table: المقالات القصيرة

أقل ما يجب ذكره هو fread .
النقاط أعلاه مرتبطة بشكل أساسي بتحويل البيانات ، fread هو أكثر من استخراج البيانات لذلك قد يتم تخطيها في هذه المقالة القصيرة ، ومع ذلك فمن الجدير بالذكر IMO هذه القدرات data.table .

تحرير: أي واحد ستستخدمه: Rnw أم Rmd؟

متفق عليه ومحدث.

أشعر بالفضول لمعرفة ما الذي يجعل الزكام أسرع من قول tapply . جزء واحد من الإجابة هو gforce ، ولكن ماذا عن الوظائف المكتوبة من قبل المستخدم؟ لم أجد أي شيء عن هذا. هناك منشور لطيف عن الباندا: http://wesmckinney.com/blog/؟p=489
يمكن للمرء حتى مقارنتها بـ sapply . على سبيل المثال ، افترض أنني بدأت من قائمة النواقل. هل يستحق الأمر إلحاق جميع المتجهات في عمود واحد في جدول البيانات واستخدام by بدلاً من sapply ؟

@ matthieugomez سؤال مثير للاهتمام! سيكون من الجيد تغطية هذا أيضًا. إبقاء م القادمة :-).

سأكون مهتمًا بمعرفة معلومات حول IDateTime وبعض حالات الاستخدام الخاصة بها.

تم تحديث gsee .

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

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

من المحتمل أن يكون هناك الكثير من العناصر الأخرى الموجودة في SO والتي يمكن تحريرها في مجموعة بسيطة من الأسئلة والأجوبة.

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

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

شكرا لك مرة أخرى.

مزيد من الامتداد لفكرة صفحة wiki: قد تكون ارتباطات الأسئلة الشائعة وأجزاء التعليمات البرمجية (المتقدمة) المدرجة في http://www.ats.ucla.edu/stat/r/ مصدرًا مفيدًا لمقارنة المهام التقليدية في R بالبيانات .table way. فعلت شيئًا كهذا في منشور مدونة (http://vijaylulla.com/wp/2014/11/12/grouping-in-r-using-data-table/) لعرضه على زميلي. آسف للترويج الذاتي وقح.

لقد انتهيت من _Introduction to data.table_ vignette (انظر الرابط في الأعلى). سيكون من الرائع معرفة رأيك.

بفضل jangorecki و brodieG للحصول على ردود فعل رائعة ، وبالطبع mattdowle :-).

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

في قسم .SD تكتب "تلك المجموعة" ولكن قد يكون من الواضح أكثر أن تقول "تلك المجموعة محددة باستخدام by ". يتم ذلك أيضًا بعد قليل.

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

مرة أخرى ، هذه مجرد اقتراحات. عملك الجاد (ومات) هو موضع تقدير كبير.

يوم السبت ، 17 كانون الثاني (يناير) 2015 الساعة 6:22 مساءً ، Mark Danese [email protected]
كتب:

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

شكرا لك.

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

أوه المفاجئة! نقطة عظيمة. يجب أن أضيف "النظام (..)" في البداية ، و
سيضيف إلى الملخص أيضًا.

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

الحق ، سوف تفعل.

ويمكنك الارتباط بها لاحقًا.

هذا ، لست متأكدًا .. حيث من المفترض أن يتم دفعها إلى CRAN ، وكذلك
على WIKI ..

في قسم SD. تكتب "تلك المجموعة" ولكن قد يكون الأمر أكثر وضوحًا
قل "تلك المجموعة المحددة باستخدام". يتم ذلك أيضًا بعد ذلك بقليل
حسنا.

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

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

أعتقد أنك فاتتك. يقع أسفل اقتباس الكتلة مباشرةً حيث توجد .SD
أوضح (في القسم 2 هـ). وهو يشرح بالضبط ما ذكرته هنا ...

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

صحيح .. هذا سبب عدم إدخال رموز خاصة أخرى.

مرة أخرى ، هذه مجرد اقتراحات. عملك الشاق (ومات) عظيم
محل تقدير.

اقتراحات رائعة. سوف أكتب مرة أخرى بمجرد تحميل المقالات القصيرة الأخرى.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/Rdatatable/data.table/issues/944#issuecomment -70375167
.

هذا ، لست متأكدًا .. حيث من المفترض أن يتم دفعها إلى CRAN ، وكذلك
على WIKI ..

AFAIK عند دفع الحزمة إلى CRAN التي تتضمن Rmd في دليل vignettes سيتم بناؤها تلقائيًا للتحقق مما إذا كان إنشاء المقالة القصيرة قد نجح ، لكن الكود المصدري في CRAN سيحتوي على نقوش صغيرة (html) تم إنشاؤها بالفعل بواسطة أنت ، وليس الشخص من CRAN build / check.
يعد CRAN مكانًا جيدًا للمقالات القصيرة كما هو الحال بالنسبة للعديد من المستخدمين ، فهو المكان الأول للبحث عن المستندات / البرامج التعليمية ، لذلك أعتقد أنه من المفيد الحصول عليها في CRAN.

ويمكنك الارتباط بها لاحقًا.

هذا ، لست متأكدًا .. حيث من المفترض أن يتم دفعها إلى CRAN ، وكذلك على WIKI ..

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

تم التحديث باستخدام المصغر _Reference Semantics_.

شكرا مرة أخرى لفعل كل هذا.

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

أخيرًا ، قد يكون إدراج المقالات القصيرة "المفيدة" في قائمة المقالات الكاملة مفيدًا للموضوعات التي لا تريد تضمينها في المقالة القصيرة.

فقط بعض الأفكار العشوائية.

فكرتان:

• رابط إلى المقالات القصيرة في الويكي
• في الدلالات المصغرة المرجعية ، أضف كيفية الاستخدام: = مع تعبير قائمة مقتبس (أو مجرد واجب مقتبس). ربما يستحق هذا المقالة القصيرة الخاصة به ، لأن NSE (التقييم غير القياسي) في data.table يسهل الاستخدام التفاعلي ولكنه يتطلب ذلك لاستخدام data.table في وظيفتك أو حزمتك ، يجب عليك الآن شيئًا عن الاقتباس والتقييم والاستبدال والأصدقاء. ربما فقط أضف شيئًا مثل dt [، do.call (": ="، Eval (my_quoted_list)] إلى المقالة القصيرة ثم قم بإنشاء المقالة القصيرة حول NSE وآثارها؟

شكرا.

1. هل رأيت هذا ؟
2. من المرجح أن يتم تغطية ذلك في المقالة القصيرة منفصلة. لكن لا توجد خطط بعد.

arunsrinivasan كلا ، لم أر ذلك ، رائع! إشارة مرجعية أخرى

تم التحديث باستخدام _Keys ومجموعة فرعية تعتمد على البحث الثنائي السريع_ المقالة القصيرة.

لطيف جدا. أنا أحب هذه المقالات القصيرة. فقط بعض التعليقات السريعة للنظر فيها.

ما هو الغرض من الاستيلاء على أسماء الصفوف إذا لم يتم استخدامها؟ أم أنها تستخدم من قبل العوامل الخاصة في j (مثل .N ، .I ، إلخ)؟ أعتقد أنها مستخدمة بواسطة data.table ، لكن ليس فقط كمؤشرات. لطالما كنت مرتبكًا من الغرض من فرض أسماء الصفوف المرقمة.

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

هل يجب نقل جميع المفاتيح؟ حتى عدد (عدد صحيح)؟ هل يمكنك استخدام رقم كمفتاح؟ هل هناك أشياء يجب الانتباه لها؟

ماذا لو كان عمودك الرئيسي يحتوي على زمالة المدمنين المجهولين فيه؟ هل يمكنك البحث عن هؤلاء واستبدالهم (كما فعلت في مثالك حيث استبدلت 24 بـ 0؟

قد يكون من المفيد توضيح أن keyby ينطبق على _output_ data.table ( ans في مثالك) وليس بيانات الإدخال ( flights في المثال الخاص بك).

هل يمكنك تمرير ناقل إلى المفتاح؟ بمعنى آخر ، هل يمكنك إنشاء airport <- c("LGA", "JFK", "EWR") واستخدام airport مباشرة في i في المثال الخاص بك بالقرب من الأسفل؟ قد يساعد ذلك في إعداد فكرة تمرير جدول بيانات مختلف للدمج.

خطأ مطبعي في "المقابلة" ("المطابقة"). إحدى علامات التجزئة الخلفية مفقودة في قسم المسح المتجه حيث تكتب "يتم الحصول على مؤشرات الصف المقابلة للأصل ==" LGA "والرقم ==" TPA "` باستخدام مجموعة فرعية تعتمد على المفتاح. "

markdanese بخصوص

لماذا استخدام فريد في المفتاح الأول عند الوصول إلى المفتاح الثاني فقط؟

flights[.(unique(origin), "MIA")]

لست متأكدًا مما إذا كنت تطلب اقتراح تفسير أفضل أو أنك لست على دراية باستخدام أكثر تعقيدًا لمفتاح أعمدة متعددة.
لا يمكنك ببساطة استخدام البحث الثنائي على dest عندما يكون مفتاحك c(origin, dest) ، يجب أن يكون لديك c(dest, origin) لاستخدام البحث الثنائي على dest . استخدام .(unique(origin), "MIA") يستخدم البحث الثنائي ، من خلال توفير جميع القيم المتاحة للعمود الأول في المفتاح ثم القيم الانتقائية للعمود الثاني.
لقد قمت بعمل امتداد لاستخدام أعمدة انتقائية فقط من المفتاح. قد يساعدك أيضًا النظر إلى المثال البسيط في الفهم. الامتداد الخاص بي ليس جاهزًا ليكون PR إلى data.table master نظرًا لأن استخدام الذاكرة لا يتسع بقدر ما يمكن إذا تم تطويره باستخدام وظائف data.table الداخلية / مدمج مع مفتاح data.table الثانوي.

هل يمكنك استخدام رقم كمفتاح؟

يمكنك استخدام الأرقام كمفتاح ، فهي مذكورة في قسم Keys and their properties .

هل هناك أشياء يجب الانتباه لها؟

لست متأكدًا ولكن setNumericRounding يؤثر على المفتاح الرقمي ، وقد يكون من الجدير بالذكر في المقالة القصيرة.

ماذا لو كان عمودك الرئيسي يحتوي على زمالة المدمنين المجهولين فيه؟ هل يمكنك البحث عن هؤلاء واستبدالهم

نعم ، تم تحسين is.na() لاستخدام البحث الثنائي. جرب data.table(a=c(1,NA_real_),b=c("a","b"),key="a")[.(NA_real_), .SD ,verbose=TRUE]

أيضًا إلى arunsrinivasan ، الخطأ المطبعي في:

ابحث عن القيم المطابقة في

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

يوم الجمعة ، 23 كانون الثاني (يناير) 2015 ، الساعة 8:48 مساءً ، Mark Danese [email protected]
كتب:

لطيف جدا. أنا أحب هذه المقالات القصيرة. فقط بعض التعليقات السريعة ل
الاعتبار.

ما هو الغرض من الاستيلاء على أسماء الصفوف إذا لم يتم استخدامها؟ أو هي
استخدموا من قبل المشغلين الخاصين في j (مثل .N ، .I ، إلخ)؟ اعتقد انهم
يتم استخدامها بواسطة data.table ، ولكن ليس فقط كمؤشرات. كنت دائما
يتم الخلط بينه وبين الغرض من فرض أسماء الصفوف المرقمة.

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

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

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

هل يجب نقل جميع المفاتيح؟ حتى عدد (عدد صحيح)؟ هل يمكنك استخدام ملف
رقمي كمفتاح؟ هل هناك أشياء يجب الانتباه لها؟

يوجد مثال بأعمدة عدد صحيح في 2d. اعتقدت أن هذا كان
كاف؟

ماذا لو كان عمودك الرئيسي يحتوي على زمالة المدمنين المجهولين فيه؟ هل يمكنك البحث عن هؤلاء واستبدالهم
لهم (كما فعلت في مثالك حيث استبدلت 24 بـ 0؟

نقطة جيدة. هذا فرق مع المسح المتجه. سأحاول إضافة هذا.

قد يساعد في توضيح أن keyby ينطبق على _output_ data.table (
الجواب في المثال الخاص بك) وليس بيانات الإدخال
مثال).

تمت مناقشة كلمة "keyby" بالفعل في المقالة القصيرة الأولى. لكن سأرى إذا كان هذا
يمكن إضافته.

هل يمكنك تمرير ناقل إلى المفتاح؟ بمعنى آخر ، هل يمكنك إنشاء مطار
<- c ("LGA" ، "JFK" ، "EWR") واستخدام المطار مباشرةً في المثال الخاص بك بالقرب
القاع؟ قد يساعد هذا في تكوين فكرة تمرير ملف
data.table للدمج.

محتوى القسم التالي. هذه هي الطريقة التي ننتقل بها إلى الصلات.

خطأ مطبعي في "المقابلة" ("المطابقة"). واحدة من القراد الخلفي
مفقود في قسم المسح المتجه حيث تكتب "فهارس الصفوف
المطابقة للمصدر == "LGA" والرؤية == "TPA" يتم الحصول عليها باستخدام المفتاح
مجموعة فرعية مقرها ".

شكرا.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/Rdatatable/data.table/issues/944#issuecomment -71253738
.

عمل رائع على هذه المقالات القصيرة!
قد تكون تعليقاتي متأخرة أو مغطاة بالفعل:

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

for (j in  valCols)
   set(dt_,  
    i = which(is.na(dt_[[j]])),
    j = j, 
    value= as.numeric(originTable[[j]]))

تمت إضافة إعادة تشكيل المقالة القصيرة إلى Wiki .

وظائف ممتازة والمقالة القصيرة! شكرا ارون

في الثلاثاء ، 23 حزيران (يونيو) 2015 ، الساعة 21:02 كتب Arun [email protected] :

تمت إضافة إعادة تشكيل المقالة القصيرة
https://rawgit.com/wiki/Rdatatable/data.table/vignettes/datatable-reshape.html
إلى Wiki https://github.com/Rdatatable/data.table/wiki/Getting-started.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/Rdatatable/data.table/issues/944#issuecomment -114678716
.

رجل مقابل patterns سيكون جيدًا. المقالة القصيرة الرائعة

أليس reshape2 مطلوبًا ليتم تحميله لاستخدام هذه الأوامر؟ إذا كان الأمر كذلك ، فيجب ذكر ذلك. أنا حقًا أحب التركيز على "واسع إلى طويل" و "طويل إلى واسع". أكره تمامًا بناء جملة reshape2 (على سبيل المثال ، أعتقد أن "make_wide" أكثر وضوحًا من "dcast"). لهذا السبب ، لن أكتب عناوين الأقسام على أنها "ذوبان جداول البيانات" و "صب جداول البيانات". هذا منطقي فقط للأشخاص الذين هم على دراية بحزمة reshape2. قد أبدأ بالعناوين الأكثر عالمية على النحو الوارد أعلاه ("طويل إلى عريض").

لما يستحق ، لا يمكنني الحصول على السطر الأول من المقالة القصيرة للتشغيل باستخدام جلسة R جديدة مع تحميل data.table فقط. ليس لدي أي فكرة عن السبب (ربما يجب أن يكون الوضع "w" وليس "wb") ، ولكن
DT = fread("https://raw.githubusercontent.com/wiki/Rdatatable/data.table/data/melt_default.csv")
عائدات
Error in download.file(input, tt, mode = "wb") : unsupported URL scheme

كالعادة ، شكرا لفعل هذا إنه مفيد حقًا.

markdanese شكرا على ردود الفعل الممتازة.

1. reshape2 لن يكون مطلوبًا من data.table v1.9.6 . تم تحديث هذا في المقالة القصيرة أيضًا.
2. تمت إضافة "عريض إلى طويل" و "طويل إلى عريض" إلى العناوين وأماكن أخرى لتجنب إرباك الأشخاص الجدد في هذا الموضوع.
3. يتم تنفيذ وظيفة https في fread في إصدار التطوير. لذلك لن تتمكن من تشغيل هذا الرمز حتى الآن باستخدام v1.9.4 . إما التحديث أو الانتظار قليلاً :-).

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

jangorecki patterns() لن يتم تصديرها. سيتم توسيع الاستخدام لـ [.data.table لاستخدامه في اختيار الأعمدة ، := ، .SDcols إلخ ..

arunsrinivasan لا يزال دليل patterns قد يساعد ، بنفس الطريقة التي يوجد بها دليل := . فقط لأن الكثير من الناس (على ما أظن) يستخدمون ?fun لفهم الكود الذي قرأوه.

في _join_ vignette ، قد يكون من المفيد إضافة أمثلة مقابلة من SQL لرابط data.table حتى يكون من السهل التقاطها لشباب db.
يمكن العثور على أمثلة من جملة SQL المقابلة على سبيل المثال في SO كيف تربط

سيكون من الرائع أيضًا أن يكون لدينا بعض المقالات القصيرة عن "اللاجئين" -

• data.table لمستخدمي Stata
• data.table لمستخدمي SQL
• data.table لمستخدمي Matlab
• data.table لمستخدمي Python / pandas
• حتى data.table لمستخدمي dplyr

إلخ مثل دليل البدء السريع ، ولكنه موجه نحو المهاجرين.

تمت إضافة Secondary indices and auto indexing نقوش الصورة النصفية. يجب أن يسمح هذا بالانتقال السلس من المجموعات الفرعية إلى الانضمام إلى المقالة القصيرة التالية التي سأعمل عليها.

arunsrinivasan ليس من الأنسب عدم استخدام _secondary_ فيما يتعلق بـ _indices_؟ تم استخدامه لـ _keys_ حيث كان مهمًا. يبدو الآن أنه لا داعي له بمجرد أن ننتقل إلى تسمية _index_.

jangorecki أعتقد أن "الثانوية" مفيدة لعلاقتها بالمفاتيح (أساسية) ، ربما:

الفرز الثانوي

هل الوصف أفضل؟

ولكن تم بالفعل استخدام الكلمة _index_ ، تبدو أجمل من _التصنيف الثانوي_ :)

لذا يمكنك تسميته "الفهرسة التلقائية"؟ يبدو "الفرز الثانوي والفهرسة التلقائية" في IMO أكثر إفادة

يمكن أن يكون _auto_ مضللاً إلى حد ما ، حيث يجب أن تعمل الفهارس من أجل إنشاء فهرس تلقائي ، وأيضًا لاستخدام الفهارس التي تم إنشاؤها يدويًا - # 1422 قيود العنوان الحالية في هذه المسألة.

أرى. ما زلت أفتقد البديل المفضل لديك - فقط "المؤشرات"؟

ليست مثالية ولكنها مفضلة على _المؤشرات الثانوية_

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

اعتقدت أن أمثلة "تشغيل" كانت مفيدة حقًا.

markdanese نقطة جيدة ، سيضيف.

شكرًا لك على المقالات القصيرة المحدثة مع إصدار v1.9.8.
تشير "الدلالات المرجعية" إلى الوظيفة copy() وقدراتها الجديدة لعمل نسخ ضحلة (خاصة الدوال الداخلية ، وهو أمر يثير اهتمامي حقًا):

"ومع ذلك ، يمكننا تحسين هذه الوظيفة بشكل أكبر عن طريق النسخ السطحي بدلاً من النسخ العميق. في الواقع ، نود بشدة توفير هذه الوظيفة لـ v1.9.8 . سوف

لكن نقش التصميم مفقود ويشير الرابط إلى مشكلة قديمة. لا يوفر الدليل المرجعي مزيدًا من المعلومات حول copy() عن تلك المتوفرة في المقالة القصيرة. لا تقدم بقية المقالات القصيرة أي معلومات عن copy .

هل ستتوفر هذه المقالة القصيرة قريبًا؟

+1 للمصغر الداخلي. أنا (وأعتقد أن البعض الآخر) مهتم جدًا بالمساهمة قليلاً في الجانب C من الأشياء ، لكنني أشعر بالخوف قليلاً من (كما هو الحال) 35 ألف سطر من كود C ... تمامًا منحنى التعلم `` للذهاب لوحده '- يمكن لمقدمة عن الأجزاء الداخلية أن تصنع المعجزات!

من أجل الانضمام إلى المقالة القصيرة:

https://github.com/Rdatatable/data.table/issues/2396

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

arunsrinivasan أرى أن لديك نقطة IDateTime vignette . ربما يمكن إدراجه في المقالة القصيرة الأكثر عمومية التي اقترحها jangorecki : المقالات القصيرة : التسلسل الزمني - الملاحظات المرتبة ؟

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

zeomal مثل هذه المساهمة ستكون ذات قيمة عالية

MichaelChirico ، شكرا لك. @ Henrik-P ، هل سيكون موجزك حول الارتباطات العادية شاملاً - أي هل سيكون تركيزك أكثر على التسلسلات الزمنية؟ إذا لم يكن الأمر كذلك ، يمكنني البدء في العمل عليها - لم أستخدم صلات متدرجة حتى الآن ، لذلك لا توجد معرفة هناك. :)

zeomal آمل أن أتمكن من تحميل المسودة الأولى قريبًا ، حتى تتمكن من إلقاء نظرة عليها. في مسودتي ، أقدم مثالًا بسيطًا لصلة "عادية" في متغير واحد ، الوقت ، حيث توجد صفوف غير متطابقة. أستخدم nomatch = NA . (maaaybe أيضًا مثال سريع بـ nomatch = NULL )

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

شكرا جزيلا على استعدادك للمساهمة! .

لدي سؤال حول الانضمام بالإشارة أثناء تحضير المقالات القصيرة. ينفذ X[Y, new_col := old_col] شيئًا مشابهًا لصلة يسارية تقليدية على X . ومع ذلك ، في حالة وجود العديد من التطابقات مع مفاتيح Y في X ، يتم الاحتفاظ فقط بالقيمة المطابقة الأخيرة (أو الأولى؟) للمفتاح. هل هذا موثق صراحة في مكان ما؟ لقد حاولت البحث عن هذا مرة أخرى عندما واجهته ، لكن كان علي أن ألجأ إلى فهمي للتحديث بالإشارة للسبب. للحصول على مثال قابل للتكرار ،

> X = data.table(a = c(1, 2, 3), m = c("a", "b", "c"))
> Y = data.table(b = c(1, 1, 4), n = c("x", "y", "z"))
> X[Y, new_col := i.n, on = "a == b"]
   a m new_col
1: 1 a       y
2: 2 b    <NA>
3: 3 c    <NA>

# an ideal left join - expected behaviour per a new user, given below
# not possible because updating row by reference isn't implemented
   a m new_col
1: 1 a       x
1: 1 a       y
2: 2 b    <NA>
3: 3 c    <NA>

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

zeomal يرجى نشر سؤالك المستقبلي حول الانضمام إلى المقالة القصيرة في إصدار # 2181 بدلاً من ذلك. يبدو أنه مكان أفضل. تم توثيقه بـ set .

zeomal إذا كنت ترغب في التحقق من مدى وجيزة علاجي على الصلات العادية (equi) ، فأنا أريد فقط أن في المقالة القصيرة من سلسلة التايمز .