EDIsaev, Ну хорошо, пусть длины в двух детях 10000 и 10002. Только через 10000 шагов отловите?
Ну так вам тогда не надо ничего хранить в вершинах вообще. Если вы и так перебор во всю глубину запускаете, то можно обход в ширину запустить.
И вообще, могут быть игры, где количество ходов будет одинаковой четности всегда. Например у вас лабиринт в котором двигаются 2 фишки и игроку надо свою фишку вывести из лабиринта раньше соперника. Тут в зависимости от шахматной раскраски доски получается что фишка всегда должна сделать количество ходов одной четности. Так что в этом дереве вообще все пути будут одинаковой четности и ваши пометки не дадут вообще никакой информации.
EDIsaev, Не всегда же. Ведь если среди двух веток детей в одной путь за 2 шага, а в другой за 4 - то вы никак это не отловите. Возможно есть какая-то специфика игры, позволяющая делать это. Но вряд ли у этого приема есть какое-то название, ибо он слишком специфичен под конкретную игру.
А дети как хранятся? Так-то только по графу-дереву состояний можно найти кратчайший путь в конечную вершину, вообще ничего не храня в вершинах дополнительно.
Что за перекрытие? В смысле, маленькие прямоугольники должны пересекаться немного? Маленькие прямоугольники фиксированного размера? Их можно поворачивать?
НЕТ. Кодовые позиции Юникода в любом из форматов его сериализации (UTF-8, UTF-16)
Я и спросил, вы именно про способ записи? Да, UTF-8 - префиксный код, потому что там длина кода закодирована в первом байте. Но это не ваше свойство. Ведь ваше свойство подразумевает, что код не префиксный.
Вы, видимо, путаете юникод, как битовый код, и способ инерпретации последовательности юникодовских символов в виде одного эмодзи. Это вообще не код в смысле, что мы читаем поледовательность кода и ставим ей в соответствие какой-то символ. Просто вот этот ZWJ - это специальный символ, который говорит, что надо соединить два символа в один при отрисовке.
Тут не какое-то свойство кода, а просто специальный символ. И название у такой штуки "Zero width joiner sequence"
Юникод - это таблица из 32-битных кодов. Они все одинаковой длины и любой 32-битный код - это символ юникода. Возможно, не определенный еще. Описанного вами свойства там нет.
Вы про кодировку UTF-8? Которая есть лишь более плотный способ записи? Вроде как тут тоже этого свойства нет.
Pragma Games, Хорошо, есть у вас направление на d. У вас есть координаты target? Если target - в центре окружности, то значит d указывает строго на нее? Ведь перпендикулярная окружности прямая проходит через центр.
А потом, зачем вам умный указатель на функцию? Это очень плохая затея вообще. Подумайте, надо ли освобождать память, на которую указывает указатель вообще? Когда и где она создается?
Функции - это набор инструкций процессора, они обычно лежат в секции кода в исполняемом файле, создаются там компилятором и загружаются в память операционной системой по особому. Данные же, которые вообще можно удалять - они находятся в куче и там прямо на уровне процессора разница между этими двумя типами данных. Вы без плясок с бубном и обращениям к системным АПИ не сможете выполнить код из кучи, или записать данные в исполнительный код.
Если же у вас какой-то класс с определенным оператором (), который и хранит какие-то еще данные, кроме кода (вроде забинденных аргументов), то у него тип вообще не функции. Это просто какой-то класс с оператором () и все.
SergeySerge11, Ну, потому что вершины выдаются в порядке обхода дерева, то некоторая локальность там конечно есть. Они там сортирвованы будут в порядке обхода трехмерной Z-кривой.
SergeySerge11, В 4 раза - неплохое сокращение. А ведь если игрок может быть на краю карты и смотреть наружу и тогда вообще мало будет видить.
Вот я скачал 3d сцены по 20-100 млн вершин, и смотрю на них полностью, с высоты.
Ну так это не типовой случай. В среднем что-то да отсекается, так что профит от октодерева есть.
если я всю сцену вижу, и никах лагов нету, тогда зачем нужна эта фаза.
Что бы лагов чаще не было и на более слабом железе. Или чтобы эта сцена не стала тормозить на вашем компьютере, когда вы добавите туда еще и вычисления для какого-нибудь игрового ИИ, какую-нибьудь симуляцию чего-нибудь, или увеличите количество вершин в пару раз.
Ясно, что эта оптимизация не работает хорошо 100% времени. И без нее на конкретно вашем компьютере может хватать вычислительной мощности для 60фпс. Но если она работает достаточно часто, то почему бы ее и не применить?
xfnxfn, Ссылка - это тоже указатель, я же вам сказал. Это "псевдоним" для другой переменной. На самом деле это тоже лишь переменная, которая хранит адрес чего-то. Это не копия.
Да, и указатель и ссылку можно получить и на данные в куче и на стеке - они же в памяти, значит у них есть адрес.
xfnxfn, Указатели нужны, чтобы обращаться к памяти в куче, передавать в функции переменные, которые можно будет менять, передавать большие структуры более оптимально, хранить связи многие-к-одному.
Ссылки - это те же указатели, только времени компиляции. Это указатель, который не может быть нулевым и уже создается с адресом. Их используют, чтобы передавать данные в функции, которые можно будет оттуда менять, чтобы более оптимально передавать данные, для упрощения кода. Очень похоже на указатели.
Leroi_1, У тебя изображение - одномерный массив. При чтении любого пикселя - прочитается 8 байт. Т.е. если ты попытаешься прочесть последний пиксель - 7 лишних байт за массивом прочитаются. Надо сделать массив на 7 байт больше. Ядро будет матрицей 5x8, вроде {1,1,1,1,1,0,0,0} ...{-1,-1,-1,-1,-1,0,0,0}} Потому что векторыне операции выполняются с 8 байтами сразу.
Leroi_1, Самое простое - по строкам. Надо исходное изображение расширить хотя бы на 7 байт в конце, чтобы не было чтения за границей массива, а ваше ядро добить тремя 0 до ширины в 8 байт.
Потом вы для каждой из 5 строк вы загружаете в регистр строку ядра и строку исходного изображения (всегда на 2 пикселя левее). Векторно их перемножаете, суммируете и эти 5 чисел складываете в ответ. У вас на самом деле загрузятся еще 3 лишних значения правее - это будут или пиксели со следующей строки, или вообще нули в самом конце массива. Но тут нет проблемы, ибо в ядре там стоят 0 и они умножатся на 0.
Тут вы 25 операций векторизовали пятерками. Это работает легче всего, потому что данные лежат вот так по строкам. если вы попытаетесь 4 раза по 8, или 2 по 16 элеменов как-то загружать сразу, у вас все будет очень сложно и скорее всего даже медленнее.
Тут, правда, будет проблема с первыми двумя столбцами изображения - у вас же нет никаких пикселей левее.
Для обработки этого случая, вам придется загружать Input не с позиции на 2 пикселя левее, а на 1 или 0, но тогда и kernel придется читать со столбца 1/2 а не 0.
Для обработки крайних строк надо будет пропускать какие-то из этих 5 итераций цикла.
Или сильно проще будет, если в при загрузке изображения поместите его в рамочку из нулей шириной 2. Т.е. у вас будет +4 толбца и +4 строки.
Ланской Кирилл, Еще остались проблемы с логикой. Вам в соседнем ответе правильно подсказали - если в первом слове буква встречается несколько раз, то вы ее в ответ несколько раз и выведете.
Вообще ваш подход очень не оптимален. Может даже не пройдет по времени, если есть какая-то система тестирования.
Надо вам завести массив на 26 (или 256, если буквы не только английские бывают в словах) элементов, где вы будете помечать, есть ли у вас какая-то буква в текущем слове. Это может быть bitmask<26>, например.
Во втором таком же массиве вы должны также хранить те буквы, которые встречались во все словах.
Тогда вам надо выполнять логическую операцию И над каждым элементом этих двух массивов.
Ну так вам тогда не надо ничего хранить в вершинах вообще. Если вы и так перебор во всю глубину запускаете, то можно обход в ширину запустить.
И вообще, могут быть игры, где количество ходов будет одинаковой четности всегда. Например у вас лабиринт в котором двигаются 2 фишки и игроку надо свою фишку вывести из лабиринта раньше соперника. Тут в зависимости от шахматной раскраски доски получается что фишка всегда должна сделать количество ходов одной четности. Так что в этом дереве вообще все пути будут одинаковой четности и ваши пометки не дадут вообще никакой информации.