Резултати от търсенето

Ee, защо такъв негативизъм, можеше да питаш - "бързия или верния" :D

Аз като го отворя, виждам това.. Та май нямам причина да го отворя пак :D

Ако полето е INT, как получаваш не-целочислен сбор?

то няма нужда и от order by в тоя случай :)

Точно!

Аа inf'инитито е голямо удобство :D Позволява без излишна допълнителна логика да взимам по един и същи начин тръби от безкрайния и крайния supply (ако имам безброй тръби с дължина 6 и пет тръби с дължина 3, то и в двата случая правя `pipe_count - 1`, за да "взема" тръба от new_supply). Демо...

Зависи колко са големи входовете на uphero. Например при тръби по 10м, demand [(8, 4), (5, 1), (3, 1), (2, 5), (1, 5)], [(10, inf)] отнема феноменалните... 5 секунди :D Не мога да преценя добре в кои случаи се бави много. Друг пример с подобна дължина минава веднага: [(8, 2), (7, 3), (6, 5)...

Тоест, @uphero ще трябва да се задоволиш или с бавен (рекурсивния, който дадох по-горе), или с неточен алгоритъм. C'est la vie :). За второто, варианти бол - в статията в уикипедия има линкове с имплементации най-долу. Както пишат тук...

Ами, сори пичове, изписахме 3 страници за нищо :D :D :D :D https://en.wikipedia.org/wiki/Bin_packing_problem Просто защото няма :)

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

Хмм, я провери с този пример: две 4ки и четири 3ки при supply от тръби с дължина 10. Оптималното решение е с две тръби: всяка я режеш на 4 + 3 + 3. Твоят алгоритъм обаче като го приложа, реже втората четворка от изрезката, останала след първата, т.е. реже от 6тицата. И в сандбокса като го...

На стъпки 4/5: A това защо работи? И по принцип, защо точно този избор тук (от коя изрезка да вземеш) е най-добрият: $remainingLength = $leftoverLength - $requiredLength; if ($remainingLength > 0 && $remainingLength < $smallestDemandedPipe && $i < array_key_last($leftovers)) { continue; }...

A не не, мойто решение е експоненциално по броя на тръбите, абсурд :D Дори за входове с дължина на demand по 5 и повече отнема по повече от няколко секунди, затова тестовете са такива орязани/къси. Написах го, просто защото е най-лесното, в което мога да съм сигурен, че е вярно. Твойто като...

Онзи ден имплементирах най-наивния наглед работещ рекурсивен алгоритъм, за който писах на първата страница (вие що не го пробвахте :D :p); тръгнах да му добавям да помни и изрезките (в момента само печатам общата бройка накрая) ама не го подкарах бързо и го зарязах. Предимството на рекурсивния...

Ако в базата текста е чисто ASCII (стринга с процентите), дали ще ѝ сетнеш utf8 или не, е все тая. Проблемът ти е при записването. Как записваш данните в таблицата? Явно идват през URLа, тогава трябва да ги прекараш през https://www.php.net/manual/en/function.urldecode.php, за да се изчистят...

1 << $i за... степенуване на двойката? 😨

Щото при рязането ще изпили по 1мм на всеки разрез ли :D :D

Два списъка, един със supplyя и един с demand'а. И в двата записваш двойки (брой, дължина), и ги държиш сортирани по дължината - supply ascending, demand descending. Копирах си дословно изречението от по-горния пост :D В твоя пример това са [(infinity, 6000)] и [(20, 5000), (4,1000), (1, 100)].

То ако входът е даден, вече в задачата се търси не алгоритъм, ами по-скоро доказателство, че намереният оптимум наистина е оптимален :D Иначе това с групирането 622,532 е и резултата при "поправения" алчен алгоритъм, доколкото го проследих. Не е толкова сложно, просто е рекурсия с цикъл, ето...

Хмм, тогава вземи контрапримера и умножи всичко в него по 2. Тогава всички supply и demand числа ще са винаги четни и модификацията с нечетностите няма да промени прилагането на алгоритъма, т.е. той ще даде същия (грешен) резултат.