Функционални
Използваме бисквитки и подобни технологии, за да предоставим нашите услуги. Използваме „сесийни“ бисквитки, за да Ви идентифицираме временно. Те се пазят само по време на активната употреба на услугите ни. След излизане от приложението, затваряне на браузъра или мобилното устройство, данните се трият.
Използваме бисквитки, за да предоставим опцията „Запомни Ме“, която Ви позволява да използвате нашите услуги без да предоставяте потребителско име и парола. Допълнително е възможно да използваме бисквитки за да съхраняваме различни малки настройки, като избор на езика, позиции на менюта и персонализирано съдържание.
Използваме бисквитки и за измерване на маркетинговите ни усилия.
Амиии не е лош алгоритъма за prime, но "моя е по-добър" : )) Много си го харесвам и мисля че е доста по-бърз защото проверява и кратни на 3 и минава през 6 елемента на врътка на цикъла.
Със сигурност - но така можем да направим едни if-ове (не може да стане със switch, защото проверяваме изрази), дето проверяват с числата до 100 (до 97 по-точно). Въпросът е, че всяко следващо число "отмахва" все по-малко възможности (а if-овете не са много бързи като цяло, особено голяма серия if /elseif...). Това също не е много оптимизирано за performance - if($num % 2 == 0) return ($num == 2); - трите if-a може да са if / elseif / elseif. Но да не издребняваме - двата if-a във for-цикъла например правят кода по-труден за четене, освен това има т. нар. класове сложност на алгоритмите - броят операции в двата алгоритъма се различават с константа, освен това константата е много малка.
Всъщност, истинската оптимизация в алгоритъма е да не проверяваш всички числа до числото, а до корен квадратен от него - това прави сложността на алгоритъма от линейна (по подаденото число) до sub-linear (не знам как се превежда на български).
Така де, харесвам алгоритъма ти, но е малко overkill
. Има две основни правила при оптимизацията на код за бързодействие: 1) оптимизирай само когато се налага (защото това обикновено води до гаден код), 2) оптимизирай само ако резултатът е по-добър в пъти (примерно кодът върви 5 пъти по-бързо), а не в проценти (особено добре е да смениш алгоритъма, ако минеш в "по-бърз" клас сложност).
Първо, този алгоритъм, който си ползвал е на-стандартния, тоест, ако отвориш един туториал, първо него намираш и не е никак оптимизиран, дори и моя не е - ако ги пуснеш в SPOJ - задачата с прости числа, ще увиснат яко.
Този се води от най-бързите и със сигурност ми е трудно четим на пръв поглед Sieve of Atkins
Не виждам нищо 'бавно' в if защото е една проста математическа операция. докато вляза в цикъла да търся номера вече съм намерил решение за много голям брой случай.
Второ, и в моето решение стигам до корен на числото, не до самото число.
За четимостта е малко субективно, аз не виждам нищо нечетимо в моя код, но виждам ползите - проверката за остатък от делене на 3, което ни улеснява като след това можем да минаваме през 6 числа в цикъла. Не ми се правят тестове сега, но основната ми идея е - if - бързо, loop - бавно.
Sieve of Atkins наистина е съвсем друг тип алгоритъм, използва много неща от теория на числата (и не само) и се справя blazingly fast със задачата :). Колкото до корена от числото, да, вижда се - просто исках да отбележа, че това е най-сериозната оптимизация за нашия алгоритъм. А за четимостта - обичам да се придържам към KISS принципа
.
Сега, не ме разбирай грешно, не искам да се заяждам или нещо такова - просто исках да отбележа някои неща . Да, твоята версия прави по-малко стъпки, но не мисля, че е необходимо да я използвам
.
P. S.: Ама колко изписахме за два-три реда код![tongue-out](https://tinymce.cachefly.net/4.0/plugins/emoticons/img/smiley-tongue-out.gif)
В 5 задача е казано, ако числото не е цяло да отпечата "I cannot sum that". Гледам, че и други колеги не са догледали тази малка подробност, която на мен лично много ми усложни работата.
@ZvetanIG, много ти благодаря за препоръката. Оправих го - смених is_numeric на проверка с filter_var и сега работи само за цели числа :)
Чудесно, но аз бих ти препоръчал ctype_digit($number) вместо filter_var, защото тя не хваща варианти като 0005 или 0000 и сега при подобен вход ще получиш "I cannot sum that".
Ех, тая проверкаааа
. Мерси, оправих го отново.
Ето един доста добар алгоритъм за намиране на prime в дадени граници.
$isPrime=true;
for ($i=$startNumber ;$i<=$endNumber; $i++) {
for ($y=2 ;$y<=floor(sqrt($i)); $y++) {
if($i%$y==0){
$isPrime=false;
}
}
if($isPrime){
echo "<b>$i</b>, ";
}
else{
echo "$i, ";
}
$isPrime=true;
}
не мога да разбера защо на 6.а задача тука
function splitString($string)
{
// Works for English and Bulgarian characters only
$result = array();
preg_match_all('/[A-Za-zА-Яа-я]/', $string, $result);
return implode(" ", $result[0]);
}
в implode-то е $result[0], а не $result. Нали уж вкарваме match-овете в масива, т.е. всяка буква A-Za-zА-Яа-я отива в масива поотделно и се получава масив от букви. Така $result[0] ми изглежда, че ще печата само първата буква, а не всички...А защо печата всички?
preg_match_all('/[A-Za-zА-Яа-я]/', $string, $result) връща на мястото на $result масив с два елемента. Първият елемент е масив със съвпаденията, а вторият елемент е са групите. Дебъгни и ще видиш структурта на $result.