Тогда надо математику подключать...
Вот, например (не понял о чем речь, но название красивое):
О плотности распределения супремума случайного блуждания в субэкспоненциальном случае
😂😂😂
А если серьезно, то думаю схематика такая:
Есть веса, например, от 1 до 100...
1 этап
выбираем случайное число, допустим 34.
2 этап
выбираем все значения с весами до 34 включительно.
3 этап
выбираем случайное из данной группы значений.
в результате двойной случайной выборки получим искомый результат, т.к. максимальные веса по определению будут входить во все выборки, и сл-но встречаться в результате пропорционально своему весу, т.е. чаще прочих.
как-то так, поправьте если ошибаюсь.
Если значения и веса в базе, то можно думаю одним запросом оформить искомую выборку.
С точки зрения прграммирования верно будет не плодить лишних сущностей (зачем запятую в скобки?) и учитывать возможность множественных символов подряд, т.е.:
$new = preg_replace('/(\d+),(\d+)/i', '$1.$2', $old);
если текст построчно (как в примере), то как то так:
preg_match('/строка([^\n]*)\n/i', $text, $match);
А зачем так сложно то???
допустим есть пары:
a - 3
b - 2
c - 1
создаем массив:
[ a , a , a , b , b , c ]
и из него случайную выборку делаем...
остальное доделают теория вероятности и принципы нормального гауссова распределения...
Млин...
Не группировать с помощью... А задавать условия с помощью!!!
С помощью программирования!
Теперь и до меня дошло... (Жирафам привет)
group by позволяет условия...
т.е. как то надо туда запихать, что-то типа: group by day+TIME_OFFSET
Щас ругаться начну...
Вы издеваетесь или правда тупите так сильно?
Что вы в качестве условия для between задали - то мускуль и выдает!!!!!
Других вариантов быть не может...
Чтобы он выдавал результаты с учетом смещения, нужно это смещение уже само по себе в between запихать - что непонятно????
Т.е. "пАлюбАсу" встает вопрос обработки запроса из вне, а именно получение зоны клиента и соответствующая корректировка самого запроса...
проблема вообще не понятна, ибо само высказывание что:
ставит в тупик...
Ибо при чем здесь любые зоны, если речь идет о записях в базе данных?
Если кстати Вас это удивляет - нужно бросать эту работу...
Ну учитывая что мускуль не может знать какая timezone у клиента, логично предположить, что в условие between, нужно загонять уже даты скорректированные относительно клиентской timezone...
Это мануал... Это нормальное поведение...
Вот тут как раз наоборот... Я сталкивался именно с поведением когда в hidden не грузились данные пока он был hidden, а с display таких приколов никогда не возникает... Правда так не во всех бродилках, в каких не помню, давно дело было. Сам не могу понять почему. Т.е. display как раз из ДОМ не выпадает, а с hidden такое случается - пример ТС тому косвенное подтверждение...
Ну, например, блок в меню, когда нужно чтобы он либо пустым был, либо наполненным... И при этом страница не прыгала... Хотя конечно есть масса других методов для реализации подобного функционала...
