Идея интересная, но выглядит жутковато).
И еще, получается, что грузятся сразу все страницы сайта? Как-то это не хорошо, да и якоря особого шарма не придают).
Отличная идея! Порой часто забываешь где находится тот или иной пункт меню или же просто долго ищешь, при этом ты точно знаешь, как он называется. С данным функционалом этой проблемы бы не было. К тому же, вероятно, сделаюь, например, хоткей для показа классического меню, когда это необходимо.
Очень надеюсь, что в Gnome 3 не будут отставать и сделают такую же фишку.
Каюсь, время работы алгоритмов, по факту является временем работы всего Solver-а, а он включает в себя еще и расталкивание частиц, которое занимает значительное время. Т.е. это не совсем время работы именно алгоритма.
Рост времени 2 алгоритма не такой, какой ожидается, из-за того, что частицы на каждом шаге уже практически отсортированы.
Если выключить расталкивание частиц и на каждой итерации все частицы перемешивать, то рост времени у 2 алгоритма будет совсем другой, ближе в ожидаемому. На таких же условиях проверил 3 алгоритм, линейность во всей своей красе:
10000 — 1 мс
20000 — 2 мс
30000 — 3 мс
100000 — 10-11 мс
Можете убедиться в этом сами, в методе Collision, первой строкой сделать return, и на каждой итерации вызывать InitParticles.
Как измерить скорость работы в количестве операций я не совсем понимаю.
Мне кажется наоборот будет проигрыш, как по памяти, так и по времени работы алгоритма, причем на большем количестве частиц это будет сильнее заметно. Ведь это можно легко проверить опираясь на сложность алгоритмов.
Рабочие все 3 алгоритма, выбрать можно любой, нужно исходить из исходных данных, если частиц мало, не долго думая выбираем 1 алгоритм, потратив на его написание 10 секунд и не паримся. 2 алгоритм очень популярен, особенно, когда хочется и производительность и не очень хочется копаться в более сложных вещах, тратим на его понимание несколько минут и меньше минуты на кодирование.
Так же мне хотелось сравнивать все алгоритмы по времени работы.
Про условие, очевидно, что, если свободных мест нет, условие не выполняется и частица остается на своем месте, да, это не хорошо, да, вероятно, какие-либо столкновения с ней не обработаются, но об этом в статье я немного написал, если вы смотрели код, то вы могли заметить, что в ячейке хранится максимум 4 частицы, при хорошем расталкивании частиц этого достаточно, можно увеличить это число, можно использовать динамический массив, но это заметно скажется на производительности.
По сути, эта сеть и является хеш таблицей, которая хранит указатели на частицы.
Эту статью вижу первый раз.
KD-tree далеко не самый лучший вариант для collision detection, у них немного другая область применения. Их хорошо использовать, например, для поиска в пространстве или при рендеринге.
This account's public links are generating too much traffic and have been temporarily disabled!
И видео не грузится. :(
И еще, получается, что грузятся сразу все страницы сайта? Как-то это не хорошо, да и якоря особого шарма не придают).
Очень надеюсь, что в Gnome 3 не будут отставать и сделают такую же фишку.
Рост времени 2 алгоритма не такой, какой ожидается, из-за того, что частицы на каждом шаге уже практически отсортированы.
Если выключить расталкивание частиц и на каждой итерации все частицы перемешивать, то рост времени у 2 алгоритма будет совсем другой, ближе в ожидаемому. На таких же условиях проверил 3 алгоритм, линейность во всей своей красе:
10000 — 1 мс
20000 — 2 мс
30000 — 3 мс
100000 — 10-11 мс
Можете убедиться в этом сами, в методе Collision, первой строкой сделать return, и на каждой итерации вызывать InitParticles.
Как измерить скорость работы в количестве операций я не совсем понимаю.
Рабочие все 3 алгоритма, выбрать можно любой, нужно исходить из исходных данных, если частиц мало, не долго думая выбираем 1 алгоритм, потратив на его написание 10 секунд и не паримся. 2 алгоритм очень популярен, особенно, когда хочется и производительность и не очень хочется копаться в более сложных вещах, тратим на его понимание несколько минут и меньше минуты на кодирование.
Так же мне хотелось сравнивать все алгоритмы по времени работы.
Про условие, очевидно, что, если свободных мест нет, условие не выполняется и частица остается на своем месте, да, это не хорошо, да, вероятно, какие-либо столкновения с ней не обработаются, но об этом в статье я немного написал, если вы смотрели код, то вы могли заметить, что в ячейке хранится максимум 4 частицы, при хорошем расталкивании частиц этого достаточно, можно увеличить это число, можно использовать динамический массив, но это заметно скажется на производительности.
По сути, эта сеть и является хеш таблицей, которая хранит указатели на частицы.
Извините, но ваш код я не читал.
KD-tree далеко не самый лучший вариант для collision detection, у них немного другая область применения. Их хорошо использовать, например, для поиска в пространстве или при рендеринге.