Numpy: دعم قسر مجموعة البط

سيبدو التنفيذ المقترح على النحو التالي:

import numpy as np

# hypothetical np.duckarray() function
def duckarray(array_like):
  if hasattr(array_like, '__duckarray__'):
    # return an object that can be substituted for np.ndarray
    return array_like.__duckarray__()
  return np.asarray(array_like)

استخدام المثال:

class SparseArray:
  def __duckarray__(self):
    return self
  def __array__(self):
    raise TypeError

np.duckarray(SparseArray())  # returns a SparseArray object
np.array(SparseArray())  # raises TypeError

لقد استخدمت هنا np.duckarray و __duckarray__ كعناصر نائبة ، ولكن ربما يمكننا أن نفعل ما هو أفضل لهذه الأسماء. انظر المصطلحات من NEP 22:

تعمل "مصفوفة Duck" بشكل جيد كعنصر نائب في الوقت الحالي ، ولكنها اصطلاحية قد تربك المستخدمين الجدد ، لذلك قد نرغب في اختيار شيء آخر لوظائف API الفعلية. لسوء الحظ ، تم استخدام "المصفوفة" بالفعل لمفهوم "أي شيء يمكن إجباره في مصفوفة" (بما في ذلك كائنات القائمة على سبيل المثال) ، و "anyarray" مأخوذ بالفعل لمفهوم "شيء يشارك تطبيق ndarray ، ولكن له دلالات مختلفة "، وهو عكس مجموعة البط (على سبيل المثال ، np.matrix هي" anyarray "، ولكنها ليست" مجموعة duck "). هذه سقيفة دراجات كلاسيكية ، لذا فنحن نستخدم حاليًا "مجموعة البط". على الرغم من ذلك ، تتضمن بعض الخيارات الممكنة: مصفوفة ، مصفوفة زائفة ، مصفوفة اسمية ، مصفوفة مصفرة ، مصفوفة صفراء ، ...

بعض أفكار الأسماء الأخرى: np.array_compatible() ، np.array_api() ....

يمكن أن يعمل np.array_compatible ، على الرغم من أنني لست متأكدًا من أنني أحبه أفضل من duckarray . np.array_api لا يعجبني ، يعطي فكرة خاطئة imho.

منذ فترة طويلة لم نتوصل إلى اسم أفضل ، ربما ينبغي أن نبارك اسم "مجموعة البط" ......

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

ربما quack_array :)

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

>>> import numpy as np, cupy as cp
>>> a  = cp.array([1, 2])
>>> b = np.ones_like(a)
>>> type(b)
<class 'cupy.core.core.ndarray'>

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

import numpy as np, cupy as cp
a  = cp.array([1, 2])
b = [1, 2]
c = np.asarray(b, like=a)

أي أفكار / اقتراحات حول هذا؟

ربما np.copy_like؟ نريد تحديد الخصائص بعناية
(على سبيل المثال ، بما في ذلك نوع dtype أم لا) يتم نسخها من مجموعة أخرى.

يوم الإثنين 1 يوليو 2019 الساعة 5:40 صباحًا Peter Andreas Entschev <
[email protected]> كتب:

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

استيراد numpy مثل np ، cupy مثل cp >>> a = cp.array ([1، 2]) >>> b = np.ones_like (a) >>> type (b)

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

استيراد numpy مثل np، cupy مثل cp
أ = cp.array ([1، 2])
ب = [1 ، 2]
ج = np.asarray (ب ، مثل = أ)

أي أفكار / اقتراحات حول هذا؟

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/numpy/numpy/issues/13831؟email_source=notifications&email_token=AAJJFVRCWDHRAXHHRDHXXM3P5H3LRA5CNFSM4H3HQWAKYY3PNVWWK3TUL52HS4DFVREXG43VMVB50
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AAJJFVRSYHUYHMPWQTW2NLLP5H3LRANCNFSM4H3HQWAA
.

np.copy_like جيدًا أيضًا. أوافق ، على الأرجح يجب أن يكون لدينا طرق للتحكم في أشياء مثل dtype .

آسف لسؤال المبتدئين ، ولكن هل يجب أن يكون شيء مثل np.copy_like تعديلًا لـ NEP-22 ، هل يجب مناقشته في القائمة البريدية ، أو ما هو الأسلوب الأنسب لذلك؟

ليس لدينا بالفعل قواعد صارمة حول هذا الأمر ، لكنني أميل إلى وضع np.copy_like و np.duckarray (أو ما نسميه) معًا في NEP جديد حول الإكراه / إنشاء مصفوفات البط ، واحدة هذا توجيهي مثل NEP 18 بدلاً من "معلوماتي" مثل NEP 22. ليس من الضروري أن يكون طويلاً ، معظم الدوافع واضحة بالفعل من الإشارة إلى NEP 18/22.

ملاحظة واحدة حول np.copy_like() : يجب بالتأكيد إرسال __array_function__ (أو شيء من هذا القبيل) ، لذلك يمكن تحديد عمليات مثل np.copy_like(sparse_array, like=dask_array) إما على أي نوع من المصفوفة.

رائع ، شكرًا على المعلومات ، وأنا أتفق مع اقتراح الإرسال الخاص بك. سأعمل على NEP لتنفيذ كل من np.duckarray و np.copy_like وإرسال مسودة العلاقات العامة لهذا الأسبوع.

رائع ، شكرا لك بيتر!

يوم الإثنين ، 1 تموز (يوليو) 2019 ، الساعة 9:29 صباحًا ، بيتر أندرياس إنتشيف <
[email protected]> كتب:

رائع ، شكرًا على المعلومات ، وأنا أتفق مع اقتراح الإرسال الخاص بك. أنا
ستعمل على NEP لتنفيذ كل من np.duckarray و
np.copy_like وتقديم مسودة العلاقات العامة لهذا الأسبوع.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/numpy/numpy/issues/13831؟email_source=notifications&email_token=AAJJFVW2YUBNUCJZK6JWDBTP5IWHNA5CNFSM4H3HQWAKYY3PNVWWK3TUL52HS4DFVREXG43VMV33
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AAJJFVR2KTPAZ4JPWDYYMFLP5IWHNANCNFSM4H3HQWAA
.

من دواعي سروري ، وشكرا جزيلا على الأفكار والدعم في هذا العمل!

ستكون array_like و copy_like غريبة بعض الشيء في مساحة الاسم الرئيسية على ما أعتقد ، نظرًا لأنه لا يمكننا أن يكون لدينا تطبيق افتراضي (على الأقل لا أحد يقوم بالتفكير الصحيح لـ cupy / dask / sparse / etc) ، صحيح؟ إنها مفيدة فقط عند تجاوزها. أو أني أفتقد طريقة لإنشاء كائنات مصفوفة عشوائية غير معقدة هنا؟

هذا صحيح ، ستكون هذه مفيدة حقًا فقط إذا كنت تريد دعم كتابة البط. ولكن بالتأكيد ستعمل np.duckarray و np.copy_like حتى لو كانت الوسيطات عبارة عن مصفوفات NumPy فقط - فستكون مكافئة لـ np.array / np.copy .

جميع تطبيقات المصفوفة لها طريقة copy أليس كذلك؟ استخدام ذلك بدلاً من copy_like يجب أن يعمل ، فلماذا تضيف وظيفة جديدة؟

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

np.duckarray له معنى بالنسبة لي.

أود أن أميل نحو وضع np.copy_like و np.duckarray (أو أيًا كان ما نسميه) معًا في NEP جديد بشأن إكراه / إنشاء مصفوفات البط ، مخطط توجيهي مثل NEP 18 بدلاً من "المعلوماتي" مثل NEP 22.

+1

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

هذه هي الحالة التي أود معالجتها بشيء مثل np.copy_like . لم أختبر ، ولكن ربما يتم إرسال np.copy بالفعل بشكل صحيح إذا كانت المصفوفة ليست NumPy.

فقط للتوضيح ، هل تشير أيضًا إلى دالة np.array_like ؟ لقد تجنبت عمدًا مثل هذا الاسم لأنني اعتقدت أنه قد يكون مربكًا لجميع المراجع الحالية لمصفوفات array_like . ومع ذلك ، أدرك الآن أن np.copy_like قد يشير إلى نسخة ضرورية ، وأعتقد أنه سيكون من الجيد أن يكون لديك سلوك مشابه لـ np.asarray ، حيث تحدث النسخة فقط إذا لم تكن بالفعل NumPy مجموعة مصفوفة. في الحالة التي تمت مناقشتها هنا ، سيكون من الأفضل عمل النسخة فقط إذا لم يكن a من نفس النوع مثل b في مكالمة مثل np.copy_like(a, like=b) .

لم أختبر ، ولكن ربما يتم إرسال np.copy بالفعل بشكل صحيح إذا كانت المصفوفة ليست NumPy.

يجب أن يكون مزينًا لدعم __array_function__ .

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

نعم. ونعم توافق على أنه يمكن أن يكون مربكا.

ومع ذلك ، أدرك الآن أن np.copy_like قد يشير ضمنًا إلى نسخة ضرورية ،

نعم ، هذا الاسم يعني نسخة من البيانات.

قد يشير إلى نسخة ضرورية ، وأعتقد أنه سيكون من الجيد أن يكون لديك سلوك مشابه لـ np.asarray ،

اعتقدت أن هذا كان np.duckarray .

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

import numpy as np, cupy as cp
a  = cp.array([1, 2])
b = [1, 2]
c = np.copy_like(b, like=a)

اعتقدت أن هذا كان np.duckarray.

في الواقع ، لن يقوم np.duckarray بأي شيء ويعيد المصفوفة نفسها (إذا تم تجاوزها) ، وإلا ستُرجع np.asarray (مما يؤدي إلى مصفوفة NumPy) لا يمكننا الحصول على مصفوفة CuPy من قائمة Python معها ، على سبيل المثال. ما زلنا بحاجة إلى وظيفة يمكن إرسالها إلى CuPy (أو أي مصفوفة أخرى like= ) مقابل array_like .

شكرا jakirkham للمثال المحدث.

c = np.copy_like(b, like=a)

هل سيتم إرسال ذلك إلى CuPy عبر a.__array_function__ ويفشل إذا لم تكن هذه السمة موجودة (على سبيل المثال ، a=<scipy.sparse matrix> لن تعمل)؟ يبدو أننا بحاجة إلى مساحة اسم جديدة أو حزمة أدوات تشغيل تفاعلي جديدة لهذا النوع من الأشياء. إما ذلك أو اتركه لآلية إرسال مستقبلية أكثر اكتمالا حيث يمكن للمرء ببساطة القيام بما يلي:

with cupy_backend:
   np.array(b)

يبدو أن تقديم وظائف جديدة في مساحة الاسم الرئيسية لا معنى لها لـ NumPy نفسها لدعم العمل حول حد __array_function__ يبدو غير صحي بعض الشيء ....

هل سيتم إرسال ذلك إلى CuPy عبر a.__array_function__ ويفشل إذا لم تكن هذه السمة موجودة (على سبيل المثال ، a=<scipy.sparse matrix> لن تعمل)؟

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

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

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

يبدو أن تقديم وظائف جديدة في مساحة الاسم الرئيسية التي لا معنى لها لـ NumPy نفسها لدعم العمل حول قيود وظيفة __array_function__ تبدو غير صحية بعض الشيء ....

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

يبدو أن تقديم وظائف جديدة في مساحة الاسم الرئيسية التي لا معنى لها لـ NumPy نفسها لدعم العمل حول قيود وظيفة __array_function__ تبدو غير صحية بعض الشيء ....

في الواقع ، بهذا المعنى ، لن ينتمي أيضًا np.duckarray إلى مساحة الاسم الرئيسية.

في الواقع ، بهذا المعنى ، لن ينتمي أيضًا np.duckarray إلى مساحة الاسم الرئيسية.

أعتقد أن أحدًا أكثر قابلية للدفاع (مشابه لـ asarray وسيتحقق بشكل أساسي من "هل يتوافق هذا مع تعريفنا لنوع البطة التي تشبه ndarray") ، ولكن نعم. إذا أردنا أيضًا الكشف عن array_function_dispatch ، ولدينا أشياء np.lib.mixins.NDArrayOperatorsMixin ونخطط لكتابة المزيد من mixins ، فقد يكون من المنطقي وجود وحدة فرعية جديدة معقولة لجميع الأشياء المتعلقة بالتشغيل البيني.

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

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

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

لا توجد اعتراضات حقيقية مني ، أعتقد أنه من الأفضل أن يكون لديك وظائف في مكان ما وليس في أي مكان. :)

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

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

ولكن إذا أردنا الاستفادة من __array_function__ نطاق أوسع ، فهل لدينا بدائل أخرى الآن لتنفيذ أشياء مثل np.duckarray و np.copy_like (أو أي شيء آخر نقرر تسميته)؟

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

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

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

بالنسبة للبدائل ، لم يتم العثور على uarray بعد ، ولست مقتنعًا حتى الآن بأنه سيتم دفع النفقات العامة لأسفل بدرجة كافية لاستخدامها افتراضيًا في NumPy ، لكنها تقترب ونحن على وشك محاولة إنشاء scipy.fft نظام الواجهة الخلفية https://github.com/Quansight-Labs/uarray/tree/master/unumpy

نهج الإرسال مع uarray مثير للاهتمام بالتأكيد. على الرغم من أنني ما زلت قلقًا بشأن كيفية تعاملنا مع المصفوفات الوصفية (مثل Dask و xarray وما إلى ذلك). يرجى الاطلاع على هذا التعليق للحصول على التفاصيل. من غير الواضح أنه تمت معالجة هذا الأمر (على الرغم من الرجاء تصحيح ما إذا فاتني شيء ما) سأكون مهتمًا بالعمل مع الآخرين في SciPy لمحاولة اكتشاف كيفية حل هذه المشكلة.

يرجى الاطلاع على هذا التعليق للحصول على التفاصيل. من غير الواضح أنه تمت معالجة هذا الأمر (على الرغم من الرجاء تصحيح ما إذا فاتني شيء ما)

أعتقد أن التغييرات التي حدثت في الأسبوع الماضي تحل ذلك ، لكن لست متأكدًا - فلنترك ذلك لموضوع آخر.

سأكون مهتمًا بالعمل مع الآخرين في SciPy لمحاولة اكتشاف كيفية حل هذه المشكلة.

سأكون هناك ، سيكون من الرائع مقابلتك شخصيًا.

ربما يكون np.coerce_like() أو np.cast_like() أسماء أفضل من copy_like ، لذا من الواضح أن النسخ ليست مطلوبة بالضرورة. الوظيفة المطلوبة تشبه إلى حد كبير طريقة .cast() ، باستثناء أننا نريد تحويل أنواع المصفوفات بالإضافة إلى أنواع dtype ، ويجب أن تكون دالة بدلاً من بروتوكول بحيث يمكن تنفيذها بواسطة أي وسيطتين.

نهج الإرسال مع uarray مثير للاهتمام بالتأكيد. على الرغم من أنني ما زلت قلقًا بشأن كيفية تعاملنا مع المصفوفات الوصفية (مثل Dask و xarray وما إلى ذلك).

uarray على دعم للخلفيات المتعددة لذا يجب أن يعمل شيء كهذا

with ua.set_backend(inner_array_backend), ua.set_backend(outer_array_backend):
  s = unumpy.sum(meta_array)

يمكن القيام بذلك عن طريق وجود استدعاء المصفوفة الوصفية ua.skip_backend داخل تنفيذه ، أو إذا كانت الواجهة الخلفية للمصفوفة الوصفية ترجع NotImplemented عند عدم تطابق النوع.

cc: hameerabbasi

سوف أتوسع في هذا: كقاعدة عامة ، مقابل dask.array ، أي شيء به da سيتم كتابته بدون skip_backend. أي شيء مع NumPy سيحتاج إلى skip_backend.

أو مقابل da يمكنك دائمًا تخطي الإرسال والاتصال بالتنفيذ الخاص بك مباشرةً والحصول على skip_backend(dask.array) كل مكان.

بالنسبة إلى وظائف الإرسال التي لا تحتوي على مصفوفة مرفقة ، مثل ones ، cast ، فأنت تقوم فقط بتعيين الواجهة الخلفية والانتهاء. نفس الشيء بالنسبة إلى np.errstate و np.dtype . يوجد مثال يغطي np.ufunc unumpy .

أما بالنسبة لمسألة الأصلية، uarray يوفر __ua_convert__ البروتوكول، الذي يفعل بالضبط هذا. قد يكون البديل هو أن تتجاوز الخلفيات asarray مباشرة.

شكرًا على التنبيه على uarray ، rgommers ، @ peterbell10 ،hameerabbasi.

لكن كما أرى ، يجب عليك تعيين الواجهة الخلفية المناسبة قبل بدء الحساب ، فهل هذا صحيح؟ تتمثل إحدى مزايا __array_function__ أن المكتبات يمكن أن تكون محايدة تمامًا للمكتبات الأخرى ، مثل Dask لا يحتاج إلى معرفة وجود CuPy ، على سبيل المثال.

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

حسنًا ، أعتقد أن هذا ما ذكره https://github.com/numpy/numpy/issues/13831#issuecomment -507432311 ، مشيرًا إلى الخلفيات في https://github.com/Quansight-Labs/uarray / شجرة / رئيسي / غير متكدس.

آسف للعديد من الأسئلة ، ولكن ماذا لو اعتمد بعض التطبيقات الافتراضية على خلفيات مختلفة ، على سبيل المثال ، كل من NumPy و Sparse ، حيث اعتمادًا على مدخلات المستخدم ، ربما يكون كل شيء NumPy فقط أو Sparse-only أو مزيجًا من الاثنين معًا. @ peterbell10 المذكورة https://github.com/numpy/numpy/issues/13831#issuecomment -507458331 ، ولكن هل يمكن اختيار الواجهة الخلفية تلقائيًا أم ستكون هناك حاجة للتعامل مع الحالات الثلاث بشكل منفصل؟

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

فيrgommers SciPy،danielballan، وأنا شخصيا تحدثت عن هذه المسألة. خلصنا إلى أنه سيكون من المفيد متابعة إضافة duckarray (باستخدام هذا الاسم). ومع ذلك ، يبدو أن هذا سيكون 1.18. على الرغم من الرجاء تصحيح لي إذا أسأت فهم الأشياء. بالنظر إلى هذا ، سيكون من الجيد بدء العلاقات العامة؟

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

كل هذا يبدو رائعًا بالنسبة لي ، ولكن سيكون من الجيد أن نبدأ بسياسة جديدة للتوظيف توضح الاقتراح الدقيق. راجع https://github.com/numpy/numpy/issues/13831#issuecomment -507334210

بالتأكيد هذا منطقي. 🙂

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

a2 = np.empty_like(a1)
a2[...] = a1[...]

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

خلصنا إلى أنه سيكون من المفيد المضي قدمًا في إضافة duckarray (باستخدام هذا الاسم).

كل هذا يبدو رائعًا بالنسبة لي ، ولكن سيكون من الجيد أن نبدأ بسياسة جديدة للتوظيف توضح الاقتراح الدقيق. انظر # 13831 (تعليق)

لقد بدأت بالفعل في كتابة ذلك ، لم أتمكن من إكماله حتى الآن (آسف للتخطيط السيئ https://github.com/numpy/numpy/issues/13831#issuecomment-507336302).

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

a2 = np.empty_like(a1)
a2[...] = a1[...]

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

يمكنك القيام بذلك ، ولكنه قد يتطلب منطق نسخ خاص (كما هو الحال في CuPy https://github.com/cupy/cupy/pull/2079).

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

من ناحية أخرى ، سيكون هذا نوعًا من استبدال asarray . لذلك كنت أتساءل عما إذا كان بدلاً من بعض الوظائف الجديدة copy_like ، نود بدلاً من ذلك إعادة النظر في الفكرة التي اقترحها NEP-18 :

ستحتاج هذه البروتوكولات الخاصة بها:
...
المصفوفة و asarray ، لأنها مخصصة بشكل صريح للإكراه على كائن numpy.ndarray الفعلي.

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

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

كان الإجماع من اجتماع Dev و Sprint في SciPy'19 هو: دعنا نحصل على 1.17.0 خارج الباب ونحصل على بعض الخبرة الواقعية معه قبل اتخاذ أي خطوات تالية.

أتساءل فقط عما إذا كانت هذه فكرة يجب أن نعيد النظر فيها ومناقشتها.

ربما نعم ، ولكن في غضون بضعة أشهر.

ربما نعم ، ولكن في غضون بضعة أشهر.

حسنًا ، شكرًا على الرد!

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

a2 = np.empty_like(a1)
a2[...] = a1[...]

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

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

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

a2 = np.empty_like(a1)
a2[...] = a1[...]

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

يمكنك القيام بذلك ، لكنه قد يتطلب منطق نسخ خاص (كما هو الحال في CuPy cupy / cupy

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

من ناحية أخرى ، سيكون هذا نوعًا من استبدال asarray . لذلك كنت أتساءل عما إذا كان بدلاً من بعض الوظائف الجديدة copy_like ، نود بدلاً من ذلك إعادة النظر في الفكرة التي اقترحها NEP-18 :

ستحتاج هذه البروتوكولات الخاصة بها:
...
المصفوفة و asarray ، لأنها مخصصة بشكل صريح للإكراه على كائن numpy.ndarray الفعلي.

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

لا أعتقد أنه من الجيد تغيير سلوك np.array أو np.asarray ببروتوكول جديد. المعنى الراسخ لها هو الإرسال إلى مصفوفات NumPy ، وهذا هو السبب الأساسي وراء حاجتنا إلى np.duckarray

ومع ذلك ، يمكننا التفكير في إضافة وسيطة like إلى duckarray . سيتطلب ذلك تغيير البروتوكول من الاقتراح المبسط أعلاه - ربما لاستخدام __array_function__ بدلاً من بروتوكول مخصص مثل __duckarray__ ؟ لم أفكر في ذلك حقًا.

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

a2 = np.empty_like(a1)
a2[...] = a1[...]

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

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

هذا عادل. في الواقع يمكننا بالفعل تبسيط الأمور. على سبيل المثال ، يعمل هذا مع CuPy و Sparse اليوم.

a2 = np.copy(a1)

هذا عادل. في الواقع يمكننا بالفعل تبسيط الأمور. على سبيل المثال ، يعمل هذا مع CuPy و Sparse اليوم.

a2 = np.copy(a1)

نعم ، ولكننا نريد أيضًا "نسخ مجموعة البط هذه إلى نوع مجموعة البط الأخرى هذه"

لا أعتقد أنه من الجيد تغيير سلوك np.array أو np.asarray ببروتوكول جديد. المعنى الراسخ هو الإرسال إلى مصفوفات NumPy ، وهذا هو السبب الأساسي وراء حاجتنا إلى np.duckarray

أنا أيضًا غير متأكد من هذا ، وكنت مترددًا حتى في طرح هذا السؤال ، ولهذا السبب لم أفعل ذلك حتى اليوم.

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

لا أعرف ما إذا كان سيكون هناك أي تعقيدات مع ذلك ، ربما نحتاج إلى بعض الحذر ، لكني أميل إلى الإعجاب بهذه الفكرة. قد يبدو هذا زائدًا عن الحاجة في مستويات مختلفة ، ولكن ربما لاتباع النمط الحالي ، بدلاً من إضافة معلمة like يمكن أن يكون لدينا duckarray و duckarray_like ؟

نعم ، ولكننا نريد أيضًا "نسخ مجموعة البط هذه إلى نوع مجموعة البط الأخرى هذه"

ماذا عن تأسيس هذا حول np.copyto ؟

ماذا عن تأسيس هذا حول np.copyto ؟

لا تتردد في تصحيح ما إذا كنت مخطئًا ، لكنني أفترض أنك تعني شيئًا مثل:

np.copyto(cupy_array, numpy_array)

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

يدعم np.copyto بالفعل الإرسال بـ __array_function__ ، لكنه يعادل تقريبًا:

def copyto(dst, src):
    dst[...] = src

نريد ما يعادل:

def copylike(src, like):
    dst = np.empty_like(like)
    dst[...] = src
    return dst

يدعم np.copyto بالفعل الإرسال بـ __array_function__ ، لكنه يعادل تقريبًا:

def copyto(dst, src):
    dst[...] = src

نريد ما يعادل:

def copylike(src, like):
    dst = np.empty_like(like)
    dst[...] = src
    return dst

صحيح ، هذا ما نريده. copyto ويعمل إذا كان المصدر والوجهة من نفس النوع ، فنحن بحاجة إلى شيء يسمح بالإرسال إلى مكتبة مصفوفة الوجهة.

حسنًا ، لا يزال من الممكن أن يكون copyto منطقيًا اعتمادًا على طريقة تفكيرنا بها. خذ على سبيل المثال حالة الاستخدام التالية.

np.copyto(cp.ndarray, np.random.random((3,)))

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

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