http://pastebin.com/Ec9ikKmn -> сложих проверките които каза но същият резултат

За съжаление не намирам къде е разликата. Пращам моя код, ако може да помогне https://gist.github.com/astambi/c7c373fe5a8993eadcf5d7c39a0b68c6

не е от това и времето и паметт са ок

Каква ти беше грешката когато от 91 направи 100. И кой тест беше грешен защото аз сега съм с 91 и ми е грешен втори.

При мен беше последния тест. И не даваше Х, а една иконка и пишеше "Лимит памет".

Иначе това е кода, с който изкарах 100 точки: http://pastebin.com/qVkJPmqH - не мога да ти кажа кое точно е помогнало, защото съм я решавал страшно много пъти задачата с различни комбинации.

Успех с коригирането!

преместих фор цикъла в addMany и ми даде 91, но друго не мога да се сетя

Добре ти най-добре си познаваш кода и можеби ще намериш грешката по- бързо от мен. Ето с този код работи.

 List<long> forAdd = new List<long>();
                    for (int i = 2; i < command.Length; i++)
                    {
                        int a = int.Parse(command[i]);
                        forAdd.Add(a);
                    }
                    numbers.InsertRange(index, forAdd); break;

Това е от моето решение. Ако го замениш с твоят код за addMany дава 100.

Виж че при теб имаш празни редове. Аутпута може да е верен но имаш един празен ред който не трябва да го има.

Наков и целият колектив винаги са наблягали на факта, че:

"Отговорът на задачата трябва дословно да отговаря на зададения изход в условието на задачата."

Всякакви редове, точки, запетайки и т.н. трябва да бъдат 1 към 1. 

В противен случай можете да си блъскате главата до безкрайност! :) 

така е ама при мен не е това, и още не мога да го мина този втори тест

Здравей! Разгледах твоя код и ето как мисля че може да се оптимизира:

Вместо да използваш Лист List<string> task за да прочетеш входа на командата можеш да използваш масив от стингове string[] task. Така ще бъде заделена по-малко памет за входа. Забелязах че използваш index два пъти, можеш да си го инициализираш само един път в началото на switch-case-а. За addMany командата използваш отново лист, може да се използва пак масив, защото дължината е ясна, а можеш и да работиш направо върху input-а във for-цикъла. За sumPairs пак можеш да работиш върху входния лист с числата вместо да създаваш нов и така ще се избегне голяма част от функционалното програмиране. Като цяло, забелязах че на много места употребяваш допълнителни методи които ти заемат повече памет. Бих ти препоръчал да си направиш собствени методи. Както каза и Наков повече писане(по-голям обем на кода), заема по-малко ресурси. Ето моето решение http://pastebin.com/LaVNitsb в Judge заема 16.88MB Това е с което мога да помогна. Успех!

Здравей,

По погрешка качих малко по-стара работна версия на кода, където нарочно бях инициализирал index променливата два пъти - исках да проверя дали това може да се прави ако се използват "{ }" скоби в тялото на всеки case. Това със сигурност не е е проблем, защото в последвалата версия изцяло премахнах подобни променливи, както и проверката дали 0 < index < input.Count, но това, уви, не намали количеството заделена памет.

Относно използването на списъци вместо масиви - правя го съвсем тенденциозно, защото искам да свикна с функционалността им. Във видеото от лекцията Наков уверяваше, че разликата в заемания ресурс е не повече от 5% (а в случая аз трябва да смъкна цял MB за да достигна memory target-а). Ако видя, че се доближавам до него - разбира се, и това ще направя. За sumPairs отначало работих точно с входния масив и резултатът не беше с нищо по-добър. Нарочно въведох допълнителен списък, за да избегна използването на RemoveAt() метода, който гълта повече памет (при всяко отстраняване на елемент следва преиндексиране), и това определено беше подобрение в сравнение с предходния submission в Judge-а.

Не разбирам частта за допълнителните методи - да не би да е нещо, което е било дискутирано на място (или съм пропуснал от видеото)? Примерно от кода, който си качил, с какво RemovesElement е по-добър от директното извикване на numbers.RemoveAt(index)? Нали в тялото си извиква точно този метод? Нещо не разбирам идеята... Също така, кодът, който annsta е качила по-горе не използва никакви собствени методи и когато го тествах мина с нещо от типа на 16.6-16.7MB! Той всъщност изглежда доста близък до това, което аз съм направил в моята програма (изключвайки частта с проверката дали input = "print") и все още не мога да разбера защо дава такава разлика!

Здравей отново. Поиграх си малко с твоя код и го сравних с този на annsta и стигнах до заключение че листовете ти заемат много ресурси, където можеш ако използваш масиви вместо листове заеманата памет пада драстично до 16,95MB.Тъй като всяка клетка от списъка съдържа указател към следващата клетка, то всеки елемент заема повече памет, отколкото би заемала клетката в масив. Когато информацията във всяка клетка е относително много, това не е проблем, но ако просто пазим по един int, то ние ще се нуждаем от поне двойно повече памет. Нашата имплементация ще е двусвързан списък, тоест ще имаме и още един указател към предходния елемент в списъка, което прави нещата дори по-зле в това отношение. Например във версията която си качил смених List<string> task със string[] task , и List<int> shifted със int[] shifted, и там където използваш List<int> tempList за sumPairs го направих без допълнителен лист, а директно работиш върху входния лист с числа. След промените го тествах в Judge и ми даде този резултат. Прав си че в моя случай RemovesElement извиква в тялото си numbers.RemoveAt(index), но това с изнасянето в метод го правя за да се тренирам :-).