Задачи -> Първа задача -> Предадени решения
Тук кликаш върху името на човека, чието решение искаш да видиш, като в общия случай искаш да има коментари към него, защото е много вероятно да прочетеш нещо от сорта: "това не се прави така", "опитай да замениш това с онова", "харесва ми как си направил/а това" и т.н. Така можеш сам да преосмослиш решението и стила си, а и мисля, че преподавателите ще бъдат доволни да не пишат всеки път на всеки едно и също ;)
Задачи / Първа задача / Предадени решения
Супер, благодаря ви и на двамата. Не бях забелязал този линк в началото. Въпрос към лекторите - ще правим ли по време на лекция "разбор" на най-често правените грешки в домашните/предизвикателствата?
P.S. И още един въпрос за performance - меродавни ли са тези времена за изпълнение? Имам предивд следното - като разглеждам предизвикателствата виждам идентични решения с различно време за изпълнение, както и по-дълги и включващи извикване на повече методи решения, които минават по-бързо от други, по-кратки. Знам, че меренето на performance е доста относително, но все пак бих искал да чуя и вашето мнение.
@Алекс, да, спокойно, ще има хейт по решенията 
.
Аз не бих имал много вяра на времената за изпълнение на тестовете. Най-малкото, защото тестовете се пускат асинхронно на сървър, на който се търкалят и други неща.
Ако толкова искаш да сравниш времената за изпълнение на някои функции, хвърли един поглед на Benchmark.
Объркал съм мястото на един символ в една от задачите си, поради което не са ми дадени никакви точки за цялото домашно. Ще може ли да го оправите? Мерси.
Имам контестация - губя 2 теста от домашното, понеже методът ми prime_factors time limit-ва. При мен работи за време ~1.5 сек. за двата теста, показани в log-а на решението, така че не е ужасяващо бавно. Ще ги пуснете ли отново с по-голям TL?
@Иван Георгиев, не, не става така. Заради "объркани символи" са падали ракети от небето. Качил си решение със синтактична грешка изцяло по твоя вина. Това със сигурност ще ти остане като добър урок и следващия път ще си много по-внимателен.
@Ясен Трифонов, прегледах решението ти и къде гърми. Отнема ти повече от една секунда да сметнеш 738.prime_factors (които са [2, 3, 3, 41]).
Всеки тест, който се изпълнява над вашия код, тества нещо дребно в него и има лимит от една секунда.
Въпреки, че не държим на производителност и не гоним всяка милисекунда в курса, не е окей да продуцирате решения, съдържащи очевидни и прекомерно бавни елементи, които могат да бъдат премахнати, запазвайки четимостта и яснотата на кода. Твоят prime_factors е интересен, обаче наистина е твърде неоптимален :) Надявам се си разгледал алтернативни решения, които колегите ти са предложили.
Плюс, res? :)
@Mitio Точно затова бях питал (в тази тема) до колко ще се гледа бързодействието на даден метод -- чудех се дали има нужда да си оптимизирам prime? (който впоследствие използвам и в prime_factors). И понеже това не е ПРАНКА, реших да се опитам да разуча повече ruby конструкции и да го реализирам като се възползвам максимално от тях.
Иначе можех да го имплементирам и по друг, по-бърз начин, но щеше да е досущ като кода, който бих ползвал и в останалите езици... А от решенията на колегите разбрах за умопомрачителната оптимизация в prime? да се цикли до self / 2. =) UPDATE: Твоят prime_factors е готин, исках да го реализирам така, но не се усетих за (abs / factor).prime_factors.
А за res -- реално не ми е нужна изобщо, трябваше ми нещо, в което да пазя последния ред. За толкова символи, колкото имах, това беше най-смисленото, което можех да напиша. Жалко, че няма дефинирано _ като в irb.
Принципно, _ си е валидно име на променлива, като понякога има и малко по-специално поведение. Но ти сам го казваш – "res не ми беше нужна изобщо". И това е ключът, сигналът, че трябва да потърсиш друго решение, да направиш завой от текущото си.
Относно "моето" решение, това всъщност е решението на Христо, който е и автор на задачата.
И последно, да – не сме ПРАНКА, но, човек – 1.5 секунди е МНОГО! :)
Тук съм с Митьо, нелепо е.
Да, наистина е нелепо. Имам представа какви задачи могат да се решат в рамките на 1.5 секунди. Проблемът ми не е във времето за изпълнение, а в това, че този критерий беше изцяло недефиниран. Съответно дори и да съм допуснал грешка (във времето за изпълнение), няма как да я забележа. За бъдещите задачи поне драснете едно изречение "ще го тестваме с числа до 1000 и трябва да работи до 1 секунда" след като го отчитате като грешка.
Продължавам да отговарям по темата, защото "именно в спора се разда истината" :) И понеже не искам това да става пълен спам за всички, искам да споделя и няколко предложения:
Единственото ми притеснение е, че макар и тези идеи да са добри и ефективни на практика, стигне ли се до оценка, вероятно ще има доста злоупотреби с тях.
@Ясен, първата ти идея е добра, даже доста добра. Иначе след няколко домашни трябва да се появи едно, наречено "Ретроспекция", което на пайтъна го имаше мисля, че и миналата година на руби пак са го давали. То цели точно анализирането на чужди, а и на свои стари решения. Втората обаче ми се струва малко неприложима.
ПП Съгласен съм с тебе, че трябваше да се спомене за ограничението от 1 секунда.
Ok, наясно сме, че това не е логическо програмиране => решения, които отнемат 1000 години за изпълнение не са решения. Но колегата изрично ви попита и отговорът беше напълно недвусмислен - "ако не сме казали изрично, не мислете за времето за изпълнение и/или заеманата памет". Още повече, че както той отбеляза, с "оптимизацията" /2 (която асимптотично не променя нищо) решението му щеше да мине.
@Никола и @Ясен - за едно нещо няма спор и това е, че наистина казах, че не трябва да мислите за производителността, без да упомена ограничението от една секунда на тест.
Затова, ще пусна тестовете с по-голямо времево ограничение и Ясен ще получи точките, които му се полагат.
В случая, грешката е моя, понеже не бях достатъчно ясен. За което се извинявам :)
А да попитам за примерното решение, което е дадено в Github: То не би ли трябвало да може да работи и за този тест?
[[1]].combine_with([1]).should eq [[1],1]
Yup, too much flatten...
Така би трябвало да работи:
def combine_with(other)
longer, shorter = self.length > other.length ? [self, other] : [other, self]
combined = take(shorter.length).zip(other.take(shorter.length)).flatten(1)
rest = longer.drop(shorter.length)
combined + rest
end
Дам така е супер :)
Не бях забелязал, че просто може да му се подава ниво
Трябва да сте влезли в системата, за да може да отговаряте на теми.