В моем array метод last_index() возвращает int — последний валидный индекс в массиве или -1.
node_index это unsigned int; должно приводится без сайдэффектов здесь.
DG>Может быть подскажете, что не так делаю? DG>И еще вопрос параллелльно : на сколько ваш array по быстродействию выигрывает у vector? Думаю, измерения проводились...
Мой массив в его ьекущей инкарнации работает с абсолютно той же скоростью что и std::vector.
В ситуациях например типа array< smart_ptr<something> > мой работает на insert/append быстрее. Иногда значительно. Все мои классы позиционно независимы поэтому я могу себе позволить memcpy.
Что требует определенной дисциплины. Поэтому я его и не выкладываю.
CS>В моем array метод last_index() возвращает int — последний валидный индекс в массиве или -1. CS>node_index это unsigned int; должно приводится без сайдэффектов здесь.
Смотрим array.h:
const element&
last_index () const
{
return _size — 1;
}
Видимо, вместо const element& нужно int? Подправил — работает
Еще по одному вопросу не могу сообразить (что-то в 3 часа ночи не думается)
Здравствуйте, Dr.Gigabit, Вы писали:
DG>Смотрим array.h: DG> const element& DG> last_index () const DG> { DG> return _size — 1; DG> } DG>Видимо, вместо const element& нужно int? Подправил — работает DG>Еще по одному вопросу не могу сообразить (что-то в 3 часа ночи не думается)
У-у-у, какая древность, но все равно спасибо, надо опять на SF идти изменять а там все не просто.
Да конечно нужно так:
inline const element& last () const;
inline int last_index () const
{
return _size - 1;
}
DG>Выводит 1. Каким образом слова отображать-то? DG>В своей реализации TST я использую vector<char*> resultSet; DG>А как с dword'ом быть?
CS>Второй вариант — воспользоваться предлагаемой имплементацией ternary tree [2]:
[skiped]
Не могли бы вы прояснить такую вещь:
При записи всех узлов в бинарный файл, количество записываемых узлов 107184
(значение, возвращаемое total_nodes() ). Но в одном из узлов lokid имеет значение 4294967295
В то же время при проецировании бинарного файла, в который предварительно записаны все узлы, в память,
их количество 3435973836 (проверяю в цикле, пока указатель не NULL)
Как locid может иметь значение, большее кол-ва узлов? Или я где-то не прав?
Есть серьезный недостаток — требовательность к памяти. Чем длиннее ключ — тем больше хавает. А если ключи еще и различаются в начале — вообще абзац.
Проверял практическим способом
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, c-smile, Вы писали:
CC>Есть серьезный недостаток — требовательность к памяти. Чем длиннее ключ — тем больше хавает. А если ключи еще и различаются в начале — вообще абзац.
Ну в общем и целом утверждение "требовательность к памяти" справедливо для любой конструкции такого рода.
Для hash tables нужно тоже где-то ключи хранить.
Причем если ключи примерно такого типа:
Здравствуйте, c-smile, Вы писали:
CS>Ну в общем и целом утверждение "требовательность к памяти" справедливо для любой конструкции такого рода. CS>Для hash tables нужно тоже где-то ключи хранить.
Но там то ключи фиксированного размера = размеру хеша. А хеш можно посчитать по ооочень длинной строке.
CS>Причем если ключи примерно такого типа: [skipped] CS>То оверхед у hash-table по памяти будет больше.
Это понятно, речь не об этом. Сравнивать его лучше с Patricia как с близким по принципу действия.
Впрочем вы с cranky и так уже пересеклись
Когда я запхал в него и в patricia телефонный справочник (номер + фио как один ключ — все ключи уникальны) то ternary отожрал больше гига памяти. Тут просто трабл в том, что на 1 символ ключа выделяется +3*sizeof (uint). И в ситуации, когда ключи различаются в самом начале (Ex: "123 мама мыла раму" "124 мама мыла раму" "223 мама мыла раму" и т.д.) то оверхед получается максимальным — все "хвосты" ключей добавляются в nodes, а это 13 байт на char.
Также этот алго проигрывает в случае если ключи — пути к файлам. К примеру список всех файлов HDD с путями: 99519 строк. Ternary: 32.9 Mb 15508 CPU ticks per lookup, Patricia: 23.8 Mb 3811 CPU ticks per lookup.
Но на простых текстах (выборка всех слов из 400 мб. текстовика: слил много книг в 1 txt файл) Ternary рвет patricia с отрывом в 3-5 раз по скорости и почти в 2 раза по памяти. Но при этом следует учесть что Patricia хранит имена ключей.
IMHO ternary алго отличный, но область применения ограничена по причине зависимости потребления ресурсов от входных данных.
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, c-smile, Вы писали:
CS>>Ну в общем и целом утверждение "требовательность к памяти" справедливо для любой конструкции такого рода. CS>>Для hash tables нужно тоже где-то ключи хранить. CC>Но там то ключи фиксированного размера = размеру хеша. А хеш можно посчитать по ооочень длинной строке.
Но сами строки в полном виде ты хранить тоже обязан для разрешения коллизий.
Так что хэш таблица как структура тоже зависит от длины ключа.
CS>>Причем если ключи примерно такого типа: [skipped] CS>>То оверхед у hash-table по памяти будет больше.
CC>Это понятно, речь не об этом. Сравнивать его лучше с Patricia как с близким по принципу действия. CC>Впрочем вы с cranky и так уже пересеклись
CC>Когда я запхал в него и в patricia телефонный справочник (номер + фио как один ключ — все ключи уникальны) то ternary отожрал больше гига памяти. Тут просто трабл в том, что на 1 символ ключа выделяется +3*sizeof (uint). И в ситуации, когда ключи различаются в самом начале (Ex: "123 мама мыла раму" "124 мама мыла раму" "223 мама мыла раму" и т.д.) то оверхед получается максимальным — все "хвосты" ключей добавляются в nodes, а это 13 байт на char.
[skiped].
На самом деле возможны варианты.
1) Хранить хвосты после последних развилок как фрагменты строк т.е. получается 1/2 байта (char/wchar) на 1 символ.
2) Ввести ограничение на длину ключа — а дальше collision tables.
Да, еще нужно обратить внимание что алгоритм зависит от способа наполнения — если ключи
поступают в случайном порядке то дерево получается более отимальным чем в случае с "по порядку"
Здравствуйте, c-smile, Вы писали:
CS>Но сами строки в полном виде ты хранить тоже обязан для разрешения коллизий. CS>Так что хэш таблица как структура тоже зависит от длины ключа.
Верно. Упустил из виду...
CS>На самом деле возможны варианты.
CS>1) Хранить хвосты после последних развилок как фрагменты строк т.е. получается 1/2 байта (char/wchar) на 1 символ.
Верно. Но надо уже смотреть на реализацию: ведь тогда как я понимаю надо будет при вставке если возникнет необходимость эти хвосты разрезАть.
CS>2) Ввести ограничение на длину ключа — а дальше collision tables.
ИМХО это уже неправильно.
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, c-smile, Вы писали:
CS>Второй вариант — воспользоваться предлагаемой имплементацией ternary tree [2]:
CS>Замечания по имплементации: CS>1) Я использую свой array который может быть легко заменен на std::vector
Попал в интересную ситуацию...
следующий код нормально отрабатывает в Debug, в релизе валится.
Компилятор VC6, VC2003 Release (/O1 или /O2)
--------------------------------------------------
Прошу прощения за столь длинный код, но валится именно на таком количестве.
Если заменить std::vector на std::deque то всё нормально.
Если удалить хотя бы одну строчку вставки ttree.insert(...); то тоже всё нормально.
Вот такие дела....
Сам не смог разобраться...
---------------------------------------------------