Представь, что на очередном шаге left+1=right. Тогда mid равно или left, или right (понятия не имею, как округляет Java). Теперь пусть key равен другому значению переданной границы (скажем, если mid=left, то key=numbers[right]). Произойдёт рекурсивный вызов, но передаваемые для left и right значения образуют некорректную пару, которая не пройдёт контроля left <= right.
PS. Это - НЕ двоичный поиск. В крайнем случае это его нестандартная вариация с (неудачной) попыткой оптимизации.
PS. Для исправления достаточно убрать "оптимизацию" и передавать mid как есть.
вот реальный пример цены и процентов вещей, который нашел, цена 20р
Цена вещей и шанс их выпадения
Если бы была вменяемая функциональная зависимость, то график процента от стоимости был бы похож по внешнему виду на 1/x. А он, если его построить, похож на чёрт знает что, с каким-то необъяснимым перегибом.
Допускаю, что итоговый процент есть сумма двух функций - одна на 20 рублях упирается в ноль, а другая к этому нулю приближается асимптотой. Но, блин, угадывать, что на самом деле там наворотил очередной "дерзайнер" - занятие абсолютно безнадёжное.
Это скорее всего "сервис" от библиотеки доступа либо коннектора (первое вероятнее). Но в любом случае LIMIT 1000 добавляется до передачи запроса на MySQL (можно проверить, включив General Log).
LIMIT 10000
Если нужен LIMIT, лучше использовать максимально допустимое значение.
Нет в MySQL такого ограничения. В MySQl вообще, в принципе, есть только одна инструкция, способная выполниться частично - это LOAD DATA. А в большинстве СУБД таких вообще нет.
Практически все производители имеют модели принтеров со встроенными считывателями карт. Правда, почти всегда это принтеры для рабочих групп (и правда, зачем нужна защищённая печать на маленьком индивидуальном принтере? проще не расшаривать). И к ним прилагается соотв. программное обеспечение (как в прошивке, так и опции драйверов), с аутентификациями как локальными, так и через сервисы каталога.
Думаю, лучше с такой задачей сразу обращаться к консультации/техподдержке производителя либо к интегратору.
NewSantaClaus, Тогда только подзапрос, который для каждого пользователя получит максимальный штамп времени, и использование этих данных в качестве условия отбора по другой копии таблицы.
SELECT t1.*
FROM table AS t1
NATURAL JOIN (
SELECT user_id, MAX(timestamp) AS timestamp
FROM table AS t2
GROUP BY 1
) AS t3
Если вдруг для юзера время может иметь дубликаты - будут выведены все соотв. записи.