Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "Потрепаться";
Текущий архив: 2002.09.05;
Скачать: [xml.tar.bz2];

Вниз

Окончание   Найти похожие ветки 

 
AL2002   (2002-08-07 11:18) [0]

Написал я это паскудство, которое файл сжимает.
Не буду говорить, сколько я, мать его, времени и нервов угробил. Расскажу, что получилось.
В общем эта сволочь может паковать любой файл. Но мне очень интересно, какой дурак будет запаковывать, если 1000 байт запаковывается в ~990-995 байт. Особенно, если время обработки этой тысячи занимает в лучшем случае 10-15 секунд. Кстати, я не учитываю, что для склеивания 1000-байтных кусочков придётся потерять как минимум два байта на каждую тысячу.

Вот такой подсчёт:
Возьмём файл на один метр.
В самом лучшем случае он будет обрабатываться три часа с хреном и будет весить в лучшем случае 0,990 метра.

Спрашавается, на какой хрен кому-то нужен будет такой, мать его, архиватор?


 
Mike B.   (2002-08-07 11:23) [1]

Может ты плохие алгоритмы применял?


 
Alx2   (2002-08-07 11:26) [2]

>AL2002 © (07.08.02 11:18)
Кстати, для любого архиватора можно подобрать файл (и приличного размера), который он раздует :)


 
kull   (2002-08-07 11:26) [3]

Попробуй еще раз.
Во второй раз сожмется лучше.

А еще хорошо код заново и начисто переписать, тоже лучше получится.


 
KSergey   (2002-08-07 11:26) [4]

Не совсем понятно а зачем он делался...


 
AL2002   (2002-08-07 11:27) [5]

Лучше работать не будет.
Я просто хочу узнать, стоит ли её до ума доводить при таких характеристиках?


 
Mike B.   (2002-08-07 11:42) [6]

При таких ее лучше написать заново с использованием нормальных алгоритмов. И все-таки: для чего программа предназначается и каким способом она у тебя пакует файлы?


 
Слесарь Матерящийся   (2002-08-07 11:45) [7]

Сравни с bzip2. Если проигрывает по степени сжатия -- то не стоит "доводить до ума".

bzip2 -- rulezz


 
Mike B.   (2002-08-07 11:45) [8]

Да и какие файлы ты пакуешь, а то может они в принципе не упаковываются :-)


 
AL2002   (2002-08-07 11:48) [9]

2Mike B.
Задача была описать 1000 байт меньшим количеством байтов.
Хочу просто узнать будет ли спрос на мою прогу?
Лично мне проще на компакт записать без всякого сжатия и не тратить пары суток, чтобы получить 600Кб вместо 1000.


 
AL2002   (2002-08-07 11:50) [10]

>Да и какие файлы ты пакуешь, а то может они в принципе не
>упаковываются :-)
Любые. Берётся зип или рар или мп3 и обрабатывается.


 
Mike B.   (2002-08-07 11:51) [11]

> AL2002 ©
Ну 990 байт вместо тысячи это не сжатие, сам понимаешь, так что на большой спрос вряд ли можно рассчитывать


 
Mike B.   (2002-08-07 11:54) [12]

Пытаться дополнительно упаковать зиповский или раровский архив практически бесполезно, можешь даже увеличение размера получить.
В мп3, по-моему, тоже избыточность информации небольшая, так что они хорошо сжиматься не будут


 
VAleksey   (2002-08-07 11:56) [13]

Я так понял, что ты уже сжатые файлы пытаешся еще раз сжать ? :))


 
AL2002   (2002-08-07 11:57) [14]

Да, времени угробил порядочно. Лучше бы шифровщик написал.

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



 
AL2002   (2002-08-07 11:59) [15]

>Я так понял, что ты уже сжатые файлы пытаешся еще раз
>сжать ? :))
Да, сжатые, но очень долго. Не надо прикалываться, только скажите объективно, нужна такая прога или нет.


 
Mike B.   (2002-08-07 12:01) [16]

> AL2002 ©
>Но потом можно опять сжать тот файл, что получился. И так где->то до десяти килобайт. Правда, сколько это времени займёт, я не >знаю. Может, месяц.
Алгоритмы сжатия основаны на поиске и представлению в более компактном виде избыточной информации в файле. Так что в архивном файле такой избыточной информации будет мало или (в идеале) вообще не будет. Поэтому пытаться сжать уже однажды архивированый файл бесполезно, большой степени сжатия ты не добъешся, даже может быть наоборот увеличение размера


 
Johnmen   (2002-08-07 12:39) [17]

>AL2002 © (07.08.02 11:57)
>Но потом можно опять сжать тот файл, что получился.
>И так где-то до десяти килобайт

А почему только до 10К ? Может быть лучше до 10 байт ?
Ж:-)


 
AL2002   (2002-08-07 13:06) [18]

>А почему только до 10К ? Может быть лучше до 10 байт ?
Нет. Меньше 10К уже низя.

Но так никто и не сказал, будет ли пользоваться спросом такая программа.


 
Leran2002   (2002-08-07 13:11) [19]


> AL2002 © (07.08.02 13:06)

Мужик бросай прикалываться с этим, ведь архиваторов полно, и врядли нам смертным получиться написать лучше...


 
AL2002   (2002-08-07 13:20) [20]

Короче, ясно. Будет время, доведу до ума и выложу, хотя бы как демку о том, что файлы можно сжимать до 10Кб.


 
VAleksey   (2002-08-07 13:30) [21]


> AL2002 © (07.08.02 13:20)

Не, точно не будет спросом пользоваться.
Но если написал, то утебя уже есть хорошая практика :). А это неплохо.


 
Кулюкин Олег   (2002-08-07 13:31) [22]

2 AL2002 © (07.08.02 13:20)
А почему не до 1 байта?

У меня когда-то тоже была мысль архиваировать заархивированное :)


 
esu   (2002-08-07 14:35) [23]

Я так и не понял, а разархиватор ты уже написал ?
Пришли мне на мыло, если она zipы хоть на 0.5-1% сжимает и разпаковывает их потом.


 
Ketmar   (2002-08-07 18:24) [24]

насчет зипов: 7-Zip. сжимает лучше стд. зипов, распаковывается любым штатным анзиппером.

Satanas Nobiscum!
7-VIII-XXXVII A.S.


 
anpsoft   (2002-08-07 18:53) [25]

или я тут ничего не понял, или остальные :)
но автор наверное вел речь о том курьезном случае когда в интернете предложили вознаграждение за создание архиватора, который выдаст после упаковки файла предоставленного организатором конкурса файл хоть на 1 байт короче.
И один парень чуть было не получил. Он как раз хотел сыграть на разбиении файла на куски.
Если не ошибаюсь суть в том что к примеру что файл с
1234567890432465435 можно разбить на несколько, разбив по какому-либо байту - например 0. сам 0 не писать никуда
в итоге 2 файла будут в нашем случае на 1 байт короче.
Но устроитель конечно не признал все это :)
Так как это все чушь, физически в нашем случае к примеру размер почти удвоиться, на размер записи в fat таблице :)

Так что обломилось :)
Но устроитель и сам виноват, не совсем корректно описал задание.



 
AL2002   (2002-08-07 18:57) [26]

1234567890432465435 можно элементарно сжать, потому что из 256 кодов ASCII здесь только 10.


 
Сергей Суровцев   (2002-08-07 20:32) [27]

>AL2002 ©
Ладно тебе, не расстраивайся, может с ИИ лучше получится?

>AL2002 © (07.08.02 18:57)
>1234567890432465435 можно элементарно сжать, потому что из 256 >кодов ASCII здесь только 10.
А как ты будешь хранить информмацию об их последовательности?


 
AL2002   (2002-08-07 20:46) [28]

>А как ты будешь хранить информмацию об их последовательности?
Последовательно.


 
drpass   (2002-08-07 20:59) [29]

>AL2002
Не расстраивайся. Мой друг придумал новый алгоритм архивации, а когда реализовал его в проге, то на выходе из exe-файла весом 400К он получил фиг_знает_что весом 600К :)


 
AL2002   (2002-08-07 21:08) [30]

>Не расстраивайся
Да не расстраиваюсь я. Всё таки получилось же.
Только со скоростью ничего нельзя сделать.


 
lak_b   (2002-08-08 00:32) [31]

2AL2002 ©
не огорчайся;-) задача не из лёгких...



 
igorr   (2002-08-08 02:25) [32]

2AL2002

1. На каком языке делал?
2. Делал ли к нему анализатор возможного сжатия?
(т.е. наличие повторяющихся участков кода)
Я к тому, что может быть уже нечего было ужимать.
3. Какой формат упакованных данных? (просто ради интереса,
т.е. сколько байт у тебя получится после упаковки:
FF 01 FF 01 FF 01 FF 01 FF 01 FF 01)


 
KSergey   (2002-08-08 09:36) [33]

Странно, на автор вопроса так и не ответил не на один из поставленных вопросов, поэтому ничего и не понятно.
1) Что значит "лобой файл ужать до 10К"? Причем много было вопросов почему ен бо 1 байта, но ответов так и не последовало. А действительно: почему?? И именно любой исходный? Т.е. рабмером, например, 100Мб? Или я что-то не понял?

2) Так какой алгоритм использовался? Он был выдуман или взят какой-то готовый стандарнтый (описанный, изученный)?

3) Так и остался открытым вопрос: предполагается сжатие само по себе, или оно должно быть обратимым? Т.е. использованный алгоритм предполагает, что потом информацию можно восстановить обратно или нет? Или суть просто сжать, а восстанавливать не обязательно? (а то при такой постановке задачи я запросто йжму любой файл до 1 бита - просто отсечением ;) восстнавливать-то необязательно)

4) Изначально вопрос ставился как "сжать любой файл", но почему-то автор (судя по постам) упорно жмет только файлы 2 типов: архивы, упакованные другими архиваторами, и mp3-файлы. Почему?? Тут пожалуй стоит отметить, что ужимать архивы, равно как и mp3-файлы - практически безполезно. Не знаю на счет mp3, но в архивах избыточности практически нет, есть только избыточность только в заголовке, где перечислены имиена файлов.

Так будьте добры. осветите наконец эти интересующие всех вопросы.

[А то все про время жа про время.. Да до лампочки оно! Если вы придумаете обратимую методику сжания информации, при помощи которой можно будет жать любой файл до наперед заданного размера - про время работы этого алгоритма никто и не заикнется! Это уже будет абсолютно неважно! Вот только пока не придумано такого...]


 
Igorek   (2002-08-08 10:29) [34]

2 AL2002 © (07.08.02 21:08)
Если хочешь, что бы получилось что-то стоящее, то залезь в теорию сжатия информации (или как там она называется). Дело в том что самые эффективные алгоритмы уже реализованы. Если хочешь сделать свой покруче, то без открытия в этой области не обойтись.

---
Learn, work and hope...


 
AL2002   (2002-08-08 10:35) [35]

>[А то все про время жа про время.. Да до лампочки оно! Если вы
>придумаете обратимую методику сжания информации, при помощи
>которой можно будет жать любой файл до наперед заданного
>размера - про время работы этого алгоритма никто и не
>заикнется! Это уже будет абсолютно неважно! Вот только пока не
>придумано такого...]
Точно до лампочки?


 
KSergey   (2002-08-09 07:54) [36]

AL2002 © (08.08.02 10:35)
>Точно до лампочки?

Могу Вас заверить со 100% уверенностью! И вот почему.

Даже если вы покажете (имеются в виду математические выкладки, а не комбинации из пальцев, к примеру ;), что вот таким-то методом можно обратимо ужать любую информацию конечного объема до любого наперед заданного размера (меньше исходного, желательно ;), и даже если время, необходимое на такую операцию, будет стремиться к бескоечности - ну Нобелевка не Нобелевка, но то, что это теоретическое изыскание войдет во все учебники соотв. профиля - я Вам гарантирую!

Просто пока (на сколько я ориентируюсь в данной проблематике) такая постановка задачи противоречит современным представлениям о материальном мире, вот в чем вся штука... Но с другой стороны - почему бы и нет? Дерзайте! Теория относительности Энштейна тоже противоречит законам Ньютона (да простят меня эстеты, возможно я не совсем верно выражаюсь, но суть, согласитесь, верна), однако же ее справедливость доказана экспериментально, что говорит о том, что она все же верно описывает наш материальный мир, просто до ее открытия наши представления о нем (о мире) были более узкими, нежели теперь. Так что дерзайте, расширяйте! (В этих словах нет издевки, я серьезно. Кто ищет - тот всегда найдет.)

И все же, я никак не пойму: почему нет таки ответов на поставленные вопросы? Пожалуй если их не будет и в дальнейшем - придется потерять интерес к данной ветке, причем приняв таки мнение, высказанное anpsoft (07.08.02 18:53), которое, заметьте, Вас не красит...

[я умышленно еще раз многое повторил из своего предыдущего поста, т.к. там было очень много опечаток; здесь вроде меньше ;)]



Страницы: 1 вся ветка

Форум: "Потрепаться";
Текущий архив: 2002.09.05;
Скачать: [xml.tar.bz2];

Наверх





Память: 0.54 MB
Время: 0.008 c
14-14237
Invega
2002-08-10 12:12
2002.09.05
Мне нужен пример ftp клиента


3-13924
Uran
2002-08-13 14:24
2002.09.05
Ограничение доступа с помощью BExpert


3-13907
Павел Н.
2002-08-15 05:31
2002.09.05
ADO и добавление записей


1-14072
djonny
2002-08-26 22:41
2002.09.05
Как работать с диалогом, находящимся в ресурсе.


3-13949
minva
2002-08-15 22:49
2002.09.05
И снова приходится делать Insert





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский