Решение на Log Parsing от Илия Ячев
Резултати
- 10 точки от тестове
- 0 бонус точки
- 10 точки общо
- 10 успешни тест(а)
- 0 неуспешни тест(а)
Код
Лог от изпълнението
PASS ok _/tmp/d20141023-10368-1amhcha 0.011s PASS ok _/tmp/d20141023-10368-1amhcha 0.011s PASS ok _/tmp/d20141023-10368-1amhcha 0.011s PASS ok _/tmp/d20141023-10368-1amhcha 0.012s PASS ok _/tmp/d20141023-10368-1amhcha 0.011s PASS ok _/tmp/d20141023-10368-1amhcha 0.011s PASS ok _/tmp/d20141023-10368-1amhcha 0.011s PASS ok _/tmp/d20141023-10368-1amhcha 0.011s PASS ok _/tmp/d20141023-10368-1amhcha 0.011s PASS ok _/tmp/d20141023-10368-1amhcha 0.012s
История (4 версии и 7 коментара)
Илия обнови решението на 15.10.2014 02:53 (преди над 3 години)
Промяна в случай, че е проблем Filter
да връща nil
.
Интересен е фактът, че append
очевидно работеше нормално и когато му подавах result
, на който не бях викал make
.
Всички операции над slice
работят - просто нямаш масив под slice
поради което append
директно ти прави нов масив и прави slice
върху него.
Не знам дали пак (тъй като и миналата година го имаше това) е било казано че ще гърми ако slice
не е инициализиран - няма голям смисъл - обикновено не е и практично да не си го инициализираш :).
тук забелязах нещо върху което не се бях замислял - всъщност nil
slice
-а се държи като slice
с дължина 0 с изключение на случай със сравняване с nil
.
Да, точно понеже рядко ще има причина да не се инициализира се очудих от нуждата от експлицитна инициализация чрез make
.
Да и аз затова питах във форума въпроса за nil
.
Илия обнови решението на 15.10.2014 15:12 (преди над 3 години)
-
Reduce
-а ти работи ли акоlen(data) == 1
? - Приеми че в 99% от случаите за
Filter
е изпълнено че му се подават масиви с големина >1000 и той връща 90%+ от подадените му данни
Илия обнови решението на 21.10.2014 00:04 (преди над 3 години)
Когато видях отговора ти за началната стойност за Reduce
знаех, че трябва да променя имплементацията, за да съответства с него, но после забравих да го променя.
За Filter
зададох cap
-ът да бъде размера на подадените данни. Все си мисля, че ако повечето ще останат след филтъра, то значи би било по-ефективно не да се добавят тези които се взимат, а да се направи копие и да се премахнат невалидните, но някакси
arr = append(arr[:i], arr[i+1:]...)
този синтаксис ми подсказва, че сигурно няма да е по-ефективно (correct me if I'm wrong).
Обръщане към обикновен списък, премахването и обръщането обратно в масив (slice) ми звучи добре, но не съм абсолютно сигурен дали наистина ще е продуктивно (без benchmark няма как да съм сигурен), а и засега не сте показвали container/list
.
Така е добре.
Това с невалидните елементи не мисля че е ефективно ИЗОБЩО - но като остане време ще направя няколко benchmark-а. Които между другото ще преподаваме следващия Вторник.
Илия, аз бих си задал cap-а да е len(data)/2
... Така в най-лошия случай ще имаш едно заделяне и същия брой излишни елементи, които ще имаш и ти - len(data)/2 - 1
. Другия ти най-лош е да нямаш валидни елементи и да имаш заделен масив с len(data)/2
празни елементи, а ти би имал len(data)
празни елементи.