Общие вопросы по программированию (1315 стр)

Гугловый ГПТ на серьезных щах заявляет, что я могу смело конкатенировать строки так:

#include "my_folder/" "my_header.h"

Вот же брехло.

nes
> Гугловый ГПТ на серьезных щах заявляет, что я могу смело конкатенировать строки так

Вообще конкатенировать строки так действительно можно, но вот только не внутри #include (и, вероятно, нельзя и в других директивах препроцессора), о чем вот я не знал, пока сам не проверил. И ГПТ тоже, видать, не знал, и экстраполировал общее правило, как и я в #19697.

Ну шож вы так? :)

nes
> Можно ли как-то добиться такого поведения в крестах?
Когда тебе надо вскипятить воду, ты тоже разводишь костер во дворе? ;)

Пока сам не понимаю точно суть своего вопроса, пока сформулирую, может быть пойму :)

Есть последовательность некоторых элементов, суть элементов не важна (однотипные структуры в памяти, буду обозначать просто буквами).
Есть последовательный ридер, умеющий читающий N таких элементов, лежащих подряд в памяти.

Последовательность очень длинная, необходимо оптимизировать ее представление в памяти, благо в последовательности скорее всего будет много повторяющихся кусков. Только какие это куски и их размеры - надо это как то определить.

Например, абстрактно надо получить на выходе такую последовательность (здесь короткая, для примера):

A B C D E F G H F G H A B C

Если я разобью последовательность так:

(A B C D) (E F G H) (F G H A B C)

, то вижу, что могу в памяти расположить элементы так:

E F G H A B C D

, а потом ридеру дать команды
- читай 4 элемента, начиная с индекса 4
- читай 4 элемента, начиная с индекса 0
- читай 6 элементов, начиная с индекса 1

и получу на выходе требуемый результат.

Информация об индексах и размерах кусков, конечно, тоже занимает место в памяти, причем размер дескриптора (индекс, количество) примерно равноценен размеру элемента (хотя было бы неплохо, чтоб для алгоритма можно было задать любое отношение размера элемента к размеру дескриптора куска)..

Как бы такую задачу оптимизации хранения последовательности для вышеуказанного ридера решить в общем виде, имея в качестве входных данных только итоговую последовательность?

Построить структуру типа префиксного дерева (слегка отличающуюся т.к. последовательность можно переиспользовать не только с первого символа) в которой посчитать какой "профит"  приносит каждая из последовательностей (сколько символов сэкономит с учетом размера дескриптора и самой последовательности).
Дальше будем последовательно добавлять в память одну из последовательностей, пересчитывать дерево без нее, повторять.

Сразу добавлять в память самую выгодную последовательность я так понимаю нельзя, может быть ситуация когда кодирование оставшихся кусков окажется менее оптимальным чем без нее, поэтому используем метод ветвей и границ - сначала последовательно добавляя самую выгодную получим верхнюю границу, дальше перебираем менее выгодные ветки останавливаясь если граница превышена и постепенно ее улучшаем.

kipar, так отдельных мелких последовательностей нет. Если рассматривать вообще все возможные разбиения исходной последовательности на подпоследовательности - комбинаторный взрыв.

Dmitry_Milk
например сначала просто префиксное дерево (в каждом узле пишем сколько сэкономим с учетом родительских узлов), а потом в каждый узел добавляем экономию из узлов совпадающих начиная с 2, 3 и т.д. символа.

еще из идей - ограничить глубину скажем 5, но в каждом листе с глубиной 5 хранить точку где он встретился. Если найдем его повторно - увеличиваем глубину в этом месте пока не найдется расхождение, т.е. чтобы любой не-лист с глубиной больше 5 встречался хотя бы дважды в тексте.

Почему в векторных расширениях (SSE/AVX) архитектур x86 и x64 из горизонтальных операций до сих пор есть только сложение и вычитание? Почему нет хотя бы умножения и деления, я уже не говорю о большем, таком, как минимум, максимум, сравнение и прочее.

Ещё один прозрел. Что не Интел и не АМД не умеют делать нормальные процы.

Можно было бы в маске задавать операции горизонтальные(умножение,сложение,min,max и деление)
https://gamedev.ru/flame/forum/?id=292760&m=6115729#m12

prowkan
> Почему в векторных расширениях (SSE/AVX) архитектур x86 и x64 из горизонтальных операций до сих пор есть только сложение и вычитание? Почему нет хотя бы умножения и деления, я уже не говорю о большем, таком, как минимум, максимум, сравнение и прочее.
>
>
А зачем? Все же и так купят новый процессор, потому что он же мощнее ))

prowkan
> Почему в векторных расширениях (SSE/AVX) архитектур x86 и x64 из горизонтальных операций до сих пор есть только сложение и вычитание?

Потому что все эти расширения развивались от потребностей. Сперва сделали параллельную обработку массивов - супер. Потом поняли что для умножения векторов было бы удобно шаффлить вот тут и тут - сделали. Потом поняли, что для перемножения матриц было бы круто горизонтально сложить - сделали. И т.п.

Все это уже понимали в 18 веке.

А до Интела и АМД дошло как в том анекдоте до жирафа на третий день :)

prowkan
> Почему в векторных расширениях (SSE/AVX) архитектур x86 и x64 из горизонтальных операций до сих пор есть только сложение и вычитание?
Это какие? Везде для prefix sum нужно перестановки делать

haddps горизонтальное сложение.