Алгоритм для інтерфейсу користувача, що показує X відсоткових повзунків, пов'язані значення яких завжди становлять 100%

Система, яку я будую, включає набір повзунків користувальницького інтерфейсу (кількість варіюється), кожен зі шкалою 0-100. Під слайдером я маю на увазі інтерфейс користувача, де ви захоплюєте елемент і перетягуєте його вгору і вниз, як регулювання гучності. Вони з'єднані алгоритмом, який забезпечує їх завжди 100. Отже, коли один повзунок переміщується вгору, всі інші рухаються вниз, врешті-решт до нуля. Коли один рухається вниз, інші рухаються вгору. У всіх випадках загальна сума повинна бути 100. Тож тут повзунки мають різні значення, але вони на 100%:

----O------ 40
O----------  0
--O-------- 20
--O-------- 20
--O-------- 20

Якщо перший повзунок переміщується вгору від 40 до 70, інші повинні переміщувати значення вниз (у міру перетягування повзунка). Зауважте, три повзунки змінилися з 20 на 10, і один залишився на нулі, оскільки він не може опуститися нижче.

-------O--- 70
O----------  0
-O--------- 10
-O--------- 10
-O--------- 10

Звичайно, коли будь-який повзун досягає 0 або 100, він не може рухатися далі, саме там моя голова справді болить. Отже, якщо повзунок рухається вище, інші переміщуються нижче, але коли будь-який з них досягає нуля, нижчі можуть переміщатися інші, які ще не досягли нуля.

Я задаю це питання, оскільки це питання властиве алгоритму, а не його реалізації. Платформа FWIW - Android Java, але це не особливо актуально.

Підхід, який я застосував із моїм першим ударом, полягав у підрахунку зміни відсотка повзуна, який перемістився. Потім я розділив цю зміну і застосував її (в іншому напрямку) до інших значень слайдера. Однак проблема полягає в тому, що, використовуючи відсотки та множення, якщо будь-який повзунок потрапить на нуль, його більше ніколи не можна збільшити з нуля - чистий результат цього полягає в тому, що окремі повзунки застрягають у нулі. Я використовував повзунки з діапазоном від 0 до 1 000 000, щоб уникнути проблем із округленням, і це, здається, є корисним, але я ще повинен створити алгоритм, який добре обробляє всі сценарії.

Жадібний алгоритм

Коли повзунок рухається вгору (вниз), всі інші повинні рухатися вниз (вгору). У кожного є деякий простір, який він може переміщувати (для вниз - їх положення, для вгору: 100 позицій).

Отже, коли один повзунок рухається, візьміть інші повзунки, відсортуйте їх за простором, в якому вони можуть переміщатися, і просто перейдіть через них.

На кожній ітерації переміщуйте повзунок у потрібному напрямку на (загалом для переміщення вліво / повзунки ліворуч у черзі) або на відстань, яку він може перемістити, залежно від того, яка менша кількість.

Це лінійно за складністю (оскільки ви можете використовувати одну і ту ж упорядковану чергу знову і знову, як тільки вона буде відсортована).

У цьому сценарії жоден слайдер не застряє, всі намагаються рухатись настільки, наскільки можуть, але лише до справедливої ​​частки.

Зважений хід

Іншим підходом було б зважити рух, який їм потрібно зробити. Я думаю, що це ви намагалися зробити, судячи з вашої заяви "повзунки застрягли в 0". ІМХО, це більш природно, потрібно просто зробити більше налаштувань.

Ще раз замислюючись, я б сказав, що ви намагаєтеся зважувати рухи різних повзунків за їх положенням (це безпосередньо перекладається на вашу проблему з 0). Однак зауважте, що ви можете переглядати положення повзунка з різних напрямків - з початку або з кінця. Якщо ви важите за позицією від початку при зменшенні та позицією від кінця при збільшенні, вам слід уникати своєї проблеми.

Це термінологічно дуже схоже з попередньою частиною - не важуйте рух, що рухається за положенням повзунків, а обтяжуйте його місцем, яке їм залишилось для переміщення в цьому напрямку.

Підхід, який я б взяв, дещо інший і передбачає використання різного внутрішнього представлення кожного слайдера.

1. кожен повзунок може приймати будь-яке значення від 0..100 (X), яке використовується як коефіцієнт зважування для цього слайдера (не%)

2. додайте всі значення слайдера, щоб отримати загальну цифру (T)

3. щоб визначити відображене значення кожного слайдера, використовуйте КРУГЛО (X * 100 / T)

4. коли повзунок переміщується вгору або вниз, ви змінюєте лише значення одного слайдера ; зважування цього слайдера збільшуватиметься чи зменшуватиметься відносно всіх інших повзунків, а вищезгаданий калькулятор забезпечить, щоб зміни на всі інші слайдери були розподілені максимально рівномірно.

Я думаю, що ви занадто ускладнюєте речі, намагаючись скорегувати поточне значення на відсоток від зміни повзунка 'переміщений', що дає вам відсоток відсотків, що вводить помилки округлення.

Оскільки ви знаєте, що ви коли-небудь маєте справу із загальною вартістю 100, я б зберігав речі як цілі числа і працював на відстані від 100, уникаючи будь-яких серйозних проблем з округленням. (У наведеному нижче прикладі я обробляю будь-яке округлення як цілі числа в кінці)

Моєю технікою було б встановити повзунки як прості 0-100. Відніміть «нове» значення від 100, щоб визначити, скільки перерозподілити, розподіліть його між іншими повзунками відповідно до їх ваги, а потім почистіть)

Наскільки я не знаю, це не дійсний код Android: p

// see how much is "left" to redistribute
amountToRedistribute = 100 - movedSlider.value

//What proportion of the original 100% was contained in the other sliders (for weighting)
allOtherSlidersTotalWeight = sum(other slider existing values)

//Approximately redistribute the amount we have left between the other sliders, adjusting for their existing weight
for each (otherSlider)
    otherSlider.value = floor(otherSlider.value/allOtherSlidersWeight * amountToRedistribute)
    amountRedistributed += otherSlider.value

//then clean up because the floor() above might leave one or two leftover... How much still hasn't been redistributed?
amountLeftToRedistribute -= amountRedistributed

//add it to a slider (you may want to be smarter and add in a check if the slider chosen is zero, or add it to the largest remaining slider, spread it over several sliders etc, I'll leave it fairly simple here)
otherSlider1.value += amountLeftToRedistribute 

Це повинно суто обробляти будь-яке значення 0 або 100

Що з підходом Round Robin? Створіть транзакцію, яка гарантує, що додавання вартості одному слайдеру зменшиться від його однорангового. і навпаки.

Потім щоразу, коли зміна повзунка виконує транзакцію з іншим одноранговим повзунком (я б створив ітератор, який повертає повзунок однорангових по черзі). Якщо повзунок рівних дорівнює нулю, перейдіть до наступного.

Просто для детальної розробки великої відповіді на жадібний алгоритм від @Ordous. Ось розбивка кроків.

1. Переміщення повзуна
2. Зберегти в differenceAmount він переїхав в NEWVALUE - OldValue (засіб позитивного значення він переміщається вгору і інші повзунки повинні рухатися вниз і навпаки)
3. Відсортувати інші в списку від найменш до найбільш від відстані вони можуть рухатися в потрібному напрямку з допомогою differenceAmount бути позитивним або негативним.
4. Встановіть amountToMove = differenceAmount / час, що залишився OthersCount
5. Цикл по кожному і перемістити повзунок з допомогою яких суми він може рухатися або amountToMove . Що б менше
6. Відніміть суму повзунок зробив крок від amountToMove і розділити на новий залишився OthersCount
7. Закінчивши, ви успішно розподілили різницю між іншими повзунками.

Один простий прийом - це обчислити відсотки значень слайдера відносно суми значень повзунка, а потім переназначити значення повзунка на відповідні обчислені відсотки. таким чином коригуються значення слайдера, наприклад

slider1.value = (slider1.value / sumOfSliderValues) * 100 ;
slider2.value = (slider2.value / sumOfSliderValues) * 100 ;
slider3.value = (slider3.value / sumOfSliderValues) * 100 ;

Хоча це вводить помилку округлення, але її можна впоратися у випадку, якщо нам потрібні значення повзунків точно і завжди підсумовувати до 100.

Я створив скрипку, щоб продемонструвати це за допомогою angularjs. Будь ласка, відвідай демонстрацію