Java Fundamentals - минали изпити в judge - неясни условия

kosio197 104 Точки

Java Fundamentals - минали изпити в judge - неясни условия

Здравейте,

Започнах да решавам задачите от предишни изпити, тъй като ми предстои този изпит. Вече пуснах една тема с въпроси относно Dragon accounting от 4- октомври, тък като доста неща не са достатъчно ясно описани в условито. Пропуснах тази задача и реших другите от изпита. Минах на втората тема: "Java Fundamentals Retake - 26 October 2015" и започнах да гледам "TheHeiganDance". Условието отново е много не ясно, докарах го до 70 точки за момента, но без да гледам тестовете нямаше да стане. Та какво ми направи впечатление в условито:

1. On the next several lines – you receive input in format {spell} {row} {col} – {spell} is either Plague or Eruption - едното тук е, че spell изобщо не е Plague или Eruption, а е Cloud или Eruption (да речем, че това се разбира от нулевите тестове). Другото е, че за row и col няма никакви ограничения в какви граници могат да бъдат и като видиш тестовете (което на изпит няма как да се случи) виждаш, че може да излизат и извън границите на матрицата. (хайде да речем, че това може да го предположиш от този constraint : A damaging spell will always affect at least one cell)

2. "If the player’s current position is within the area of damage, the player tries to move." - да ама не, според един от тестовете излиза, че ако текущата магия не го удря, може да си стои там и то без да отнася демидж.

3. "If he cannot move in any direction, because the cell is damaged or there is a wall, the player stays in place and takes the damage." - още в нулеия тест се вижда, че не е така, това е само, ако текущата магия го удари централно, иначе и да има остатък от предишнен облак няма проблем да се премести.

Докато го докарам от 70 до 100 процента със сигурност ще има и още.

На мен ми се струва, че като цяло задачите от този курс са доста не ясно дадени, липсват ограничения, както и уточненията, нулевите тестове като цяло почти нищо не покриват от основните изисквания (все си мисля, че тряба да са малко повече, особенно при положение, че до сега не сме писали на java и това ни е 3-ти изпит като цяло в Софт Уни).

Аз лично срещам сериозни затруднения, не толкова с писането на кода, колкото с разбирането на подробностите около самата задача.

Тагове:

01/11/2015 03:15:43 Java Advanced

mgulubov 73 Точки

Привет,

Аргументите ти, в голяма степен, са недобре покрити.

1-1. "spell изобщо не е Plague или Eruption, а е Cloud или Eruption" - тук си прав, това е грешка в условието и ще е хубаво да се оправи.

1-2. "row и col няма никакви ограничения в какви граници могат да бъдат" - след като няма ограничение за стойностите, приемаш, че могат да бъдат всякакви. Ако си карал шофьорски курсове, когато наближиш кръстовище и инструктура не каже изрично на къде да продължиш, то следваш пътя с предимство.

За точки 2 и 3, наистина не схващам, какви точно са ти оплакванията.

2. Да, ако играча не попада в радиуса на магията, то той не се мести. Мести се само ако попада в радиуса на магията.Никъде в условието не се казва, че играча ще се мести на всеки ход. Ще се мести, само ако магията, която се каства в момента, може да го удари.

3. Остатъка от предишната магия, е към предишната магия. Щом играча не е успял да избяга от Cloud-a, то той реално ще бъде ударен два пъти - веднъж при кастването на магията и още веднъж на следващия ход, като остатъчния damage няма как да се избегне, понеже магията вече го е ударила на предишния ход.

Имай предвид, че като цяло е грешна практиката, винаги да търсиш проблема в нещо различно от себе си. Да, задачите не са лесни, но все пак това не е Programming Basics изпит. Също така, на изпита имаше доста хора, които решиха задачата на 100%, без да гледат тестовете. Ще ти помогне много, ако винаги се концентрираш върху това как да решиш проблема, вместо да отделяш толкова време да обвиняваш проблема, че не е достатъчно лесен :).

01/11/2015 10:29:20

kosio197 104 Точки

"Имай предвид, че като цяло е грешна практиката, винаги да търсиш проблема в нещо различно от себе си." - "винаги" е малко силна дума, в случая споделям мнение, което смятам, че засяга хората, които минават този курс като цяло. За първата задача, за която условието не беше достатъчно ясно просто отворих тема и си зададох въпросите там. Това обаче, което ми направи впечатление е че неясните условия не са еденичен случай и затова отварям темата - не с цел да се заяждам, а с цел повишаване на качеството на обучение в Софт Уни.

"Да, задачите не са лесни, но все пак това не е Programming Basics изпит. " "Ще ти помогне много, ако винаги се концентрираш върху това как да решиш проблема, вместо да отделяш толкова време да обвиняваш проблема, че не е достатъчно лесен"- Какво значи "лесни" ? - Една задача може да се разбере перфектно като условиве и пак да е трудна. Това, което на мен ми прави впечатление и заради което отварям темата е че "прочита" на условието се оказва по - труден от самата задача. От моя гледна точка решаването на една задача се свежда до 3 етапа:

1. Какъв точно е проблема който трябва да решим

2. Да измислим алгоритъмът за решението.

3. Да изберем подходящи структори от данни и типове в зависимост от ограниченията и да имплементираме алгоритама от точка 2.

Като 2 и 3 понякога може да са взаимно свързани.

Това, което забелязвам аз е, че най - трудното нещо в Java Fundamentals e точка 1. Аз мисля, че не това трябва да е основната идея. Смятам, че в момента се учим да програмираме, т.е. трябва да наблягаме на точки 2 и 3, а не както се налага в задачи като тази например, да четем условието отново и отново, да гледаме между редовете и накрая пак да стигаме до тестовете и това което намерим там като "грешка" в нашето решение да не го намираме изобщо в условито или да го намираме много скрито между редовете.

"Също така, на изпита имаше доста хора, които решиха задачата на 100%, без да гледат тестовете." - Не знам колко човека е имало на изпита, но гледам в момента "Dragon Accounting" - 12 човека, "TheHeiganDance" - 20 човека - което ми се струва доста малко в сравнение с Advanced C# темите примерно.

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

01/11/2015 11:54:59

RoYaL Trainer 6849 Точки

Няма как стилът на писане да обхване абсолютно всички. Все един ще разбира по-добре условието от друг. Така е с всичко написано. От романи, до условия на задачи. В крайна сметка, ако по време на изпит в цялата залата се окаже, че 80% от хората не разбират, че като някой кастне магия на определено място и нейният импакт засегне мястото, където се намира играча, той се мести, ако пак е на засегнато място - пак се мести, и ако пак е на засегнато място - се мести и накрая вече няма къде да ходи и си го бият като куче, то ще излезе някой отпред и ще го обясни ...

01/11/2015 23:25:32

sholeto 93 Точки

Има моменти с такива задачи. Аз имам проблем от тип "assuming logical things" - примерно предположих че на Dragon Accounting ще трябва да плащам изработените дни от месеца, когато уволнявам някой, въпреки че не е написано. Все пак са работили там няколко дена преди да ги уволнят. FAIL. На приемния изпит предположих, че брой на тренировки не може да е отрицателно число, въпреки че си беше написано в ограниченията. FAIL.

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

Ето един пример от Dragon Accounting:

The boss also pays salaries every 30 days. Assuming all 30 days are paydays, he pays salaries proportionally (e.g. an employee is hired on 20th day, when 30th day hits, he receives salary for 10 days. Daily salary should be computed to the 9th digit after the decimal separator up and then kept to the 7th digits after the decimal point without any rounding).  Formula for calculating total salary to receive is employee’s salary per day multiplied by the days the employee has worked that month. ((salary / 30) * totalWorkingDaysThatMonth)

което в моя случай се превежда в:

BigDecimal payment = salary
                    .divide(BigDecimal.valueOf(30), 9, BigDecimal.ROUND_UP)
                    .setScale(7, BigDecimal.ROUND_DOWN)
                    .multiply(BigDecimal.valueOf(monthWorkDays))
                    .multiply(BigDecimal.valueOf(numberOfEmployees));

Всичко си е написано, само дето нямаше по смъртно да го направя на изпит... Тази задача я решавах 3 дни и накрая пак трябваше да погледна чужди решения заради този детайл. FAIL.

Според мен целта на всичко това е да се отсеят не само добрите програмисти, ами и хората с внимание към детайлите. Шерлок кодърите. :D

01/11/2015 10:53:03