Състезанието в неделя ще започне след като приключи изпитът във ФМИ. Това доколкото си спомням трябва да е около 15ч., така че обявявам начало в 15ч. Ако почнем по-късно всички ще сме прецакани, не само вие :)
Вярно е, но не носи утеха (Максим Горки - "Майка")
Като цяло го казваме така, състезанието може да започне най-рано в 15 часа. Но следователно ако трае 5 часа може да свърши в 20ч. (мале...) Тъйче ако някой закъснее има време до крайния час, не повече. Надявам се това вече да носи утеха. ;)
Тая т.нар. система за "тестване" на решенията ще работи ли на поправката. Защото аз докато траеше контролното успях да пробвам само едно от решенията си, на първата задача и то само на easy.
Задачите ги писах на Visual Studio 2003 и се компилираха на компютъра, а в spoj дават CE, което не е толкова учудващо, но предвид факта, че системата през 90% от времето не работеше, нямаше как да се провери.
Ако ще се държи така системата и другия път може ли поне да се дадат повече от един пример, за да може поне да проверим както трябва решенията си.
И друго ми беше странно. Аз така и не разбрах работата с постоянното напомняне да не се натиска F5. Ами аз и един F5 не можах да натисна понеже сайта даже не се и отваряше през по-голямата част от времето, да не говорим за изпращане на решение.
Задачите ги писах на Visual Studio 2003 и се компилираха на компютъра, а в spoj дават CE, което не е толкова учудващо, но предвид факта, че системата през 90% от времето не работеше, нямаше как да се провери.
Ако ще се държи така системата и другия път може ли поне да се дадат повече от един пример, за да може поне да проверим както трябва решенията си.
И друго ми беше странно. Аз така и не разбрах работата с постоянното напомняне да не се натиска F5. Ами аз и един F5 не можах да натисна понеже сайта даже не се и отваряше през по-голямата част от времето, да не говорим за изпращане на решение.
Прав си да мрънкаш за самото провеждане на състезанието, но за компилацията най-вероятно ти си си виновен. Предполагам, че си ползвал __int64 или нещо такова, което си е чисто Майкрософтско. Това сме го говорили на практикумите, а и на двете контролни по практикум имаше задачи, за които се налагаше да ползват големи типове. На spoj0 върви gcc, което принципно предпочита long long. Доцент Манев още в началото ви каза, че е силно препоръчително да идвате на практикум. Разбира се той основно е имал предвид за да научите алгоритмите, но също така и за да свикнете със състезанията и в частност тестващата система.
Ако не е бил такъв проблемът, ще се радвам да ми пратиш кода си, за да изясним точно за какво става въпрос.
Ако не е бил такъв проблемът, ще се радвам да ми пратиш кода си, за да изясним точно за какво става въпрос.
Ще има друг път точно защото системата се държа така сега. В този смисъл очевидно целта е т.нар. система за "тестване" да работи на поправката. Освен безсмислени въпроси и коментари може да давате някакви конструктивни предложения как да направим състезанието най-добре и така, че да ви хареса
Аз,както и да го мисля,единтственото решение е хората да не качват постоянно и да не помпат.Аз също събмитнах два пъти,но не се оплаквам.Имаше идея да се събмитва на групи,примерно след първия половин час spoj-a се пуска и ако стаите са 4-ри на всяка се дава по 15 минути.За един час човек ще реши една задача,да кажем да има един-двама с две,но като в стаята има 20 човека,това означава за 15мин spoj-a да обработи 20-25 задачи,което мисля,че е възможно.Така,хем на spoja му е леко,хем ние ще си обмисляма по-добре задачите.А иначе и аз съм "за" по-силните тестове на условията,за да си правим добри проверки.Това е моето мнение.Дерзайте :)
Доколкото знам проблемите на spoj0 са заявките към база данни, няма сесии нито proxy и за всеки refresh се задава нова заявка към вече немалката база. Това може да се оптимизира, но едва ли Мило или някой друг ще има време да се занимава с това до следващото контролно. Едно временно решение, е да се създаде нова база само за това състезание и по-този начин няма да има проблеми с натоварването (доколкото знам до преди няколко месеца, когато базата беше по-малко spoj0 се държеше доста по-добре). Другия вариант е да говорите с Цецо Богданов, да пусне "Корейската" система.
Поздрави,
Пресли
Ще може ли някой да даде тестовете. Интересувам се по-точно за А задача, която на състезанието беше решена от 1 човек, а сега виждам че още 2,3 са я решили, като всички са писали на C++.
Относно А-hard и аз имам една малка вметка, не знам заради бъг в spoj0 или заради бъг в gcc/g++4.1.2, но получих wa на абсолютно верен код, в който броя тестовете с for, а като замених с while даде ok и хвърли мен и тези, с които споделих в абсолютно недоумение.
Може да погледнете:
http://milo0.no-ip.org/spoj0/status.pl?run_id=21394
http://milo0.no-ip.org/spoj0/status.pl?run_id=21322
Оказва се, че поради някаква причина променливата във for-а някъде не се променя с +1, а с +2 и се изпуска последния тест (и не, не я ползвам никъде другаде тази променлива, не я променям, и да, вкъщи компилирах с g++ -O2).
Иначе ако дава tl, не е от java със сигурност, защото авторовото решение е на java.
Може да погледнете:
http://milo0.no-ip.org/spoj0/status.pl?run_id=21394
http://milo0.no-ip.org/spoj0/status.pl?run_id=21322
Оказва се, че поради някаква причина променливата във for-а някъде не се променя с +1, а с +2 и се изпуска последния тест (и не, не я ползвам никъде другаде тази променлива, не я променям, и да, вкъщи компилирах с g++ -O2).
Иначе ако дава tl, не е от java със сигурност, защото авторовото решение е на java.
gcc не увеличава управляващата променлива с 2 ако му е зададено нещо от типа:
for (int i = 0; i < 10; i++), т.е. има ли i++ се увеличава с 1
Възможно е да се омазва някъде паметта и да се омазва стойността на тази променлива, но gcc по никакъв начин няма да направи това, което казваш ако всичко друго е наред.
for (int i = 0; i < 10; i++), т.е. има ли i++ се увеличава с 1
Възможно е да се омазва някъде паметта и да се омазва стойността на тази променлива, но gcc по никакъв начин няма да направи това, което казваш ако всичко друго е наред.
Сега разгледах двата сорса, които си посочила.
Първото решение, което дава WA печата номера на теста вместо отговора...
Второто дава верните отговори, само че и двете се почупват като ги компилирам с Visual Studio понеже двата големи масива са вкарани в main функцията. Това понапълва стека и всичко се чупи. Явно на сървъра стека е по-голям с този компилатор, с тази ОС...
Все пак на практикума няколко пъти сме коментирали, че трябва да се внимава колко са големи локалните променливи, за да не умре стека.
Та, нещо аз ли не разбирам или за пореден път ставам свидетел на напълно неаргументирани оплаквания относно сподж, задачите и т.н.???
Първото решение, което дава WA печата номера на теста вместо отговора...
Второто дава верните отговори, само че и двете се почупват като ги компилирам с Visual Studio понеже двата големи масива са вкарани в main функцията. Това понапълва стека и всичко се чупи. Явно на сървъра стека е по-голям с този компилатор, с тази ОС...
Все пак на практикума няколко пъти сме коментирали, че трябва да се внимава колко са големи локалните променливи, за да не умре стека.
Та, нещо аз ли не разбирам или за пореден път ставам свидетел на напълно неаргументирани оплаквания относно сподж, задачите и т.н.???
Дам, извинявам се run-а е http://milo0.no-ip.org/spoj0/status.pl?run_id=21323.
Никой не понапълва стека, а се оказва че: променливата tests е заделена точно след масива found[20000] (в който няма да обяснявам какво държа, защото да не подскажа на колегите решението ;) ). И така първия ми елемент на редицата е a и казвам разбира се found[a]=1.
ЗАЩОТО В УСЛОВИЕТО ПИШЕ 1<=a<20000, ПИШЕ СТРОГО ПО-МАЛКО.
В 4ТИЯ ТЕСТ a=20000. Това прави found[20000]=1, но found стига до индекс 19999, на мястото found[20000] е tests. т.е след края на 4тия тест имам tests=1, и като направи следващата проверка брояча t след 4тия тест е 4 и не минава условието t<tests и не минава през последния тест.
На java това сигурно дава re, защото пипаш извън масива, но на gcc ти позволява (което не е бъг, а се прави целенасочено, за хора, които знаят какво правят) и явно част от стратегията на версия 4.1.2. е последователното заделяне (вкъщи версията ми е 4.3 и тестовете минаха, там може би има промени в заделянето).
Така или иначе тестовете (или условието) са некоректни.
Надявам се да съм аргументирала оплакването си.
P.S. Много благодаря на колегата Кирил Калчев за помощта :)
Никой не понапълва стека, а се оказва че: променливата tests е заделена точно след масива found[20000] (в който няма да обяснявам какво държа, защото да не подскажа на колегите решението ;) ). И така първия ми елемент на редицата е a и казвам разбира се found[a]=1.
ЗАЩОТО В УСЛОВИЕТО ПИШЕ 1<=a<20000, ПИШЕ СТРОГО ПО-МАЛКО.
В 4ТИЯ ТЕСТ a=20000. Това прави found[20000]=1, но found стига до индекс 19999, на мястото found[20000] е tests. т.е след края на 4тия тест имам tests=1, и като направи следващата проверка брояча t след 4тия тест е 4 и не минава условието t<tests и не минава през последния тест.
На java това сигурно дава re, защото пипаш извън масива, но на gcc ти позволява (което не е бъг, а се прави целенасочено, за хора, които знаят какво правят) и явно част от стратегията на версия 4.1.2. е последователното заделяне (вкъщи версията ми е 4.3 и тестовете минаха, там може би има промени в заделянето).
Така или иначе тестовете (или условието) са некоректни.
Надявам се да съм аргументирала оплакването си.
P.S. Много благодаря на колегата Кирил Калчев за помощта :)
Дам, така разбирам! Еми, не знам какво да кажа... съжалявам много. Ще трябва да кажем на автора на задачата това нещо да има предвид.
Все пак ако може да дам някакъв съвет е да не слагаш толкова много данни като локални и съответно в стека. Другото е да не разчиташ на бъгове в gcc от подобен род, най-често се намазва паметта, когато променливите странно сменят стойностите си. И да допускаш, че хората, които ти дефинират условието са пропуснали това онова. :(
Все пак ако може да дам някакъв съвет е да не слагаш толкова много данни като локални и съответно в стека. Другото е да не разчиташ на бъгове в gcc от подобен род, най-често се намазва паметта, когато променливите странно сменят стойностите си. И да допускаш, че хората, които ти дефинират условието са пропуснали това онова. :(
Благодаря много за съветите, само ще отбележа, че това все пак не беше бъг в gcc и че в крайна сметка това е нашия устен изпит и точността трябва да е и от двете страни :) И понеже виждам че доста колеги са submitвали на състезанието, може би ще е добре да промените теста и да им rejudgeнете решенията 
Мисля, че оправих теста. Само че мисля да пусна rejudge през нощта, че иначе сега хората събмитват и сподж ще се сбози пак за известно време.
Направих най-накрая rejudge, обаче ми се струва, че има само един човек с ok сега. Не знам дали е отпреди това или се е появил сега. Ако има други, на които им дава wrong answer само заради некоректния тест моля да кажат.
Hi. Аз само да попитам, знае ли някой точно колко точки трябва да се съберат сумарно от двете контролни за различните оценки.
Благодаря предварително.
Благодаря предварително.
Еми погледна ли този документ: https://learn.fmi.uni-sofia.bg/mod/resource/view.php?id=2856
Има го сложен в първа седмица за курса. Смятам, че тези оценки е доста вероятно да се запазят така, понеже имахме 10 седмици с домашни. Имахме и двете състезания. Можеби трябва да видим от второто състезание коя задача ще броим като контролно от едната седмица, нещо за динамично беше.
Та, май това е положението. Обаче предполагам, че може да има някакви допълнителни неща за дооформяне.
Има го сложен в първа седмица за курса. Смятам, че тези оценки е доста вероятно да се запазят така, понеже имахме 10 седмици с домашни. Имахме и двете състезания. Можеби трябва да видим от второто състезание коя задача ще броим като контролно от едната седмица, нещо за динамично беше.
Та, май това е положението. Обаче предполагам, че може да има някакви допълнителни неща за дооформяне.