Jgrapht: تقلل من قيمة فيبوناتشي هيب

أود أن أقوم بمقارنة الأداء

لقد أجريت مقارنة الأداء ، ها هي النتائج
كومة فيبوناتشي الأصلية

| نوع الاختبار | ديكسترا ، الولايات المتحدة / المرجع | أقرب مكرر أول ، us / op |
| --------------------- | ------------------- | ------- ------------------------ |
| أكمل 100 | 165 | 165 |
| أكمل 300 | 1903 | 1920 |
| أكمل 500 | 9799 | 9526 |
| أكمل 1000 | 54701 | 54474 |
| مثلث. 1000 | 507 | 510 |
| مثلث. 3000 | 1702 | 1695 |
| مثلث. 5000 | 3399 | 3329 |
| مثلث. 10000 | 7420 | 7386 |
| مثلث. 20000 | 17138 | 16867 |
| مثلث. 40000 | 38579 | 38707 |

JHeaps فيبوناتشي كومة

| نوع الاختبار | ديكسترا ، الولايات المتحدة / المرجع | أقرب مكرر أول ، us / op |
| --------------------- | ------------------- | ------- ------------------------ |
| أكمل 100 | 172 | 173 |
| أكمل 300 | 2013 | 1984 |
| أكمل 500 | 11371 | 10108 |
| أكمل 1000 | 56411 | 56650 |
| مثلث. 1000 | 455 | 464 |
| مثلث. 3000 | 1534 | 1595 |
| مثلث. 5000 | 2927 | 3100 |
| مثلث. 10000 | 6985 | 6892 |
| مثلث. 20000 | 15904 | 16159 |
| مثلث. 40000 | 35970 | 36313 |

JHeaps الاقتران كومة

| نوع الاختبار | ديكسترا ، الولايات المتحدة / المرجع | أقرب مكرر أول ، us / op |
| --------------------- | --------------------- | ----- -------------------------- |
| أكمل 100 | 166 | 165 |
| أكمل 300 | 2017 | 2163 |
| أكمل 500 | 12015 | 11453 |
| أكمل 1000 | 61985 | 63824 |
| مثلث. 1000 | 373 | 375 |
| مثلث. 3000 | 1224 | 1227 |
| مثلث. 5000 | 2637 | 2895 |
| مثلث. 10000 | 5840 | 5941 |
| مثلث. 20000 | 15251 | 15217 |
| مثلث. 40000 | 30799 | 33975 |

الفرق في الأداء ليس بهذه الضخامة.

لا يمكنني حاليًا إجراء الاختبارات باستخدام كومة جذر مزدوجة أحادية اللون. والسبب هو أنه يطرح استثناء. يحدث هذا عندما نقوم أولاً بإدخال قمة البداية بمسافة 0 (currentMin = 0) ، ثم نزيلها (الآن CurrentMin في الكومة فارغة) ، ثم ندخل عقدة بها بعض المسافة k (currentMin تصبح k) ثم أدخل عقدة بمسافة م <ك (تم طرح استثناء بسبب k <م). يُذكر في ويكيبيديا أن "الشرط الضروري والكافي في قائمة انتظار الأولوية الرتيبة هو أن الشخص لا يحاول أبدًا إضافة عنصر له أولوية أقل من العنصر الذي تم استخراجه مؤخرًا". أعتقد أن القيمة currentMin لا يجب أن تصبح فارغة بعد إزالة الرأس بمسافة 0 ولكن في الكود ، تم التعليق عليه كحالة خاصة ، لذلك لست متأكدًا مما إذا كان هذا صحيحًا.

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

إذا أعدت كتابة Dijkstra قليلاً ، فيجب أن تعمل. أعتقد أنك تحتاج أولاً إلى الاتصال بـ findMin() ، ثم تخفيف الحواف وأخيراً delMin() .

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

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

Toptachamann لقد غيرت التنفيذ ويجب أن يعمل الآن خارج الصندوق. لم أقم بإصداره ، لذا سيتعين عليك اختبار الإصدار 0.9-SNAPSHOT بعد التثبيت محليًا باستخدام تثبيت maven.

@ d-michail الآن لا يعمل كذلك. بعد حذف رأس البداية ، يصبح فهرس المجموعة الخاص به -1 ، ولكنه يظل الحد الأدنى الحالي. بعد إرخاء جميع الحواف الصادرة ومحاولة حذف عنصر حد أدنى آخر ، يتم طرح java.lang.ArrayIndexOutOfBoundsException: -1 .

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

فيما يلي نتائج الكومة الرتيبة المزدوجة:

| نوع الاختبار | ديكسترا | أقرب مكرر أول |
| -------------------------------- | ---------------- | ------------------------ |
| أكمل 100 يصل. ب. 10 | 172 | 172 |
| أكمل 300 حتى. ب. 10 | 2458 | 2408 |
| أكمل 500 حتى. ب. 10 | 11104 | 10052 |
| أكمل 1000 حتى. ب. 10 | 57028 | 56944 |
| أكمل 100 يصل. ب. 100 | 185 | 175 |
| أكمل 300 حتى. ب. 100 | 2381 | 2464 |
| أكمل 500 حتى. ب. 100 | 11320 | 11313 |
| أكمل 1000 حتى. ب. 100 | 64749 | 61865 |
| أكمل 100 يصل. ب. 1000 | 190 | 180 |
| أكمل 300 حتى. ب. 1000 | 2315 | 2303 |
| أكمل 500 حتى. ب. 1000 | 11034 | 11792 |
| أكمل 1000 حتى. ب. 1000 | 65407 | 68292 |
| أكمل 100 يصل. ب. 10000 | 186 | 193 |
| أكمل 300 حتى. ب. 10000 | 2390 | 2359 |
| أكمل 500 حتى. ب. 10000 | 12667 | 14156 |
| أكمل 1000 حتى. ب. 10000 | 72096 | 71001 |
| مثلث. 1000 | 418 | 418 |
| مثلث. 3000 | 1347 | 1349 |
| مثلث. 5000 | 2426 | 2486 |
| مثلث. 10000 | 6798 | 6559 |
| مثلث. 20000 | 16375 | 16257 |
| مثلث. 40000 | 36574 | 36203 |

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

Toptachamann هل لديك فرع منشور يمكنني إلقاء نظرة عليه؟

jsichi لقد دفعت فرع المعيار إلى مفترقتي. هناك قمت فقط بقياس خوارزمية Dijkstra. هل يجب أن أفعل الإيقاف؟

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

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

يبدو أن أزواج أكوام Ps قيمة افتراضية معقولة نظرًا لأن الحد الأعلى لأوزان الحافة في معظم الأوقات لن يكون منخفضًا ولن يكون للأكوام الرتيبة ميزتها. لكنني سأدلي بملاحظة في التعليقات أنه من الجيد التفكير في استخدام أكوام رتيبة لخوارزمية Dijkstra في حالة أن نطاق الأوزان ليس كبيرًا.