Need help! Не решается задача, упираюсь в ограничения железа - страница 10
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Делаю еще попытку.
Имеем три файла.
1. Л. Толстой. Война и мир, Том-1.
2. Л. Толстой. Война и мир, Том-2.
3. Ф. Достоявский. Прступление и наказание.
Запаковываем каждый из них.
Имеем три запакованых файл без названий (только не спрашивайте как я предствляю себе файл без имени). Еще имеем один незапакованый фал, пусть это будет "Преступление и наказание".
Как наиболее экономно найти этот файл в тех трех сжатых?
Вариант 1. Разжать все три файла и найти в нем искомый файл.
Вариант 2. Сжать искомый файл и найти точно такой же файл среди трех сжатых.
угу - поэтому предложенный Вами не годится
Да знаю, что если данные короткие, то при архивации увеличивается размер.
Ну если хотите продолжать в этом направлении, то для поиска можно и хеширование использовать или контрольную сумму, не обязательно кодировать сжатием. Создать индекс по хешам и методом дихотомии выполнять поиск.
Но это при наличии исходной порции в полном объеме.
Я например, в подобных случаях использую СУБД без всяких выкрутасов. И времени меньше затрачиваю на разработку, и продукт стабильный получается.
Вы парни всё правильно говорите, и это ещё раз подчёркивает что вариант сжатия должен быть обоснован под задачу.
Те плясать нужно от постановки задачи.
Ну если хотите продолжать в этом направлении, то для поиска можно и хеширование использовать или контрольную сумму, не обязательно кодировать сжатием. Создать индекс по хешам и методом дихотомии выполнять поиск.
Но это при наличии исходной порции в полном объеме.
Я например, в подобных случаях использую СУБД без всяких выкрутасов. И времени меньше затрачиваю на разработку, и продукт стабильный получается.
Так это не я предлагал. В любом случае идея интересная.
>>> Разговор про сравнение двух сжатых последовательностей.
Дима! напоминаю - вот о чем речь шла
как раз именно это мы разобрали на практике
>>> Да знаю, что если данные короткие, то при архивации увеличивается размер.
поэтому и не годится
--
поэтому и в промышленных базах нет этой идеологии
...
Ну если хотите продолжать в этом направлении, то для поиска можно и хеширование использовать или контрольную сумму, не обязательно кодировать сжатием. Создать индекс по хешам и методом дихотомии выполнять поиск.
Но это при наличии исходной порции в полном объеме.
Я например, в подобных случаях использую СУБД без всяких выкрутасов. И времени меньше затрачиваю на разработку, и продукт стабильный получается.
Integer:
Хорошая идея.а вот это можно попробовать
>>> Я например, в подобных случаях использую СУБД без всяких выкрутасов. И времени меньше затрачиваю на разработку, и продукт стабильный получается.
но лучше всего взять готовые промышленные SQL базы
>>> Разговор про сравнение двух сжатых последовательностей.
Дима! напоминаю - вот о чем речь шла
как раз именно это мы разобрали на практике
>>> Да знаю, что если данные короткие, то при архивации увеличивается размер.
поэтому и не годится
--
поэтому и в промышленных базах нет этой идеологии
...
а вот это можно попробовать
>>> Я например, в подобных случаях использую СУБД без всяких выкрутасов. И времени меньше затрачиваю на разработку, и продукт стабильный получается.
но лучше всего взять готовые промышленные SQL базы
Юрчик, я имел ввиду без выкрутасов с обработкой файлов, сжатием и т.п. Чисто работа с SQL и логикой робота/индикатора. Работал со многими БД, единственной проблемой было подружить MQL c SQL )), сделал красивое решение без всяких там массивов и структур.
В общем, я предпочитаю не изобретать велосипед, а решать задачи оптимальными средствами.
Думаю, что по другой причине. Потому-что там проблема загрузки больших данных в опреативку решена по другому, они не загружаются, а читаются непосредственно с диска. (наверно)
этим занимается сервер... причем очень эффективно