Eugene-Usachev, выше ты пишешь что коллизии неизбежны. Да. Они неизбежны по свойству множеств.
Множество значений ключа обычно (как правило) мощнее чем множество значений хеша. Принцип Дирихле! Это вообще
база хеш-таблиц. Если-бы этой базы не было - то мы ушли-бы от функции расстановки к прямому доступу
к таблице как к массиву. С другой стороны если у тебя ключ - i32 - (4 млрд значений) то выдели себе
массив на 4 млрд 4х байтных чисел (указателей?) (это будет 16 Г) и пользуся! Прямой доступ. Ключ == индекс.
Красота.
И будет тако себе будерброд и хеша и тела ключа. Но это на самом деле tradeoff. Перенос проблемы
из области вычислений в мемоизацию. Это надо прикинуть хорошенько не ударит ли по памяти например.
Тебе хеш нужен дважды. Первый раз при вставке ключа в хеш-таблицу.
И второй раз при поиске. И это неизбежно потому что дистанция между
этими событиями - бесконечно большая во времени и хранить эти временные
штуки негде.
TheAvix, Doom был многократно опубликован в исходниках (кажется под Watcom C++) и
портирован на Java, JavaScript и всякие игровые приставки. Попробуй поискать. Думаю
материала читать там хватит надолго.
Ты спрашиваешь про RayCasting для таких игр. Честно я не знаю зачем это в 21 веке. В эпоху
всяких Unity, Vulkan, e.t.c. Хочешь написать свою игру для ограниченного железа? Или просто
потренироваться?
Посмотри книжку Шикина и Борескова (комп графика) она такая желтого цвета. Он там что-то
писал про базис Doom/Quake на уровне обзора. Может про текстурирование что-то было.
Но до текстурирования у тебя должен быть уже готов pipeline для геметрии. Тоесть должна быть
сцена. Камера. И должны быть уже известны экранные координаты всех текстур.
Существует терминологическая путаница. RayCasting, RayTracing, Back-tracing. В разной литературе
и в разных статьях авторы и переводчики иногда их меняют местами.
В гейм-индустрии весь 20-й век работал обратный рей-трейсинг - это когда освещение вычислялось
по лучу выпущенному из глаза наблюдателя. Это было легко и количество отражениый было равно нулю.
А прочие эффекты расчитывались "запеканием" карты освещения которая делалась как раз прямым трейсингом
(от источников света к стене). Так уже работал Quake-1.
В современных играх стали двигаться к трейсингу от источника света к объекту. Тоесть именно так
правильно как в физике происходит но пока еще нагрузка получается unpredictable, и трудно
стабилизировать игру чтоб она выдавала одинаковый ФПС. Правильный рей-трейсинг это
рекурсия а она всегда была такая ... бррр. Неприятная короче в плане прогнозов.
Вот пускай автор расскажет что он именно хочет узнать в виде детализации вопроса.
Phys_Math_Man, мне сложно комментировать код, который я хотел-бы переписать.
Я-бы предложил так.
connection.autocommit = false
....
здесь ты делаешь свои DML операции и в конце даешь явный коммит как бы фиксируя пачку.
connection.commit()
Комментировать то что ты написал я не хочу. Мне кажется что оно не совсем корректно.
Я-бы избегал таких миксов COMMIT внутри строки. Это полюбому не production use-case
и такое не проходит code-review.
А про авто-коммит тебе в самом начале уже написали. Я согласен. Вот так оно и работает.
Смирись с этим.
Сергей Соловьев, по первой ссылке в ответе в stackoverflow есть куча документов. Читай. Разбирайся.
И после этой ссылки ты уже должен сюда прийти полностью подготовленным. И знать
правила формирования доменных имен.
Можно придумать функцию которая отображает любой IP адрес в фиксированный name с сохранением числовой составляющей. И при этом не нарушая правил. Понятное дело что автор хочет какую-то блажь
но пускай попробует так:
Артем Гартунг, я давно в стеке LAMP ничего не делал. Но мне кажется что такие типичные
настройки как троттлинг запросов и фильтрация пользовательского клиента уже должны
были стать частью стека.
Тоесть грубо говоря - дефолтное приложение должно быть защищено из коробки от типичных школьников.
Платные решения типа Cloudflare идут отдельной категорией. Их тут обсуждать не интересно. Речь
как раз о том что можно сделать в самом простом кейсе.
Множество значений ключа обычно (как правило) мощнее чем множество значений хеша. Принцип Дирихле! Это вообще
база хеш-таблиц. Если-бы этой базы не было - то мы ушли-бы от функции расстановки к прямому доступу
к таблице как к массиву. С другой стороны если у тебя ключ - i32 - (4 млрд значений) то выдели себе
массив на 4 млрд 4х байтных чисел (указателей?) (это будет 16 Г) и пользуся! Прямой доступ. Ключ == индекс.
Красота.