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

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

PhilippPelz هل تقصد مثل: https://github.com/facebook/ztorch/tree/master/lib/THZ ؟ أو هل قمت ببناء شوكة خاصة بك من TH تتيح الأنواع المعقدة؟

لدى killeent بعض الملاحظات حول كيفية ارتباط TH بـ Python ، يمكنه مشاركتها.

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

ومع ذلك ، فإن بناء واجهة CUDA الخلفية لـ Tensors المعقدة يعد جهدًا كبيرًا إلى حد ما ، حتى أننا لم نبدأ في ذلك.

لقد كتبت z-cutorch (https://github.com/PhilippPelz/z-cutorch) منذ فترة. إنه قطع شوكة قبل إعادة بناء ديون CudaHalfTensor (ليس لديك الأجهزة بعد).

هذا عظيم. أعتقد أنك دفعت بالفعل جهدًا كبيرًا في هذا الاتجاه :)

soumith لقد قمت بعمل شوكة من TH بأنواع معقدة. في الأساس عبارة عن THGenerateComplexTypes.h + إجراءات BLAS + LAPACK المضافة والباقي مجانًا تقريبًا. بدا لي أنه عمل أقل بكثير من التحقق من أجزاء THZ المتوافقة ثم نسخ اللصق.

أنا عالق في تجميع THPP في الوقت الحالي ، مع اكتشاف رسائل المترجم مثل

/home/philipp/projects/pytorch/torch/lib/tmp_install/include/TH/generic/THBlas.h:6:40: خطأ: متوقع 'أو' أو '...' قبل الرمز المميز '*'
TH_API void THBlas_ (swap) (long n ، real * ، long incx ، real * ، long incy) ؛

صعبة بعض الشيء.

سأكون ممتنًا للمساعدة في كيفية تمكين تكامل Python. يجب أن تكون الواجهة الخلفية لـ CUDA عبارة عن نسخ لصق من z-cutorch.

PhilippPelz هنا بعض الملاحظات حول التفاف PyTorch TH: https://gist.github.com/killeent/4675635b40b61a45cac2f95a285ce3c0

@ killeent شكرا ، تبدو مفيدة للغاية. يتم الآن تجميع lib / build_all.sh ، وأعتقد أنه يمكنني إلقاء نظرة على دليل csrc.

هذا يعمل الآن:

استيراد الشعلة مثل ال
استيراد numpy كـ np

أ = np.array ([1 + 1j، 2 + 2j])
ب = np.array ([3 + 3j، 4 + 4j])
ath = th.from_numpy (أ)
bth = th.from_numpy (ب)
ath_cuda = ath.cuda ()
ath_cuda + = bth.cuda ()
ath = ath_cuda.cpu ()
طباعة (ath.numpy ())

خارج: [4. + 4.j 6. + 6.j]

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

PhilippPelz شكرا لتعليقاتك. أنا أتحقق من تنفيذك. أولاً ، لست متأكدًا من تنفيذك لـ ger . لا يتم تضمين بعض وظائف blas المعقدة في THBlas.c الخاص بك كما عرّفت GER كـ zger_ و cger_ في ترويسات التوليد ، ولكن لا توجد وظيفة blas مع cger_ في العام / THBlas.c . رغم ذلك ، يمكنني استخدام gemv وبعض الوظائف الأخرى. وربما يجب عليك إضافة IMO .gch إلى .gitignore؟ هل دفعت كل الامتدادات الخاصة بك إلى مفترق الطرق؟ يمكنني تقديم طلب سحب إلى سيدك بناءً على التنفيذ أولاً.

وبالنسبة إلى DOT أعتقد أنه ربما بالنسبة للناقلات المعقدة ، فإن إجراءات dotc للنقطة هي الأكثر شيوعًا؟

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

وبالنسبة للاختبارات ، لم أر أي اختبارات سابقة لـ TH. أين يجب أن أكتب تلك الاختبارات؟ أو نكتب بعض اختبارات البايثون

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

بالنسبة لـ DOT ، أستخدم cdotc و zdotc ، يبدو أنهما مفقودان ، سأقوم بالتحديث الأسبوع المقبل.

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

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

رائع أن تبحث أيضًا في هذا!

حسنًا ، لقد دفعت بعض التغييرات. توجد الآن إجراءات TH blas المعقدة

PhilippPelz لقد تقدمت للتو بطلب سحب إلى الريبو الخاص بك. وللطبقات الخطية المعقدة وبعض العوامل الأخرى. يمكن أن يكون هناك الكثير من العمليات hermitian (مثل bp للطبقة الخطية المعقدة). ربما تضيف بعض الوظائف للموتر؟ هل قمت بفحص جزء THNN؟

نعم مفيد الناسك. كودا ففت تعمل الآن. يمكن لف وحدة المعالجة المركزية fft من numpy. لم أتطرق إلى THNN أو THCUNN حتى الآن.

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

سأعيد تحديد جميع الالتزامات بعد مراجعتك.

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

@ Roger-luo نعم ، لدي أيضًا بعض المشاكل مع ذلك في مكان آخر. يجب أن تكون الأنواع المعقدة التي نستخدمها إما من complex.h أو std :: complex. نظرًا لأن THPP هو غلاف C ++ ، فربما يكون std :: complex أكثر ملاءمة. هل يمكنك تغيير ذلك من فضلك؟

يتسبب الدفع أيضًا في حدوث مشكلات للسبب نفسه بالضبط عند محاولة إنشاء امتدادات cffi. في الوقت الحالي ، أقوم بحل بديل ، ولكن الطريقة الصحيحة هي تغيير النوع المعقد إلى cuFloatComplex / cuDoubleComplex في THC. حتى لا يشكو مترجم cffi. أريد فقط المضي قدمًا في البحث الآن ، فهذا يستغرق الكثير من الوقت مني :(. إذا كان لديك وقت ، فيرجى القيام بذلك.

أيضًا ، يعد إنشاء امتداد cffi باستخدام استدعاءات kernel المخصصة أمرًا مرهقًا للغاية ، لأن المرء يحتاج دائمًا إلى إنشاء مكتبة إضافية مجمعة باستخدام nvcc ، والتي يتم ربطها بعد ذلك بغلاف cffi. أعتقد أنه لا توجد طريقة أخرى. يمكن للمرء استخدام cffi في وضع ABI ، لكن موقع الويب يقول "وضع API يقوم بدلاً من ذلك بتجميع غلاف CPython C الذي يستدعي الوظيفة المستهدفة مباشرةً. إنه ، نسبيًا ، أسرع بشكل كبير (ويعمل بشكل أفضل من libffi على الإطلاق)."

PhilippPelz ربما reinterpret_cast يمكن أن يكون حلاً؟ أعتقد أنه يجب تغييره إلى cuComplex ، واستخدام reinterpret_cast في THPP. سأحاول أولا ...

نعم ، أعتقد أنه لا توجد طريقة أخرى غير reinterpret_cast إذا كنت تريد إنشاء THPP أيضًا بدون تثبيت cuda.

PhilippPelz أود المساعدة. هل هناك أي قائمة مهام في أي مكان؟

يجب تمكين THNN و THCUNN للأنواع المعقدة. هل يمكنك التنسيق مع @ roger-luo؟ أيضًا ، إذا كنا نهدف إلى التكامل مع الماجستير ، فيجب كتابة اختبارات الوحدة لجميع الطرق المعقدة.

elbamos معظم العمل في THNN سيكون حول تنفيذ طرق backpropagtion الجديدة المعقدة لكل طبقة موجودة. هناك PR WIP في مفترق فيليب. لقد قمت بإدراج بعض المراجع.

apaszkesoumithPhilippPelz وهناك سؤالان :

• هل يعرف أحد سبب وجود ملف GenerateXXXTypes.h آخر في THS ؟ يبدو هو نفسه مع تلك الموجودة في TH .

• ما هي الكود التالي في byte_order.cpp لـ؟

void THP_decodeFloatBuffer(float* dst, const uint8_t* src, THPByteOrder order, size_t len)
{
  for (size_t i = 0; i < len; i++) {
    union { uint32_t x; float f; };
    x = (order == THP_BIG_ENDIAN ? decodeUInt32BE(src) : decodeUInt32LE(src));
    dst[i] = f;
    src += sizeof(float);
  }
}

void THP_decodeDoubleBuffer(double* dst, const uint8_t* src, THPByteOrder order, size_t len)
{
  for (size_t i = 0; i < len; i++) {
    union { uint64_t x; double d; };
    x = (order == THP_BIG_ENDIAN ? decodeUInt64BE(src) : decodeUInt64LE(src));
    dst[i] = d;
    src += sizeof(double);
  }
}

أي اقتراحات بشأن تنفيذ نسخته المعقدة ذات الصلة؟ لست متأكدًا مما إذا كان التنفيذ التالي صحيحًا ...

void THP_decodeZFloatBuffer(std::complex<float>* dst, const uint8_t* src, THPByteOrder order, size_t len)
{
  for (size_t i = 0; i < len; i++) {
    union { uint64_t x; std::complex<float> cf;};
    x = (order == THP_BIG_ENDIAN ? decodeUInt64BE(src) : decodeUInt64LE(src));
    dst[i] = cf;
    src += sizeof(std::complex<float>);
  }
}

void THP_decodeDoubleBuffer(std::complex<double>* dst, const uint8_t* src, THPByteOrder order, size_t len)
{
  for (size_t i = 0; i < len; i++) {
    union { uint128_t x; std::complex<double> df;};
    x = (order == THP_BIG_ENDIAN ? decodeUInt128BE(src) : decodeUInt128LE(src));
    dst[i] = df;
    src += sizeof(std::complex<double>);
  }
}

تم التصريح عن decodeUInt128XE السابق كـ

static inline uint128_t decodeUInt128LE(const uint8_t *data) {
  return (((uint128_t)data[ 0])<<  0) | (((uint128_t)data[ 1])<<  8)|
         (((uint128_t)data[ 2])<< 16) | (((uint128_t)data[ 3])<< 24)|
         (((uint128_t)data[ 4])<< 32) | (((uint128_t)data[ 5])<< 40)|
         (((uint128_t)data[ 6])<< 48) | (((uint128_t)data[ 7])<< 56)|
         (((uint128_t)data[ 8])<< 64) | (((uint128_t)data[ 9])<< 72)|
         (((uint128_t)data[10])<< 80) | (((uint128_t)data[11])<< 88)|
         (((uint128_t)data[12])<< 96) | (((uint128_t)data[13])<<104)|
         (((uint128_t)data[14])<<112) | (((uint128_t)data[15])<<120);
}

static inline uint128_t decodeUInt128BE(const uint8_t *data) {
  return (((uint128_t)data[15])<<  0) | (((uint128_t)data[14])<<  8)|
         (((uint128_t)data[13])<< 16) | (((uint128_t)data[12])<< 24)|
         (((uint128_t)data[11])<< 32) | (((uint128_t)data[10])<< 40)|
         (((uint128_t)data[ 9])<< 48) | (((uint128_t)data[ 8])<< 56)|
         (((uint128_t)data[ 7])<< 64) | (((uint128_t)data[ 6])<< 72)|
         (((uint128_t)data[ 5])<< 80) | (((uint128_t)data[ 4])<< 88)|
         (((uint128_t)data[ 3])<< 96) | (((uint128_t)data[ 2])<<104)|
         (((uint128_t)data[ 1])<<112) | (((uint128_t)data[ 0])<<120);
}

أستخدم حاليًا std::complex<T> بدلاً من T _Complex في THPP . لست متأكدًا من أنه يمكن استخدام هذا بواسطة Python حتى الآن. أو فقط c type T _Complex يمكن استخدامه مع python. إذاً هنا نوع dst هو std::complex<T> .

وإذا كنت على حق في هذا التنفيذ ، فربما نحتاج إلى تطبيق uint128_t ، مثل https://github.com/calccrypto/uint128_t ؟ نظرًا لأنه لا يبدو أن جميع المجمعات تدعم عددًا صحيحًا من 128 بت (يحتوي gcc على int128_t و uint128_t).

PhilippPelz لقد لاحظت أن مفترقك لا يحتوي على مشكلات ممكّنة - ما هي حالة مشروعك؟ أنا منزعج قليلاً من أن الموترات المعقدة ليست على خريطة طريق pytorch

@ el3ment لقد أضفت خلفية معقدة لوحدة المعالجة المركزية https://github.com/pytorch/pytorch/pull/4899 لكن لم تتم مراجعتها بعد ... ولم أتلق أي تعليقات على العلاقات العامة الخاصة بي ، لذلك لجأت إلى الاستخدام لغة البرمجة Julia مؤخرًا ...

لقد قمت بإرسال بريد إلكتروني إلىPhilippPelz آخر مرة ، أعتقد أن الريبو الخاص به لا يزال تحت الإصدار 0.1 وهو مشغول بالأطروحة حتى سبتمبر؟ وكنت أعمل على الواجهة الخلفية الجديدة لـ CUDA لـ v0.3 ، لكن ليس لدي الوقت لإنهاء كل هذه الارتباطات بمفردها. تختلف وظائف الخريطة / التقليل عن الإصدار 0.1 مع بعض التحسينات ولكن لا يمكن تحويلها بشكل بسيط لدعم الأرقام المعقدة. سأكون سعيدًا إذا كان هناك أي شخص على استعداد للمساعدة ...

أنا على استعداد للمساعدة.

في 10 أبريل 2018 ، الساعة 10:52 مساءً ، كتب Rogerluo [email protected] :

@ el3ment لقد أضفت خلفية معقدة لوحدة المعالجة المركزية # 4899

لقد قمت بإرسال بريد إلكتروني إلىPhilippPelz آخر مرة ، أعتقد أن الريبو الخاص به لا يزال تحت الإصدار 0.1 وهو مشغول بالأطروحة حتى سبتمبر؟ وكنت أعمل على الواجهة الخلفية الجديدة لـ CUDA لـ v0.3 ، لكن ليس لدي الوقت لإنهاء كل هذه الارتباطات بمفردها. تختلف وظائف الخريطة / التقليل عن الإصدار 0.1 مع بعض التحسينات ولكن لا يمكن تحويلها بشكل بسيط لدعم الأرقام المعقدة. سأكون سعيدًا إذا كان هناك أي شخص على استعداد للمساعدة ...

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

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

مرحبًا ، الرمز الخاص بي موجود في بعض الالتزام بعد الإصدار 0.2

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

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

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

@ el3ment ليس لدي وقت للعمل على قضايا الآخرين. ومع ذلك ، سأقوم بدمج الأشياء إذا كنت بحاجة إلى تنفيذ شيء غير موجود.

إذا كنت تريد شيئًا يعمل بأرقام معقدة خارج الصندوق ، فإنني أوصي بشدة بـ Tensorflow.

سأساعدك أيضًا إذا كانت هناك مشاكل في الترجمة.

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

PhilippPelz متفق عليه ، إنه أمر محزن حقًا وفي الواقع لا يدعم Tensorflow جميع المشغلين في فيزياء الكم ... لقد بدأت في استخدام Julia والتخلي عن الثعبان.

@ Roger-luo مثير للاهتمام ، هل تستخدم حزمة جوليا معينة أم أنها كلها كود مكتوب ذاتيًا؟

PhilippPelz أقوم بتطوير مجموعة أدوات كمومية متعددة الأجسام في Julia (منذ ذلك الحين PyTorch PR) ، وهي تتضمن تنفيذ شبكة عصبية معقدة / حقيقية بناءً على بعض الأوراق السابقة حول الشبكة العصبية المعقدة ، ووجدت أنه من السهل جدًا تطويرها باستخدام Julia metaprogramming. لقد وضعته حاليًا في QMTK.jl ، ولا يزال قيد التنفيذ ولم أنتهي من كل ما أريد. يلهمني PyTorch كثيرًا بالفعل ، لكنني آسف حقًا للدعم المعقد ...

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

يمكنك مشاهدته إذا كنت مهتمًا بتطويره.

إذا كان فريق PyTorch لا يزال لديه خطط لدعم معقد في المستقبل ، فسأكون على استعداد للمساعدة بالرغم من ذلك.

رائع ، سأراقبها!

مرحبًا يا شباب ، آسف جدًا لأننا لم نرد على هذه المشكلة منذ فتحها.

فيما يلي حقيقتان:

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

منذ أن تم فتح هذه المشكلة مرة أخرى في عام 2017 ، تغيرت بعض الأشياء المهمة التي قد تجعل تنفيذ الدعم المعقد أسهل قليلاً. الأول هو أن لدينا الآن ATen ، مكتبة C ++ مريحة للتلاعب بالموترات. هذا يعني أنك لست مضطرًا إلى نسخ عجينة شرائح عملاقة من كود TH / THC وآمل أن تكون قد حصلت على كل إعادة العد اليدوي بشكل صحيح ، يمكنك كتابة كود C ++ كما لو كان Python وسيعمل بسرعة. ثانيًا ، نحن نعمل على إصدار جديد من ATen ، يُدعى C10 ، وهو أكثر جدية فيما يتعلق بامتلاك واجهات خلفية مفتوحة من ATen (وهو شيء مغلق) مما يجعل العمل على الدعم المعقد أسهل ، لأنه لن يكون ' يستلزم في الواقع تفرع PyTorch ، فقط إضافة دليل جديد من التعليمات البرمجية.

لذا ، @ Roger-luo و @ PhilippPelz ، نود الحصول على مساعدتك لجعل الواجهة الخلفية المعقدة حقيقة واقعة ، لكننا نرغب حقًا في اكتشاف طريقة للقيام بذلك تساعدنا على الحفاظ عليها بشكل مستدام في المستقبل. اسمحوا لنا أن نعرف ما هو رأيك.

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

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

1. استخدم float2 ، وما إلى ذلك لمحاكاة قيمة معقدة واحدة مثل cuComplex do في جزء CUDA.
2. استخدم FloatTensor و DoubleTensor لمحاكاة موتر معقد في جزء ATen's C ++.

سبب الطريقة الثانية هو أنه في THC ، تستخدم pytorch بعض الحيل لتسريع الخريطة / تقليل العمليات وهي غير مناسبة لـ cuComplex بشكل تافه لأن cuComplex هو في الواقع float2 ، لكن وظائف __shfl_xxx لا تدعم في الأصل float2 . لست متأكدًا من كيفية محاكاة مثل هذه الوظيفة بكفاءة مقابل float2 في الوقت الحالي.

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

بالإضافة إلى ذلك ، وجدت أنه لدمج العدد المركب في ATen ، قد نضطر إلى التعامل مع أربعة أنواع مختلفة هي نفسها في الواقع على الأجهزة: std::complex ، thrust::complex ، cuComplex ، float2 والتي قد تكون خطيرة في بعض الأحيان. (في الواقع ، واجهت هذه المشكلة العام الماضي ، وكان الحل هو reinterpreter_cast ).

أنا شخصيا أفضل أن أكتب كل شيء أصلي على الرغم من ذلك.

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

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

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

فكرت كثيرا في هذا خلال اليوم الماضي. إنه لأمر محزن بعض الشيء أننا لم نتمكن من دمج جهود روجر كما هي ، لكنني فكرت في ذلك

"كيف يمكننا إنشاء دعم Tensor معقد ، مع الحفاظ على تكاليف صيانة منخفضة؟"

هذا ما أضعه كخطة فعالة من الهدف أعلاه:

• لا ينبغي أن تكون الموترات المركبة نوعًا أساسيًا جديدًا من Tensor ، مثل sparse Tensors. تؤدي إضافة نوع أساسي إلى الكثير من التغييرات العامة والتغييرات الشاملة في الصيانة. لا تتعلق النفقات العامة للصيانة بـ "من الذي يحافظ على البتات المعقدة؟"
  
  
  
  • بدلاً من ذلك ، يجب أن تكون دائمًا [شكل Tensor x 2] أو [2 x TensorShape] ، أي يجب أن يكون للموتر بعد إضافي واحد بحجم 2.
  
  
• يجب أن تكون Tensors المعقدة عبارة عن ملف / مجلد صغير من حوالي 2k سطر من C ++ البسيطة التي تم إنشاؤها فوق ATen Tensor API.
  
  
  
  • على سبيل المثال ، كما يقترح https://github.com/pytorch/pytorch/issues/6514 ، يجب تنفيذ الضرب المعقد كـ torch.stack([real1 * real2 - imag1 * imag2, real1 * imag2 + imag1 * real2], dim = -1) حيث real1 = input1[:, :, :, ..., 0]
  
  
  • هذا يضر بالأداء: نعم ، لن نحصل على نفس القدر من الأداء كما لو أننا ضمنا كل شيء. لكن السؤال هو: "بكم؟". أعتقد أننا يجب أن نهدف إلى أداء أقل بنسبة 20٪ مقابل دعم معقد صحي وكامل الميزات + الحفاظ عليه.
  
  
  • يمكن أن تبدأ الوظائف المعقدة الأكثر استخدامًا في الحصول على نواة مخصصة ، بحيث عندما يأخذ الأداء أكثر من 20٪ من وظيفة مستخدمة بشكل متكرر ، فإننا نتدخل.
  
  

يجب أن يكون [Tensor Shape x 2] كما تتوقع كل من BLAS و cublas و MAGMA أنواعها المعقدة الخاصة التي تتوافق مع البايت مع float2. كما لا يمكن التعامل مع استدعاءات blas و cublas و magma على مستوى الثعبان.
لا أعتقد أنها ستكون 20٪ فقط للضرب المعقد ، أليس لديك 4 عمليات نسخ كاملة فوق العمليات الحسابية للجزء الحقيقي والصوري؟
على أي حال ، سأظل سعيدًا إذا لم أضطر إلى دمج التغييرات من الرئيسي باستمرار.

أتفق مع PhilippPelz ، فقد نفقد الكثير من الأداء لأننا سنفقد الدعم المعقد من BLAS و cublas و MAGMA. لكني لست متأكدا من ذلك. ومع ذلك ، لكي نكون واضحين ، فإن Tensor المعقد هو شيء مختلف تمامًا عن الموتر المتناثر ، ومعظم المكتبات مثل scipy.sparse ، وتعامل Julia's SparseArrays المصفوفة المتفرقة كتكوين من المصفوفات الأساسية متعددة الأبعاد. لكن لا أحد يتعامل مع مصفوفة متعددة الأبعاد بنوع معقد بواسطة مصفوفتين حقيقيتين مركبتين ... (لا أحد أقصد هنا tensorflow و arrayfire و numpy و Julia). على الرغم من أنه في MXNet ، يتم إنجاز FFT من خلال تكوين اثنين من الموترات الحقيقية بالفعل ، إلا أنهما لا يدعمان التعقيد ... يبدو أن tensorflow نفذ DataType كغلاف حول أنواع مختلفة من الشبكات بما في ذلك complex64 و complex128 انظر types.proto

حول فقدان الأداء

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

• gemm
• gemv

قد يكون الموتر المركب شيئًا مشابهًا (أو استخدم فقط shared_ptr ):

class ComplexTensor {
    FloatTensor *real;
    FloatTensor *imag;
};

ومع ذلك ، كما ذكرت في عيب النهج الأول ، فإن وظائف مثل __shfl_xxx تبدو أيضًا كعقبة إذا أردنا القيام بذلك بشكل أصلي.

حاليًا يُرجع torch.fft موترًا عائمًا واحدًا للشكل [dim1, ..., dimN, 2]

ezyang ما هو الإطار الزمني لإصدار C10؟ تبدو هذه نقطة معقولة جدًا لبدء دعم المجمع في الفرع الرئيسي.

PhilippPelz بالتأكيد ليس لـ 0.4. نحن نستهدف يونيو داخليًا ، ونأمل ألا يكون هناك وقت طويل للانتظار.

ezyang الذي ذكرته في يونيو ، هل تمكنت من إضافة دعم للأرقام المعقدة إلى PyTorch؟

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

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

هل هناك أي ETA على الأعداد المركبة؟ هل "أسهل بكثير" تعني "من المحتمل أن يتم بسرعة"؟

themightyoarfish بواسطة أسهل بكثير ، أعني أننا لن يتم حظرنا على ما يمكن دفعه إلى سيد pytorch. لم نقم بتعيين ETA. سأقوم بتحديد نطاق العمل بمجرد فتح التسجيل في PyTorch.

soumith هل ما زلت بحاجة لأشخاص للعمل على هذا (العدد المركب)؟ فريق PyTorch سيدعم الأعداد المركبة؟ يمكنني قضاء بعض الوقت في العمل على هذا إذا كنت تريد ذلك في سبتمبر ، حيث سأحتفظ بـ QuCumber (سيستخدم رقمًا معقدًا بشكل كبير)

@ روجر لوه نعم. أردت التواصل معك بمجرد توفر التسجيل المفتوح في الواجهة الخلفية لـ PyTorch ، ويمكننا العمل على التفاصيل.
ezyang هل سيكون لدينا نوع تسجيل مفتوح بحلول سبتمبر؟

soumith Cool ، في خدمتكم.

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

ezyang أي ملاحظات الآن؟ يمكنني قراءتها على الرغم من ذلك قبل العمل عليها. يبدو أن الأمور تغيرت كثيرًا منذ آخر مرة.

@ Roger- luoPhilippPelz أود أيضًا مساعدتك في تنفيذ الموترات المعقدة. أحتاجه أيضًا من أجل تحقيقات الدكتوراه الخاصة بي ..

alexgomezalanis ربما يكون لدينا قناة للمناقشة على Slack ، لقد قمت للتو بإنشاء مكالمة قناة #complex-numbers . لكنني لن أبدأ العمل عليها حتى سبتمبر (ما زلت بحاجة إلى العمل على بعض أكواد جوليا الخاصة بي ...)

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

alexgomezalanis لا أستطيع. عليك الانضمام إلى مساحة عمل pytorch على Slack أولاً. انا لا استطيع ان اجدك. يرجى إرسال بريد إلكتروني إلى العنوان: [email protected] للحصول على دعوة.

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

كنت أحاول أيضًا حفظ بحثي العام الماضي 😏 ... ولكني الآن أريد فقط إعادة الرمز المحلي القديم 1w + إلى الحياة مرة أخرى. 🤣 دعنا نتحادث على Slack!

:) نعم ، دعنا نتحادث على Slack. فقط وجدت الدعوة في مجلد البريد.

ملحق العمل قيد التقدم (لوحدة المعالجة المركزية فقط على المدى القصير) موجود هنا: https://github.com/Roger-luo/pytorch-complex

لا تتردد في إعطائي قضية والعلاقات العامة.

لقد قمت بنشر الملاحظات حول كيفية تنفيذ التنفيذ المعقد في الجزء العلوي من هذه المشكلة.

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

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

مرحبًا bencbartlett

ما زلت أحاول العمل عليها ببطء ... لكنني حاليًا مجرد طالب أيضًا (مع وضع غير مستقر تمامًا) ، مما يعني أنه لا يمكنني العمل بدوام كامل ولكن في أوقات الفراغ فقط. (لقد قمت بتطبيق الكود المتعلق بالبحث في Julia من العام الماضي ، مما يعني أن الحزمة القديمة فقط هي التي تحتاج إلى دعم رقم معقد أفضل من torch.).

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

https://github.com/PIQuIL/QuCumber/blob/master/qucumber/utils/cplx.py

إنه بطيء للغاية ... لكنه يعمل على الأقل. أو كان لدي نسخة C بأسلوب TH القديم.

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

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

ليس لدي وصول إلى PyTorch Slack حتى الآن ، لسوء الحظ. (لقد قمت بإرسال بريد إلكتروني مرتين لطلب دعوة ، لكن لم أتلق ردًا). ​​هل يمكن لشخص ما دعوتي؟ ([email protected])

@ Roger-luo ، سألقي نظرة بالتأكيد من خلال مفترقك ، لكن لا يمكنني أن أعدك بأنني سأقدم لك الكثير من المساعدة - لغة C ++ الخاصة بي صدئة وكما أشرت ، من الصعب إيجاد وقت للعمل على هذا باعتباره طالب علم. أدوات QuCumber لطيفة ، لكن لسوء الحظ لن تكون مفيدة للغاية بالنسبة لي: حتى يتم دعم الموترات المعقدة بواسطة GPU أو يتم دعمها بواسطة autograd و torch.nn ، فإنها لا توفر الكثير من الفوائد فوق ما يمكن أن تقدمه NumPy.

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

يمكن استخدام نهج bencbartlett QuCumber على وحدة معالجة الرسومات مع AD ... إنه بطيء للغاية ... أعني إذا كنت تريد ذلك الإعلان فقط ، فقد تتمكن من استخدامه.

نعم ، بصراحة ، أستخدم نسخة معدلة قليلاً من https://github.com/FluxML/Flux.jl وبعض حزمتي الخاصة في Julia للبحث (أحتاج إلى AD معقد على GPU مع موترات في بعض المواقف أيضًا ). يمكن أن تقوم الحزمة source2source AD ​​Zygote.jl بعمل AD على موترات معقدة ، ولكنها في مرحلة مبكرة جدًا والتي قد تحتوي على أخطاء في المقطع. النظام البيئي ليس مستقرًا حتى الآن بالمقارنة مع الشعلة ، أحيانًا أضطر إلى اختراق تلك التطبيقات قليلاً للاستخدام الذاتي ... لكنها تعمل أساسًا مع ما أحتاجه للبحث في فيزياء الكم. يمكنني الحصول على موترات معقدة على وحدة معالجة الرسومات أيضًا.

لا أعتقد أن هناك حاجة إلى دعم القيمة المعقدة لـ torch.nn ، فقد نحتاج فقط إلى إضافة بعض التعريفات لـ autograd بمجرد أن يعمل الموتر المعقد ، لأن أشياء مثل الطبقات الخطية يمكن أن تظل كما هي . وقد لا تحتوي بعض وظائف التنشيط على توسعة قياسية في مساحة هيلبرت ... (يمكنك التحقق من مشاركة مدونة متعاون GiggleLiu )

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

يمكنني التقدم للحصول على تدريب داخلي في الربيع (والذي سألت عنه للتو ezyang ). لذلك قد أكون قادرًا على العمل بدوام كامل لعدة أشهر قبل أن أبدأ الدكتوراه. دعنا نرى.

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

هل لديك أي فكرة لماذا؟ إذا كنت تعرف تطبيقًا أفضل للضرب المعقد ، فيرجى إبلاغي بذلك. بطريقة ما ، يبدو أن نسختي (على الرغم من تحسينها لعدد المضاعفات: 3 بدلاً من 4) بطيئة نسبيًا ، على سبيل المثال ، يكون irfft of the out tensor أسرع بعشر مرات من عملية الضرب بالعناصر. هل الضرب المعقد مدعوم على مستوى C ++ من PyTorch؟

def complex_mul(x, y, out):
    uavc = x[..., 0] * (y[..., 0] + y[..., 1])
    out[..., 0] = uavc - (x[..., 0] + x[..., 1]) * y[..., 1]
    out[..., 1] = (x[..., 1] - x[..., 0]) * y[..., 0] + uavc

def test_complex_mul_out_tensor(self):
        N, C, H, W, I = 128, 3, 32, 32, 2
        K = 16  # number of filter banks
        repetitions = 1000
        dtype = torch.float
        if torch.cuda.is_available():
            device = torch.device("cuda")
        else:
            device = torch.device("cpu")
        x = torch.randn(N, 1, C, H, W, I, dtype=dtype, device=device)
        y = torch.randn(K, C, H, W, I, dtype=dtype, device=device)
        start_mul_time = time.time()
        out = torch.empty(N, K, C, H, W, I, dtype=dtype, device=device)
        for _ in range(repetitions):
            complex_mul(x, y, out)
        print("multiplication time: ", time.time() - start_mul_time)

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

تنفيذك مشابه لما لدينا في QuCumber. قد تستدعي الكثير من خيوط معالجة الرسومات الإضافية إذا لم تقم باستدعاء cuda kernel الصحيح لرقم مركب. وقد تفقد SIMD إذا لم يكن لديك خلفية C ++ كدعم في Python.

أود أن أقترح عليك تشغيل nvprof للحصول على مزيد من التفاصيل.

@ Roger- luoapaszkesoumith شكرا لهذا الموضوع راجع للشغل. لقد نفذت موترًا معقدًا أساسيًا تم اختراقه معًا من شعلة فئة فرعية.

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

لقد تحققت من Tensorflow و numpy. تتطابق التدرجات وجميع العمليات التي قمت بتنفيذها مع مخرجاتها!

الغرض منه فقط هو الاحتفاظ به حتى يدعم PT بشكل كامل الموترات المعقدة.

سمات:

1. الاختبارات المنفذة.
2. دعم Pypi (على سبيل المثال: تثبيت نقطة)

pip install pytorch-complex-tensor

https://github.com/williamFalcon/pytorch-complex-tensor

شكرا ويليام فالكون !

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

مرحبًا whmrtm

يعمل ezyang على https://github.com/Roger-luo/pytorch-complex/issues/4 أو أي شخص مهتم بهذا يمكن أن يساعدنا في تشغيله. ستحل هذه المشكلة بعض مشكلات البث الأساسية (ثم يمكنك استخدام الكثير من الوظائف بعد حل هذه المشكلة). لا تتردد في القيام بأي علاقات عامة أو اطلب مني إضافتك كمتعاون.

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

مرحبًاwhmrtm

تعمل ezyang على Roger-luo / pytorch-complex # 4 أو أي شخص مهتم بهذا يمكن أن يساعدنا في تشغيله. ستحل هذه المشكلة بعض مشكلات البث الأساسية (ثم يمكنك استخدام الكثير من الوظائف بعد حل هذه المشكلة). لا تتردد في القيام بأي علاقات عامة أو اطلب مني إضافتك كمتعاون.

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

شكرًا على التحديث ، سأرى ما يمكنني فعله.

مرحبًا @ روجر لو

هل يمكنني الوصول إلى قناة Slack المتعلقة بموضوع دعم الموترات المعقدة ([email protected])؟ لقد قمت بإرسال بريد إلكتروني للحصول على دعوة ولكن لم يحدث شيء بعد. الآن أحاول معرفة النقاط حيث أبدأ المساهمة في هذه المشكلة. أعتقد أن https://github.com/Roger-luo/pytorch-complex/issues/4 هي نقطة دخول حالية الآن؟

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

لا يمكنني إرسال بريد إلكتروني للدعوة (ليس لدي وصول). أعتقد أنه يجب عليك اتباع دليل pytorch الرسمي للانضمام إلى Slack. لكن يمكننا دائمًا مناقشة الموضوع / العلاقات العامة.

@ روجر لو ، موافق ، فهمت :)

اسمحوا لي أن أعرف إذا كنتم بحاجة إلى أي مساعدة. سأبدأ ببناء نسخة pytorch المحددة. أي تقدم في مجمع pytorch / القضايا / 4 ؟

اسمحوا لي أن أعرف إذا كنتم بحاجة إلى أي مساعدة. سأبدأ ببناء نسخة pytorch المحددة. أي تقدم في مجمع pytorch / القضايا / 4 ؟

dylanbespalko مرحبًا ، أنا بحاجة ماسة لتطبيق pytorch في إصدار ذي قيمة معقدة.
شكرا جزيلا لمساهماتك.

مع أطيب التحيات،
زيلار 209

مرحبًا @ Zellar209 ،

أشعر أن ezyang يعمل بجد على واحدة من أكبر المشكلات ( pytorch-complex / issues / 4 ). لدي الآن نظام AMD ونظام Nvidia في 3 أسابيع يمكنني استخدامه لزيادة دعم وحدة معالجة الرسومات.

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

IMHO أعتقد أنه يجب علينا التركيز على وحدة المعالجة المركزية وجعل الأشياء تعمل أولاً ، ثم التفكير في وحدة معالجة الرسومات لاحقًا.

دعم وحدة المعالجة المركزية فقط جيد. هل هذا النوع من مشاكل الترقية ( معقد pytorch / قضايا / 4 يتم التعامل معها داخليًا بواسطة fb؟ هل من المقبول العمل عليها خارجيًا؟

مرحباdylanbespalko ؛ لقد أخبرت @ Roger-luo أنني سأبحث في الأمر (لأنني ربما كنت في وضع أفضل لمعرفة ماهية المشكلة) ، لكن لم يتح لي الوقت للنظر فيها حتى الآن. إذا كنت تريد إلقاء نظرة على كيفية حل المشكلة ، فسيسعدني تقديم النصيحة.

مرحبًا @ Zellar209 ،

أشعر أن ezyang يعمل بجد على واحدة من أكبر المشكلات ( pytorch-complex / issues / 4 ). لدي الآن نظام AMD ونظام Nvidia في 3 أسابيع يمكنني استخدامه لزيادة دعم وحدة معالجة الرسومات.

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

مرحبًا @ Zellar209 ، هل يمكنك نشر ما تحصل عليه في مشكلة pytorch-complex؟ أعتقد أن هناك شيئًا خاطئًا في Xcode الجديد من Mac ، مما يجعل من الصعب بنائه. لكن الناس سيحتاجون إلى المزيد من رسائل الخطأ لمعرفة السبب.

سألت عن نظام التشغيل ورسائل الخطأ ، لكنك لم ترد ...

مرحباdylanbespalko ؛ لقد أخبرت @ Roger-luo أنني سأبحث في الأمر (لأنني ربما كنت في وضع أفضل لمعرفة ماهية المشكلة) ، لكن لم يتح لي الوقت للنظر فيها حتى الآن. إذا كنت تريد إلقاء نظرة على كيفية حل المشكلة ، فسيسعدني تقديم النصيحة.

شكرا لك على ردك المبكر.

1. عند تشغيل "python setup.py install" باستخدام gcc (افتراضي) ، تظهر لي أخطاء مثل:

بناء امتداد "torch_complex.cpp"
دول مجلس التعاون الخليجي -Wno-unused-result -Wsign-Compar -Wunreachable-code -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I / anaconda3 / include -arch x86_64 -I / anaconda3 / include -arch x86_64 -I / anaconda3 / lib / python3.6 / site -packs / torch / include -I / anaconda3 / lib / python3.6 / site -pack / torch / include / torch / csrc / api / include -I / anaconda3 / lib / python3. 6 / حزم الموقع / torch / include / TH -I / anaconda3 / lib / python3.6 / site -packs / torch / include / THC -I / anaconda3 / include / python3.6m -c src / module.cpp -o build / temp.macosx-10.7-x86_64-3.6 / src / module.o -g -stdlib = libc ++ -std = c ++ 11 -DTORCH_API_INCLUDE_EXTENSION_H -DTORCH_EXTENSION_NAME = cpp
gcc: خطأ: خيار سطر أوامر غير معروف "-stdlib = libc ++"

خطأ: فشل الأمر "gcc" مع حالة الخروج 1

2. عندما أستخدم clang لتجميعها ، فإن الأخطاء هي:

في ملف مضمن من src / module. cpp: 2 :
في الملف المضمن من src / CPUComplexType.h: 60:
src / CPUComplexTypeImpl.h: 102: 105: تحذير: تم إهمال "IntList" [-Wdeprecated- الإعلانات]
Tensor & CPUComplexType :: set_ (Tensor & self، Storage source، int64_t storage_offset، IntList sizes، IntList strides) const {
^
/anaconda3/lib/python3.6/site-packages/torch/include/c10/util/ArrayRef.h:273:7: ملاحظة: تم وضع علامة "IntList" صراحةً هنا على أنها مهملة
باستخدام IntList C10_DEPRECATED_USING = ArrayRef؛
^
في ملف مضمن من src / module. cpp: 2 :
في الملف المضمن من src / CPUComplexType.h: 60:
src / CPUComplexTypeImpl.h: 105: 76: خطأ: لا يوجد عضو باسم "scalarTypeToDataType" في مساحة الاسم "في"
auto source_ = check_storage (المصدر ، "المصدر" ، 2 ، DeviceType :: CPU ، في :: scalarTypeToDataType (CPUComplexTypeInfo :: scalar_type)) ؛
~~~~ ^
إنشاء 7 تحذيرات وخطأين.

خطأ: فشل الأمر 'clang' مع حالة الخروج 1

لا أستطيع إصلاحه. وأنا آمل حقا يمكنك مساعدتي!

مرحبا شباب،

شكرا لملاحظاتك. أعتقد أنه يمكنني قضاء الأسبوع في البحث في هذا. لقد جمعت حتى الآن مجمع pytorch @ Roger-luo على النحو التالي:

@ Zellar209 : لقد قمت بإرفاق متغيرات بيئتي التي تعمل على نظام macOS 10.13.

1. حذف توزيع pytorch الموجود على النحو التالي
   كوندا إلغاء pytorch
   نقطة إلغاء تثبيت الشعلة
   pip uninstall torch # قم بتشغيل هذا الأمر مرتين
   إعداد python.py نظيف
   احذف مجلد torch في مجلد حزم مواقع python إذا كان موجودًا.
   إعادة تسمية (أو حذف) مجلد مصدر pytorch السابق (شيء ما كان يشير إليه).

2. قم بتثبيت مراجعة PyTorch 6cb593b88cb0c411690b4957850058329526d87b.

    git clone [email protected]:pytorch/pytorch.git
    git checkout 6cb593b88cb0c411690b4957850058329526d87b
    git submodule update --init —recursive
    export CMAKE_PREFIX_PATH=${CONDA_PREFIX:-"$(dirname $(which conda))/../“}
    MACOSX_DEPLOYMENT_TARGET=10.13 CC=clang CXX=clang++ python setup.py develop
    python

>>> import torch

1. تثبيت مجمع pytorch

    python setup.py install
    python setup.py build
    python setup.py test
    # ERROR: test (unittest.loader._FailedTest)
    # ERROR: test_scalar_binary_op (tests.test_tensor.TestComplexTensor)

1. إنشاء موتر معقد

   from torch_complex import torch
   a = torch.ones(3, dtype=torch.complex128)
   a*a  
   RuntimeError: promoteTypes with complex numbers is not handled yet; figure out what the correct rules should be

ezyang ، @ Roger-luo:

يبدو أن كل شيء من أجل ترقية النوع لعمليات الموتر يتم في c10 / core / ScalarType.h
لقد وجدت الخطأ AT_ERROR("promoteTypes with complex numbers is not handled yet; figure out what the correct rules should be”);
يبدو أنه يجب علي إضافة إدخال لـ c8 و c16 داخل هذا الجدول.
هل هذا له علاقة بـ 9515 ؟ أعتقد أن هذا مخصص فقط لاستدعاء الدوال المعقدة.
هل هذا مكان جيد للبدء؟

9515 لا علاقة لها. ومع ذلك ، يعد إصلاح مسار الشفرة هذا في ScalarType.h مكانًا جيدًا للبدء.

لقد أصلحت مسار الشفرة في ScalarType.h
تعمل BinaryOps (add، sub، mul، div) ، ولكن فقط إذا كانت كلتا الوسيطتين من Tensors.
بعض القضايا الغريبة الأخرى ، لكني بحاجة إلى إلقاء نظرة عليها أكثر.

dylanbespalko لقد أضفت نوع الترقيات هنا: https://github.com/pytorch/pytorch/pull/11641

يمكنك فقط نسخ ذلك ، لكن المشكلة هي أن هذا يكسر CUDA بطريقة ما.

IIRC ، كان هناك خطأ سلكي بسبب إصدار دول مجلس التعاون الخليجي. كان لدي بعض الحلول هناك.

آه ، شكرًا @ Roger-luo. كنت أنظر إلى تعليقات # 11641 . سأقوم بعمل أفضل لنسخ الكود غدًا.

كيف أعرف أنني كسرت CUDA عندما لا أمتلك جهاز CUDA؟ أفترض أن المخابرات المركزية ستخبرني؟

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

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

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

مرحبا شباب،

حاولت إجراء العديد من العلاقات العامة بعد نسخ العديد من التزامات @ Roger-luo. لسوء الحظ ، ليس لديّ CUDA GPU في الوقت الحالي ولا يتم تهيئة أجهزة CI المزودة بـ CUDA. لا يمكنني إعادة إنشاء فشل اختبار CUDA في الوقت الحالي ، لذا سأعود إلى هذا في غضون أسابيع قليلة عندما يمكنني التشغيل محليًا على وحدة معالجة الرسومات هذه. تبدو واعدة على الأقل.

ezyang ، @ Roger-luo

لقد ألقيت نظرة على Roger's PR # 11641 :

• إنه يبني ويعمل على جهاز CUDA 9.0 الخاص بي
• فشل في البناء على أجهزة CI التي تقوم بتشغيل CUDA 9.0

لقد ألقيت نظرة أيضًا على بعض التطورات الأخيرة في PyTorch:

• عرض تقديمي من ezyang يصف كيفية كتابة امتداد C ++ / CUDA يمكنه تحديد جهاز / تخطيط / نوع مخصص .
  
  
  
  • أحدث رقم PR # 21964 والذي "يزيل ComplexHooksInterface" ، لكنه يحدد رقمًا معقدًا امتداد C ++ الموجود في pytorch / test / cpp_extensions / complex_registration_extension.cpp
  
  

يبدو لي أنه يتم تطوير قدرة تمديد جديدة "خارج الشجرة" ، والتي من شأنها أن تسمح لي بالتحقيق في دعم الأرقام المعقدة دون كسر بقية pytorch. هدفي هو:

1. تحديد دعم وحدة المعالجة المركزية المعقدة بدون AVX.
2. حدد دعم CUDA المركب باستخدام Thrust.

تضمين التغريدة
هل يمكنك تقديم مخطط زمني متوقع لملحق الجهاز / التخطيط / النوع الذي قدّمته خارج الشجرة؟ هل يمكننا توقع هذه الميزة في الأشهر الثلاثة القادمة؟

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

هل أنت قادر على دمج دعم الأرقام المعقدة على وحدة المعالجة المركزية بدون دعم AVX / SSE؟ أخطط لإرسال ما يلي في طلبات دمج منفصلة:

• [] تمت إضافة دعم معقد لنواة CPU BinaryOp
• [] تمت إضافة دعم معقد لوحدة المعالجة المركزية TensorFactories
• [] تمت إضافة دعم معقد لوحدة المعالجة المركزية FillKernels
• [] تمت إضافة دعم معقد لنواة نطاق وحدة المعالجة المركزية
• [] تمت إضافة دعم معقد لنواة وحدة المعالجة المركزية Unary
• [] تمت إضافة دعم معقد لنواة مقارنة وحدة المعالجة المركزية
• [] تمت إضافة دعم معقد لنواة CPU TensorCompare
• [] تمت إضافة دعم معقد لنواة CPU ReduceOp
• [] تمت إضافة دعم معقد لنواة CPU PointwiseOps
• [] تمت إضافة دعم معقد لنواة learpOps لوحدة المعالجة المركزية
• [] تمت إضافة الدعم المعقد لنواة الجبر الخطي لوحدة المعالجة المركزية
• [] تمت إضافة دعم معقد لنواة CPU SpectralOps

أخطط لاختبار هذا عبر intel / arm cpus في اليومين المقبلين.

ezyang ،

أنا أبحث في عمليات مثل fft() و var() حيث يجب أن يحول تنفيذ العدد المركب بيانات الموتر إلى موتر مزدوج للشكل: (complex_shape, 2) . هذا لا يعمل مع أي من طرق الموتر الحالية:

1. 'tensor.to (torch.float64): يحتفظ فقط بالجزء الحقيقي ، ويعيد موترًا بنفس الشكل.
2. 'tensor.view (new_shape): يجب أن يحتوي الشكل الجديد على نفس عدد العناصر.

من الواضح أنني أستطيع فعل شيء غير فعال مثل:

def to_float(tensor):
    return th.stack((tensor.real().type(th.float64), tensor.imag().type(th.float64)), -1)

def to_complex(tensor):
    tensor = tensor.type(th.complex128) 
    return tensor[..., 0] + 1j*tensor[..., 1]

من الواضح أن هذا هو إنشاء نسخ ، عندما يكون كل ما أحتاجه هو static_cast<double> وتغيير شكل الموتر إلى (old_shape, 2) . هل لديك أي اقتراحات حول كيفية القيام بذلك؟

أيضًا ، هناك اختراق في numpy يتيح لك القيام بذلك:

a = np.array([1 + 1j], dtype=np.complex128)
a.dtype = np.float64  ## This works

a = torch.tensor([1 + 1j], dtype=torch.complex128)
a.dtype = torch.float64  ## This does not work

تعمل القدرة على ضبط نوع dtype حقًا في هذه الحالة ، ولكن قد لا يمكن التنبؤ بها.

بعض المعلومات الإضافية المتعلقة بتفسير عدد مركب على أنه مصفوفة بطول 2 من الأعداد الحقيقية. ما يلي صالح في C ++ 11.

لأي مؤشر لعنصر مصفوفة من الأعداد المركبة p وأي فهرس صفيف صالح i ، reinterpret_cast(p) [2 i] هو الجزء الحقيقي من العدد المركب p [i] ، و reinterpret_cast(ع) [2 i + 1] هو الجزء التخيلي من العدد المركب p [i]. (منذ C ++ 11)

أعتقد أن هذا يعني أنه من الممكن تحويل مستشعر معقد إلى جهاز استشعار حقيقي بالشكل (شكل_ مركب ، 2) ثم إجراء عملية بدون استدعاء real() و imag() التي خصصت ذاكرة جديدة.

dylanbespalko كنت خائفًا عندما تسأل عن هذا :) يعني الضمان std::complex أنه إذا كان لديك مؤشر البيانات std::complex<float>* ، فيمكنك تحويله بأمان إلى float* (تغمغم شديد التعرج) ثم قم بتمريره إلى أي شيء تستخدمه. إذا كنت تحتاج فقط إلى تنفيذ fft / var حيث يمكنك تمرير هذا المستوى المنخفض ، فسيكون ذلك أسهل.

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

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

1. نحن دائمًا نخصص المستودعات كنوع "غير موجه" في السؤال. لذلك بالنسبة للمجمعنخصص موتر عائم.
2. يُسمح بنوع الموتر بالاختلاف مع نوع التخزين ، ولكن فقط كمتغير متجه من النوع الأساسي

لست متأكدًا من مقدار الكود الذي يتعين علينا تغييره لجعل هذا الثابت يحدث بالرغم من ذلك.

ezyang ،

نعم كان هذا لا مفر منه ...

إذا كنت تحتاج فقط إلى تنفيذ fft / var حيث يمكنك تمرير هذا المستوى المنخفض ، فسيكون ذلك أسهل.

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

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

أتخيل أنه من النادر مشاهدة موتر باستخدام نوع آخر. لقد قمت بتطبيق طريقة set_dtype() لـ Tensor ، لكن حصلت على بعض الأخطاء. أنا أيضًا لم أقوم بتحديث الخطوات لتعكس التغييرات في الشكل. لست متأكدًا من سبب عمل إعداد dtype في numpy (هل هي مصادفة؟) ، ولكن عندما تقوم بتحميل البيانات إلى محول من رقمي إلى تمثيلي (DAC) ، غالبًا ما يتوقع أن تكون البيانات الحقيقية / التخيلية متداخلة. ربما يحفز ذلك الحاجة إلى فصل نوع الموتر عن نوع التخزين كما اقترحت.

سأتجنب القيام بذلك الآن. أنا متأكد من أن هناك اختناقات أخرى في الأداء بالنسبة لي.

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

ليس بالضبط ناقل الأمراض المنقولة جنسياً ، ولكني أتخيل شيئًا مثل هذا:

Tensor complex_tensor;
assert(complex_tensor.is_contiguous());
std::complex<float>* cp = complex_tensor.data_ptr<std::complex<float>>();
float* fp = reinterpret_cast<float*>(cp);
auto num_floats = complex_tensor.numel() * 2;

لقد طبقت طريقة set_dtype () لـ Tensor ، لكنني حصلت على بعض الأخطاء. أنا أيضًا لم أقوم بتحديث الخطوات لتعكس التغييرات في الشكل.

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

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

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

ezyang ،

لقد بدأت العبث بدعم عدد معقد من CUDA.

هناك نوعان من الخيارات الثنائية المتوافقة:

1. cuComplex : دعم أساسي جدًا ، إضافة ، فرعية ، مول ، div ، حقيقي ، صور الدعم.
2. التوجه :: معقد : استبدال استبدال std::complex الذي يدعم تخصيص ذاكرة الجهاز والمضيف.

يبدو أن حاوية الدفع :: المعقدة هي السبيل للذهاب. تقترح واجهة برمجة تطبيقات Thrust :: Complex أنه يمكن تخصيص حاويات thrust::complex<T> على ذاكرة المضيف والجهاز ، بينما لا يمكن تخصيص std::complex<T> إلا على ذاكرة المضيف:

__host__ __device__     thrust::complex< T >::complex (const complex< T > &z)  //thrust container
__host__    thrust::complex< T >::complex (const std::complex< T > &z) //stl container.

1. هل يشير هذا إلى أنه يجب على AT_DISPATCH_COMPLEX_TYPES تعيين using scalar_t = thrust::complex<double> بدلاً من using scalar_t = std::complex<double> ؟

2. كيف تقوم Pytorch تلقائيًا باستدعاء مكافئات CUDA لـ std::log لأنواع البيانات الحقيقية؟ كيف أعرف أن هناك مكافئًا لنواة الرياضيات في CUDA؟

1. أعتقد أن الصعوبة في استخدام thrust::complex<double> عالميًا لوحدة المعالجة المركزية و CUDA هي أننا لا نبني في الواقع ضد التوجه إذا كنت تقوم ببناء وحدة المعالجة المركزية فقط. أعتقد أن هناك مجموعة من الخيارات ؛ يمكننا طرح النوع المعقد الخاص بنا (على غرار الطريقة التي نلف بها نوع النصف الخاص بنا) ، أو يمكنك فقط إعادة تفسير طريقك نحو النصر ، لأن std::complex<> يتم تعريفه على أنه يحتوي على تخطيط ثنائي معين. الأمر متروك لك ، ولكن مجرد إعادة تفسير اختيار النوع بين الأنواع يبدو أسهل في الوقت الحالي.
2. لدينا الكثير من الرياضيات في THCNumerics.cuh ، فهل هذا يجيب على سؤالك؟

أثار iotamudelta مشكلة مع التوافق C ++ 11 في # 29547

الأمراض المنقولة جنسيا :: الحقيقي هو فقط constexpr من C ++ 14

إذا فهمت بشكل صحيح ، يجب أن يكون std::real() constexpr حتى يتمكن المترجم hcc من تجميع التعليمات لـ __device__ .

الحلول الممكنة:

1. ابحث عن طريقة أو وظيفة أخرى لتحويل complex<double> إلى double :
   
   
   
   • لا يعمل abs أيضًا: templateT abs (مجمع const& خ) ؛
   
   

1. ابحث عن طريقة لف الوظيفة:

   • يتم إجراء معظم المكالمات إلى std :: real في aten/src/ATen/native/cpu/zmath.h . مثال: استبدل inline w / constexpr :

     inline VALUE_TYPE real_impl (SCALAR_TYPE z) ->
     constexpr VALUE_TYPE real_impl (SCALAR_TYPE z)

     inline std::complex<float> real_impl <std::complex<float>> (std::complex<float> z) -> constexpr std::complex<float> real_impl <std::complex<float>> (std::complex<float> z)

     inline std::complex<float> real_impl <std::complex<double>> (std::complex<float> z) -> constexpr std::complex<float> real_impl <std::complex<double>> (std::complex<float> z)

لن يتم تجميع هذا لأنه لا يزال هناك استدعاء متداخل لـ std::real() وهو ليس constexpr .

3. إذا كنت تستخدم الأمراض المنقولة جنسيا :: معقدة:: real () بدلاً من std :: real () يبدو أن هذا متوافق مع C ++ 11.

1. أعتقد أنك تقول أنه بغض النظر عن ما أفعله ، فإن هذا الرمز هو UB حتى C ++ 14. هل هناك أي طريقة أخرى لتحويل std::complex<double> إلى double يفي بمتطلباتك؟

iotamudelta ، bddppq ، @ ezyang ،

لقد أضفت دعمًا لـ UnaryOps و BinaryOps المعقدة على CUDA thrust :: complex API ، لكني بحاجة إلى طرح بعض الأسئلة قبل إرسالها.

لقد حددت وظيفة القالب التي تسمح لك باستخدام أنواع البيانات المعقدة عند التعامل مع الأرقام المعقدة.
aten/src/ATen/native/cuda/zmath.cuh

#pragma once

#include <complex>
#include <thrust/complex.h>

namespace at { namespace native {
namespace {

template <typename TYPE>
struct ztype_cuda {
  using value_t = TYPE; // Complex template type
  using thrust_t = TYPE; // Equivalent thrust type
};

template <>
struct ztype_cuda<std::complex<float>> {
  using value_t = float;
  using thrust_t = thrust::complex<float>;
};

template <>
struct ztype_cuda<std::complex<double>> {
  using value_t = double;
  using thrust_t = thrust::complex<double>;
};

} // end namespace
}} //end at::native

ثم في aten/src/ATen/native/cuda/BinaryOpsKernel.cu
يستبدل:

void add_kernel_cuda(TensorIterator& iter, Scalar alpha_scalar) {
  AT_DISPATCH_ALL_TYPES_AND2(kHalf, kBool, iter.common_dtype(), "add_cuda/sub_cuda", [&]() {
    auto alpha = alpha_scalar.to<scalar_t>();
    gpu_kernel_with_scalars(iter, [alpha]GPU_LAMBDA(scalar_t a, scalar_t b) -> scalar_t {
      return a + alpha * b;
    });
  });
}

مع:

void add_kernel_cuda(TensorIterator& iter, Scalar alpha_scalar) {
  AT_DISPATCH_ALL_TYPES_AND_COMPLEX_AND2(kHalf, kBool, iter.dtype(), "add_cuda/sub_cuda", [&]() {
    using thrust_t = typename ztype_cuda<scalar_t>::thrust_t;
    auto alpha = thrust_t(alpha_scalar.to<scalar_t>());
    gpu_kernel_with_scalars(iter, [alpha]GPU_LAMBDA(thrust_t a, thrust_t b) -> thrust_t {
      return a + alpha * b;
    });
  });
}

أسئلة

1. ezyang : بالنسبة للأرقام غير المركبة ، فإن scalar_t و thrust_t من نفس النوع. ربما يمكنني استبدال اسم المتغير thrust_t بشيء أكثر ملاءمة للأرقام غير المعقدة ، مثل scalar_t_c ؟
2. يبدو أن مكتبة الدفع تمت الإشارة إليها على نطاق واسع في الكود:
   أ) bddppq : هل هناك سبب يدفعني لاستخدام cuComplex بدلاً من thrust::complex ؟
   ب) iotamudelta : تمت إزالة دفع الورك في ROCm2.7. هل يجب أن أستخدم hip_complex بدلاً من ذلك؟
   التوجه :: يبدو أن المركب يدعم وظائف أكثر من cuComplex .

واسمحوا لي أن أعرف ما هو رأيك.

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

لقد قمت بتحديث المناقشة حول std :: real (). هل يمكنك تأكيد أن الأمراض المنقولة جنسيا :: معقد:: real () من شأنه أن يحل المشكلة.

مرحبا dylanbespalko ،

أعتقد أن ما تشكو منهiotamudelta هو أن cast_and_store للأنواع المعقدة يفتقد C10_HOST_DEVICE ، سيكون هذا UB إذا تم تنفيذ مسار الكود هذا على وحدة معالجة الرسومات.

حاليًا ، تُستخدم أداة الصب الديناميكي هذه فقط في GPU TensorIterator ، ولا يتم استخدامها إلا عندما يكون هناك ترويج للنوع. نظرًا لأن هذا المركب لم يكن مدعومًا على GPU حاليًا ، فإن cast_and_store للأنواع المعقدة في الوقت الحالي لا يحتوي على المؤهل C10_HOST_DEVICE ويستخدم std::real وهو أمر جيد تمامًا لمضيف- وظيفة فقط. لا يوجد UB هنا لأنه غير مستخدم ولا يوجد ما يدعو للقلق.

ولكن نظرًا لأنك تريد إضافة دعم معقد إلى وحدة معالجة الرسومات ، فإن التعقيد مدعوم من خلال ترويج النوع كما يمكننا أن نرى في https://github.com/pytorch/pytorch/blob/master/c10/core/ScalarType.h#L398 - L420 ، يجب أن تكون حذرًا جدًا في مسار الشفرة هذا وهناك بعض التعديلات التي قد تحتاج إلى القيام بها لجعلها تعمل:

بالطبع ، تحتاج إلى إضافة C10_HOST_DEVICE كما يفعل iotamudelta في https://github.com/pytorch/pytorch/pull/29547 ، لكن هذا لا يكفي ، لأن مجرد إضافة C10_HOST_DEVICE بدون تغييرات أخرى لا يزال UB على C ++ 11 كما هو مذكور من قبل iotamudelta ، قد يكون الحل الجيد هو ما ذكرته: استخدم std::complex::real() لاستبدال std::real .

ولكن بعد ذلك ، إذا نظرت إلى الملف https://github.com/pytorch/pytorch/blob/master/c10/util/TypeCast.h ، فسترى داخل fetch_and_cast ، هناك شيء مثل:

#ifndef C10_HOST_DEVICE
    AT_FORALL_COMPLEX_TYPES(FETCH_AND_CAST_COMPLEX_CASE)
#endif

تم تعطيل مسار الرمز هذا في وحدة معالجة الرسومات. تحتاج إلى تمكينها وجعلها تعمل.

أيضًا ، لم أشاهد أي تحويل بين complex<float> و complex<double> داخل fetch_and_cast و cast_and_store . قد تحتاج أيضًا إلى إضافة التحويل لذلك. تأكد من إجراء اختبار شامل لتغطية هذه الوظائف لجميع أنواع dtypes.

نسخة إلى: ezyang @ و bddppq

أيضًا dylanbespalko ، من فضلك أرسل نسخة لي إذا كنت تجري أي تغيير على TypeCast.h في العلاقات العامة الخاصة بك.

حسنًا ، لدي بعض الأشياء الصغيرة التي يجب إصلاحها باستخدام torch.real() و torch.imag() على ARM ، لذلك سأصلح TypeCast.h وبعض الأشياء الأخرى أثناء تواجدي فيه. سأرسل نسخة إليكم يا رفاق في العلاقات العامة.

القيادة بالتعليق: smessmer ينقلنا إلى C ++ 14 ، وعندها لن يكون UB. نظرًا لأن هذا سيأتي قريبًا ، إذا كان UB لا يسبب مشاكل حقيقية ، فلن أقلق كثيرًا بشأنه.

ezyang : من الجيد أن تعرف. لا تزال معظم عناصر الطرف الثالث مثل Eigen تستدعي std::real() بشكل متحرّر للغاية.

بالنسبة للأرقام غير المعقدة ، فإن scalar_t و thrust_t من النوع نفسه. ربما يمكنني استبدال اسم المتغير thrust_t بشيء أكثر ملاءمة للأرقام غير المعقدة ، مثل scalar_t_c؟

لست متأكدًا جدًا ، ولكن يبدو أن scalar_t_c أقل وضوحًا من thrust_t (ما الذي يعنيه c أي حال؟) الأنواع المعنية هنا تبدو محددة تمامًا ، لذلك يبدو من الأفضل استخدام اسم يتحدث مباشرة عن النية.

حسنًا ، سألتزم بـ thrust_t . إذا قام أي شخص بالغوص في ztype_cuda<>() فعليه أن يكتشف على الفور أن scalar_t هو thrust_t للأنواع غير المعقدة.

يرجى الاطلاع على https://github.com/pytorch/pytorch/pull/29612

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

مرحبا sunilkpai ،

لديّ علاقات عامة مفتوحة يجب أن تدعم العمليات الثنائية والأحادية في CUDA: # 30295.

هناك مشكلة أخرى تتعلق بالانتشار العكسي. أعتقد أن مشتق المركب abs() يتم تعريفه بشكل مختلف عن الأعداد الحقيقية. لست متأكدًا مما يجب فعله حيال ذلك ، ولكن يتم تحديد المشتقات في tools/autograd/derivatives.yaml

أعتقد أن الأعداد المركبة /dz abs(z) = z/abs(z) . يمكن استخدام هذا للأرقام الحقيقية أيضًا ، ولكن من المحتمل أن يكون أبطأ من sgn(z)

dylanbespalko ربما تساعدك الجداول 4.1 و 4.2 و 4.3 في تقريري https://arxiv.org/pdf/1701.00392.pdf على تحديد المشتقات.

للمشتقات المعقدة (wirtinger calculus) ، هناك خياران.
حساب المشتق wrt z أو z المترافق.
أنا شخصيا أحب المشتق wrt z المترافق أكثر.
يبدو الأمر أكثر طبيعية لعمليات المصفوفة ولا يحتاج تحديث التدرج إلى اقتران.
تعريفهم هو:

• المشتق wrt z لـ z = x + jy : dJ/dz = dJ/dx -j dJ/dy
• المشتق wrt z.conj لـ z = x + jy : dJ/dz.conj = dJ/dx + j dJ/dy

من تعليقك ، افترض أنك تحسب المشتق wrt z في الوقت الحالي.
في هذه الحالة يكون المشتق هو d abs(z) / d z = z.conj / abs(z) . عندما تأخذ التعريف الآخر ، يمكنك اتباع اقتراح Randl .

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

إحدى العمليات الأخرى التي قد تكون مفيدة (خاصة للمشاريع في مساحة الفيزياء التي تتطلب دعمًا للأرقام المعقدة) هي معالج لمشغل exp() . في Tensorflow ، لدينا tf.exp(x + iy) = tf.exp(x) * (tf.cos(y) + 1j * tf.sin(y)) . هل هذا سهل التنفيذ في pytorch أيضًا؟

sunilkpai ، boeddeker ، Randl ،

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

حالة الأرقام المركبة مدعومة بشكل غير رسمي ويجب إضافتها عبر امتداد PyTorch:

• مجمع pytorch-cpu-strided
• مجمع pytorch-cuda-strided

يحتوي كل امتداد على شيئين:

• A .cpp يحتوي على أي تسجيلات ضرورية لنواة الرياضيات.
• مجلد test/ يحتوي على إصدارات مبسطة جدًا من البرامج النصية لاختبار pytorch.
  ابحث في نصوص الاختبار لمعرفة أي النواة مدعومة (ولماذا لا يدعمها الآخرون).

لماذا لا يمكنني طباعة موتر معقد على وحدة التحكم؟

• يحتوي كائن Tensor python على بعض تنسيقات الطباعة الجميلة التي تستدعي بعض الوظائف غير المدعومة.
  
  
  
  • يمكنك تعديل محتويات tensor.py لتجاوز تنسيق الطباعة.
  
  
  • أو يمكنك ببساطة تحويل موترات Pytorch إلى مصفوفات Numpy ثم طباعتها.
  
  

حالة المشروع الحالية:

• تغطية وحدة المعالجة المركزية جيدة جدًا.
  
  
  
  • يتم تنفيذ Kernels داخل PyTorch ضمن "aten / src / ATen / native / cpu / </li> <li>Complex number specific code is under 'aten/src/ATen/native/cpu/zmath.h
  
  
  • تسريع Intel AVX256 تحت عنوان "aten / src / ATen / cpu / vec256 /"
    
    
    
    
    
    • sunilkpai : لم أكن أعرف تحسين exp. هذا هو المجلد حيث تضيف ذلك.
    
    
    
    • أخبرني إذا كنت مرتاحًا لإجراء التغيير.
    
    
    
  
  
• تغطية GPU مقصورة على العمليات الثنائية والأحادية:
  
  
  
  • يتم تنفيذ Kernels داخل PyTorch ضمن "aten / src / ATen / native / cuda / * </li> <li>Complex number specific code is under 'aten/src/ATen/native/cuda/zmath.cuh
  
  
  • يتم استخدام أنواع البيانات thrust::complex<T> وهي تتضمن النواة المحسنة.
  
  

التطور الحالي:

• في انتظار نقل نواة TH المستندة إلى C إلى مجلد C ++ ATen.
  
  
  
  • وظيفة rand () ضرورية لنقل حالات الاختبار إلى اختبارات pytorch الداخلية.
  
  
  • لم يتم نقل بعض عمليات الفهرسة حاليًا.
  
  
  • يوجد حاليًا 168/1300 نواة رياضيات (أقل من 230 في أكتوبر) والتي يجب نقلها من TH إلى ATen.
  
  
• سأحاول إضافة دعم للأرقام المعقدة حيث تصبح هذه النوى متوفرة في ATen.

-

لعلمك. فيما يتعلق بالمشتقات المعقدة ، كان لدينا نقاش طويل في Julia ويتم تنفيذه الآن في ChainRules (انظر أيضًا: http://www.juliadiff.org/ChainRules.jl/dev/api.html#ChainRulesCore.Wirtinger) و Zygote الآن . بشكل عام ، يحتاج الناس فقط
\partial L/\partial adjoint(z) باعتباره التدرج اللوني (بالتعريف هو أسرع اتجاه انخفاض) ، لكن المشتق يختلف مثل \partial L/\partial z ، يجب إضافة واجهة إضافية ، إذا أردنا دعمًا كاملاً للرقم المركب AD . للحصول على القواعد التفصيلية ، يمكنك التحقق مما تم تنفيذه في ChainRules أو Zygote/lib (نظرًا لوجود قواعد عامة فقط ، لا توجد قواعد منفصلة للأرقام المعقدة لمعظم المشغلين ، تمرير للأشياء للخلف مثل matmul مكتوبة بتعريف عام مثل adjoint(A) * B )

لماذا لا يمكنني طباعة موتر معقد على وحدة التحكم؟
يحتوي كائن Tensor python على بعض تنسيقات الطباعة الجميلة التي تستدعي بعض الوظائف غير المدعومة.
يمكنك تعديل محتويات tensor.py لتجاوز تنسيق الطباعة.
أو يمكنك ببساطة تحويل موترات Pytorch إلى مصفوفات Numpy ثم طباعتها.

أعتقد أنني أصلحت جزءًا على الأقل من الطباعة في https://github.com/Roger-luo/pytorch-complex لتصحيح الأخطاء وما إلى ذلك في المقام الأول ، ولست متأكدًا مما إذا كان هذا سيساعد لأن السيد قد تغير كثيرًا في الماضي عام. يمكنك أن تأخذه فقط إذا كان مفيدًا ، فلن أعمل على هذا بعد الآن.

dylanbespalko أنا عديم الخبرة نسبيًا في الأجزاء الداخلية من pytorch ، على الرغم من أنني بدأت التعلم! يمكنني تصور محاولة هذا التغيير ، على الرغم من أنه بناءً على ما أراه في aten/src/ATen/cpu/vec256/* ، لست متأكدًا مما إذا كان ضروريًا نظرًا لأن السلوك الافتراضي لـ std :: exp (std :: complex) هو بالضبط ما ذكرته في تعليقي السابق: انظر ملاحظات https://en.cppreference.com/w/cpp/numeric/complex/exp . لست متأكدًا أيضًا من كيفية ترجمة هذا إلى تنفيذ عمليات التشغيل هذه في CUDA (والتي تبدو حاليًا محدودة بالواقع الحقيقي والصوري والاقتران والزاوية؟).

sunilkpai ،

لقد أضفت دعم AVX لـ exp() باستخدام المعادلة المقدمة.

لقد لاحظت أيضًا أن بعض الأشياء قد تم كسرها بسبب بعض التغييرات الأخيرة في PyTorch. لقد أصلحت هذه في # 30871.

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

هل هناك جدول زمني للانتقال من TH إلى ATen؟
هل هناك طريقة يمكنني من خلالها المساهمة ، بالنظر إلى حقيقة أنني لست على دراية جيدة بالأعمال الداخلية للبيتورش؟

لقد وجدت صيغة للنشر العكسي لـ svd المركب في ملف arxiv ويمكنني تنفيذ ذلك ، إذا أوضحت لي أين

شكرا لعملكم!

@ جاكوب-أونفريد

https://github.com/pytorch/pytorch/wiki/TH-to-ATen-porting-guide

يتم تنفيذ نواة TH في لغة C وهناك القليل من الاهتمام بإضافة دعم معقد هناك بسبب جميع مشكلات عد المرجع المتأصلة. يمكنك تتبع التقدم في aten/src/ATen/native/native_functions.yaml حيث يتم تسجيل كل نواة:

ابحث عن legacy::cpu::_th وقسم هذا الرقم على 3 على عدد نوى TH القديمة.
ابحث عن legacy::cpu::_thnn وقسم هذا الرقم على 3 لعدد نوى الشبكة العصبية القديمة في مدينة TH.

يتم عادةً تسجيل كل نواة بثلاث طرق مختلفة:
1. النواة العادية y = add (a، b)
2. النواة الموضعية a = add_ (a، b)
3. إخراج النواة add_out (أ ، ب ، خرج = ص)
يكون التنفيذ الفعلي دائمًا في Output Kernel ويستدعى الآخران هذه الوظيفة.

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

التحقق من مشكلة تتبع النقل https://github.com/pytorch/pytorch/issues/24507 ، وكذلك ccVitalyFedyunin

فيما يلي تحديث حالة بشأن دعم الرقم المركب كما هو مطلوب في # 32437. أعود للعمل على الدعم المتعلق بوحدة المعالجة المركزية اليوم.

دعم Autograd

• لم يكن لدي الكثير من الوقت لذلك.
• تم تنفيذ كل من angle() ، real() ، imag() ، conj() .
• سيتطلب abs() تطبيقًا منفصلاً للأرقام المركبة. (انظر الملاحظات من boeddeker و Randl أعلاه)

دعم الأجهزة

يتم تنفيذ دعم الرقم المعقد حاليًا خارج الشجرة. هذا ما يعنيه ذلك:

كود داخل الشجرة

• يتم تنفيذ العمليات الحسابية فعليًا داخل الشجرة (داخل شفرة مصدر PyTorch).
• لا تتحقق أي من اختبارات Pytorch داخل الشجرة من صحة دعم الأرقام المعقدة (لذلك تميل الأشياء إلى الانهيار).
• تقوم PyTorch بالترحيل من TH إلى ATen (# 24507).
  - نواة الرياضيات المطبقة في مدينة تي لا تدعم الأعداد المركبة.
  - فقط النواة المطبقة في ATen يمكنها دعم الأعداد المركبة.
• تحتاج إلى تثبيت ملحق PyTorch لتمكين النوع المعقد.

رمز خارج الشجرة

• يتم تنفيذ العديد من ملحقات PyTorch ويمكن استيعابها بسهولة في المستقبل:
• يحتوي كل امتداد على أربعة ملفات مهمة:
  
  
  
  • setup.py: بناء وتثبيت امتداد pytorch.
  
  
  • [CPU / CUDA / FPGA] ComplexType.cpp: تسجيل نواة الرياضيات مشابه لـ CPUType.cpp أو CUDAType.cpp
  
  
  • test / test_torch.py: حالات الاختبار القبيحة جدًا التي تشير إلى النوى التي تعمل ، وهي محدودة بدعم ATen.
  
  
  • test / test_autograd.py: اختبار وظائف autograd.
  
  

ملحقات PyTorch خارج الشجرة

1. cpu_strided_complex
   - [x] CopyKernel
   - [] TensorFactories (عشوائية th ، th_uniform ، th_normal)
   - [x] RangeFactories
   - [x] BinaryOpKernals
   - [x] UnaryOpKernels
   - [x] CompareOpKernels
   - [x] PowKernels
   - [x] ReduceOpKernels (th_min، th_max، بعض المعايير لا تحسب الاقتران المعقد)
   - [] IndexOpKernels (th_masked_select_bool ، th_set ، th_gather ، th_cat)
   - [x] PointwiseOps
   - [x] Lerp Ops
   - [] BlasOps (th_mv، th_mm، th_fmod، th_eig)
   - [] LinpackOps (يستخدم Blas)
   - [] SpectralOps (مدعوم ، لكنه يحتاج إلى عمل)
   
   
   
   1. cuda_strided_complex
      
      
      
      
      
      • [x] CopyKernel
      
      
      
      • [] TensorFactories (انظر مشاكل وحدة المعالجة المركزية)
      
      
      
      • [x] BinaryOpKernals
      
      
      
      • [x] UnaryOpKernels (Todo: إضافة زاوية ، حقيقية ، صور ، مقترنة)
      
      
      
      • [] قارنOpKernels (تودو)
      
      
      
      • [] ReduceOpKernels (رسائل خطأ بخصوص WARP_SIZE)
      
      
      
      • تصبح وحدة معالجة الرسومات صعبة بما يتجاوز الحسابات النقطية ، ولكن يمكن دعم وظائف إضافية
      
      
      
   
   
2. vitis_strided_complex
   
   
   
   • Xilinx Vitis عبارة عن منصة توليفية عالية المستوى من FPGA تدعم الخادم والأجهزة المضمنة.
   
   
   • صدر في أكتوبر 2019 (دعم محدود على الأرجح للأجهزة).
   
   
   • يجمع بين SDAccel (الخادم) و VIvado HLS (مضمن).
   
   
   • [] BinaryOpKernals (نهاية يناير)
   
   
   • [] UnaryOpKernels (نهاية يناير)
   
   
   • [] ReduceOpKernels (نهاية فبراير).
   
   
   • أضافت FPGA مؤخرًا كائنات متجهية تدعم فئة قالب Vec256 PyTorch
   
   
   • كان Vec256 هو الطريقة التي تمت بها إضافة الدعم المعقد إلى وحدة المعالجة المركزية ويبدو أنه الطريقة الأكثر طبيعية لتنفيذ مسافات التنسور $ C $ أو $ R ^ N $
   
   

المزيد من التحديثات حول هذه المشكلة: https://github.com/pytorch/pytorch/issues/33152

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

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

مرحبًا redwrasse ، شكرًا على التعليقات! لدينا حاليًا ملاحظة للأرقام المركبة التي تتحدث عن بعض أساسيات الشعلة والوظائف المعقدة المدعومة للتوترات المعقدة على المستوى الرئيسي
(تم تضمين معظمها في الإصدار 1.6) https://pytorch.org/docs/master/complex_numbers.html؟highlight=complex. هل يمكنك مشاركة الوظائف الأخرى التي تهتم بها؟ يسعدنا التحدث أكثر عن دعمنا الحالي وما هي خطة الإصدارات القادمة.

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

مرحبًا redwrasse ، شكرًا على التعليقات! لدينا حاليًا ملاحظة للأرقام المركبة التي تتحدث عن بعض أساسيات الشعلة والوظائف المعقدة المدعومة للتوترات المعقدة على المستوى الرئيسي
(تم تضمين معظمها في الإصدار 1.6) https://pytorch.org/docs/master/complex_numbers.html؟highlight=complex. هل يمكنك مشاركة الوظائف الأخرى التي تهتم بها؟ يسعدنا التحدث أكثر عن دعمنا الحالي وما هي خطة الإصدارات القادمة.

شكرًا @ anjali411 ، من الرائع رؤية هذه الوثائق ، لم أكن على علم بها من قبل. أعتقد أن المطلوب هو "الحالة الحالية للدعم الحالي لشبكات عصبية معقدة" في المقدمة وفي المنتصف ، ولكن اسمحوا لي أن أتطرق إليها ...

الأشخاص المهتمون بـ autograd المعقدة ، قد تكون مهتمًا بـ https://github.com/pytorch/pytorch/issues/41857 الذي يمس الاتفاقية التي ستتبعها PyTorch (JAX أو TF).