"Също да уточня, че съм решил всички задачи като основно ползвам LINQ и от към скорост на изпълнение не са много добре"

@DHristoskov,
Не му се притеснявай на линк, ползвай си го с кеф, защото е много лесен за писане и четене. Освен това е достатъчно бърз. Ако някоя програма трябва наистина да е хипер-гига бърза, може би не точно код, който върви върху виртуална машина е решението, така че линк ти е последната грижа.
 

@DHristoskov : Нещо Add методът на задача 7 LinkedList не работи правилно и връща с едно по-малко. Пуснах моите тестове върху твоя проект, защото видях, че си се постарал доста, обаче всичките гърмят заради Count пропъртито.

Не. Достатъчно е да използваш метода в конзолно приложение по такъв начин, че да е очевидна коректността му. Идеята е да е по-лесно за проверяващите на домашното и без да пишат допълнителен код за тестване да се убедят, че методът работи.

Мерси, ама то това го пише само за 3та задача, а другите?

Никъде не се изискват задължително Unit Tests. Обаче ти препоръчвам поне за имплементациите на двата списъка (зад. 6 и 7) да си направиш тестове. Аз си направих и бях изумен колко допълнителни неща трябваше да поправя по моята имплементация. 

Здравей,

Поздравления за мерака да правиш юнит тестове. Аз за пръв път ползвах такива в упражненията на лекцията. Не знам как точно се пишат и дали ще имаш възможност да добавиш следния тест, за да изгладиш един бъг, който смятам че имаш:

SingleIndexedLinkedList<int> list = new SingleIndexedLinkedList<int>();

list.Add(1);
        list.Add(2);  list.Add(3); list.Add(4); list.Add(5);list.Add(6); list.Add(7);
        // 1 2 3 4 5 6 7
        list.Remove(2);
        list.Remove(3);
        list.Remove(4);
        // 1 2 4 6
        list.Add(8);
        // 1 2 4 6
        list.Add(9);
        // 1 2 4 6 

Идеята е, че след като махнеш опашката листа ти си я "забравя" и трябва да му я припомниш. Преди това трябва да си махнал някои елементи по средата преполагам. Unit-ите сигурно тестват отделни поведения(поправи ме ако греша), което може да е предимство, но може и да е недостатък, защото когато работим динамично могат да се появят непредвидини комбинации.

Тази маневра с припомнянето не се налага при двусвързан списък. И при едносвързан може да се мине без нея, но цената е долу-горе същата или по-лоша.

Давам и моя вариант за задача 7 ако някой му се гледа и да каже слаби места

https://codeboard.io/projects/7127

@ dim4o : Много благодаря за корекцията. оправих грешката и добавих тест и за този случай. 

По въпроса за  юнит тестовете: Аз лично ги намирам за много полезни и виждам само една основателна причина да не се пишат - оскъпяват продукта и не всички клиенти искат да плащат за тестове.

Не конкретно по домашното, по друга задача обхождах в дълбочина с рекурсия и при по - голям обем (в случая директории обхождах) стека се препълваше и хвърляше ексепшън. На дажва се развива действието

Завизи какво си обхождал. В случая на зад.8  имаме граф с ниска степен на свързаност. Броят на възлите V=n^2, а на ребрата е Е=2n(n-1), следователно сложността е О(V + E) = O(3n^2-2n), което за малки n e ОК. Но ако имаш мн висока степен на сързаност и обхождаш нещо с мн разклонения ще зациклиш. Например при обхождане на хиперлинкове в нета ще завизнеш още на 2-3 ниво в дълбочина, а може и по-рано. А ако ти хвърля exception веднага това в повечето случай значи, че рекурсията няма дъно. Мисля, че компилаторите понякога се усещат още преди да са потънали докрай :). Такива са ми впечатленията на мен.

@dim4o: Чудесно стегнато решение на BFS задачата. Само едно нещо ми се струва да не си е на мястото. Мисля че маркирането на клетките с u, x и номера на стъпката не трябва да се случва в принт метода, а трябва да намери място в самия CalcDistance метод. Принтирането трябва да си е само принтиране.

Трябва да разкараш всички числа, които се повтарят нечетен брой пъти.

1 1 1 2 2 - разкарваш 1, резултат  2 2
1 1 2 2 - нищо не разкарваш

1 2 1 2 1 2 - и 1, и 2 се повтарят нечетен брой пъти, затова разкарваш всичко и в резултат не печатиш нищо

От подадените числа да определиш кои се срещат нечетен брой пъти в цялата последователност и да ги премахнеш

Във енумератора си ползвай this.Count вместо размера на обекта. 

Това ли имаш предвид: http://pastebin.com/HdPGJPrR. Сега цикъла ми връща:

0

0

Дебъгвах и достигнах да извода, че листа се създава с 4 нули - значи не е от енумератора, но не виждам от къде идва цялата работа.

По default стойноста на int променлива е 0, т. е. след като инициализираш списък или масив от int-ове и в него още не си записал никакви стойности, то на всички позиции се записва default-ната стойност за int - 0. Това условие this.elements[i] == null в твоя случаи не вярно, че да се break-не цикъла.

Тъй като списъкът по условие е reversed трябва да го циклиш отзад напред, когато имплементираш IEnumerator<T> GetEnumerator и не до Capacity а до броя записани елементи - Count

Ти не си забравил, ами времето не е нагласено правилно. Трябва да е до 12/07/2015 23:59:59