Мастера DELPHI, Delphi programming community Рейтинг@Mail.ru Титульная страница Поиск, карта сайта Написать письмо 
| Новости |
Новости сайта
Поиск |
Поиск по лучшим сайтам о Delphi
FAQ |
Огромная база часто задаваемых вопросов и, конечно же, ответы к ним ;)
Статьи |
Подборка статей на самые разные темы. Все о DELPHI
Книги |
Новинки книжного рынка
Новости VCL
Обзор свежих компонент со всего мира, по-русски!
|
| Форумы
Здесь вы можете задать свой вопрос и наверняка получите ответ
| ЧАТ |
Место для общения :)
Орешник
Коллекция курьезных вопросов из форумов
Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / rsdn.org

 
Чтобы не потерять эту дискуссию, сделайте закладку « предыдущая ветвь | форум | следующая ветвь »

Сжатие


Jpacslovas ©   (07.06.19 18:22

Чем вам не нравится мое сжатие я все проверил работает я скоро сделаю распаковщик.


xayam ©   (07.06.19 18:34[1]

а твой алгоритм сжимает 1ГБ в байт?
иначе он нам не нужен


Inovet ©   (07.06.19 18:37[2]

Сжимает, но распаковщик ещё не написал.


xayam ©   (07.06.19 18:42[3]


> Inovet ©   (07.06.19 18:37) [2]
> Сжимает, но распаковщик ещё не написал.

вот! не написал распоковщик в 1 байт
а у меня уже есть распоаковщик из 1 бита...
долго бился но в конце концов  своего добился

так что однобайтовые распаковщики это прошлый век.
Сейчас мода и тренд на пустотные распаковщики
это когда из ничего распаковывают - вот где сила


xayam ©   (07.06.19 18:46[4]


> это когда из ничего распаковывают - вот где сила

по сути - это телепортация. Квантовая физика говорит что она возможна


Kerk ©   (07.06.19 18:55[5]


> Jpacslovas ©   (07.06.19 18:22)

Ты объясни нормально словами чего хочешь :)


Jpacslovas ©   (08.06.19 20:16[6]

Шифруем файл моим методом потом сжимаем с помощью .paq повторяем это циклично итак можно сжать видео, фотографии, музыку и многие другие фалы из 1МБ в 10КБ.


xayam ©   (08.06.19 20:42[7]


> Jpacslovas ©   (08.06.19 20:16) [6]
> Шифруем файл моим методом потом сжимаем с помощью .paq повторяем
> это циклично итак можно сжать видео, фотографии, музыку
> и многие другие фалы из 1МБ в 10КБ.

ну так напиши распаковщик.
Чего ты от ветки хочешь? В чем вопрос?
Вопроса нет - у меня все хорошо, сжимает в сто раз...
Чего языком молоть?


KSergey ©   (11.06.19 11:26[8]

> xayam ©   (07.06.19 18:46) [4]
> > это когда из ничего распаковывают - вот где сила
>
> по сути - это телепортация. Квантовая физика говорит что она возможна

Внезапно может оказаться, что на это потребуется бесконечное время.

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

Очень это подозрительно. Чего-то явно не договаривают про информацию. Она таки материальна? А если нет - то что мы передаём по проводам? (при том, что на саму передачу этого не пойми чего энергия вполне себе затрачивается)


xayam ©   (11.06.19 13:50[9]


> > по сути - это телепортация. Квантовая физика говорит что
> она возможна
> Внезапно может оказаться, что на это потребуется бесконечное
> время.

для вневременнОго существа вряд ли


Inovet ©   (11.06.19 14:47[10]

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


xayam ©   (11.06.19 15:32[11]


> надо чтобы распаковщик распаковывал то, что ему укажут

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


xayam ©   (11.06.19 15:58[12]

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


Jpacslovas ©   (22.06.19 13:30[13]

Вот сжатие и разжатие можно скачать здесь:

https://github.com/pjmidgard/Rexx-Software?files=1


xayam ©   (22.06.19 14:36[14]

а бинарники будут или каждому самому разбираться с этими исходниками?
документация?


Kerk ©   (22.06.19 15:26[15]


> Jpacslovas ©   (22.06.19 13:30) [13]

А что с этим делать? Извиняюсь за глупый вопрос


xayam ©   (22.06.19 15:30[16]


> А что с этим делать? Извиняюсь за глупый вопрос

язык по ходу скриптовый :)


Jpacslovas ©   (22.06.19 18:31[17]

Заходим суда и скачиваем интепритатор:
https://sourceforge.net/projects/regina-rexx/


xayam ©   (22.06.19 18:57[18]


> Jpacslovas ©   (22.06.19 18:31) [17]
> Заходим суда и скачиваем интепритатор:
> https://sourceforge.net/projects/regina-rexx/

это ты будешь говорить каждому пользователю твоего супер-пупер алгоритма?


xayam ©   (22.06.19 19:04[19]

поэтому я думаю надо переписать на Lazarus например -
и кроссплатформенность, и бинарник 32/64-хбитные, и бесплатно

как пример оформления посмотри 7-zip - отдельный сайт для программы,
бинарник для командной строки, интерфейс gui есть, документация.

А в твоем случае? Кто из нормальных пользователей будет качать еще
отдельно интерпретатор?


brother ©   (14.08.19 14:44[20]

однажды я тоже думал, что написал архиватор. Но потом так и смог распаковать сжатые данные)


xayam ©   (14.08.19 15:35[21]


> Но потом так и смог распаковать сжатые данные

новость дня:
для того, кто умеет предсказывать,
тому не нужен сжимаемый файл :)

(c) Интернет (не помню где прочитал)

а если бы все умели предсказывать, то не нужен был  бы и сжатый файл :)


Кщд2 ©   (15.08.19 07:47[22]

>Jpacslovas ©   (08.06.19 20:16) [6]
>Шифруем файл моим методом потом сжимаем с помощью .paq повторяем это циклично итак можно >сжать видео, фотографии, музыку и многие другие фалы из 1МБ в 10КБ.
а ещё говорят, что кончились кулибины на Руси!
жму руку и восхищаюсь!
у меня вопрос из практической области: можно ли с помощью Вашего алгоритма сжимать фотоны и запасать их на зиму (в трёхлитровых банках из-под абрикосового сока)?


kilkennycat ©   (15.08.19 20:52[23]


> Кщд2 ©   (15.08.19 07:47) [22]

Взрослый, а глупый. Всем ведь известно, что банки из-под абрикосового не годятся.


Inovet ©   (15.08.19 21:55[24]

> [23] kilkennycat ©   (15.08.19 20:52)
> банки из-под абрикосового не годятся.

Из-под огурцов, помидоров, капусты - осенние банки. Может, тогда из-под клубничного вараенья? Или малинового.


Кщд2 ©   (16.08.19 06:30[25]

>Inovet ©   (15.08.19 21:55) [24]
>Или малинового.
нет
эти пригодны лишь для консервирования сиреневого тумана

впрочем, автору не до наших скудоумных измышлений
надеюсь, что за заслуги перед человечеством его произвели в сиятельные короли РАЕН и прижизненно мумифицировали


DayGaykin ©   (16.08.19 15:25[26]

Интересно, какими будут алгоритмы сжатия через 100 или 500 лет. Насколько эффективнее и быстрее нынешних. Или архивирование станет никому не нужным вовсе.


Kerk ©   (17.08.19 00:35[27]


> DayGaykin ©   (16.08.19 15:25) [26]

Сжатие данных на лету всегда нужно будет. Как иначе онлайн-стриминг 118K видео будет работать? :)


xayam ©   (17.08.19 05:46[28]


> Как иначе онлайн-стриминг 118K видео будет работать?

не иначе как на пегом дудочнике :)


Германн ©   (27.08.19 02:51[29]


> DayGaykin ©   (16.08.19 15:25) [26]
>
> Интересно, какими будут алгоритмы сжатия через 100 или 500
> лет. Насколько эффективнее и быстрее нынешних.

Ни на сколько не будет. Максимум на доли процента.


Dimka Maslov ©   (27.08.19 09:28[30]


> Ни на сколько не будет. Максимум на доли процента.


Если цивилизация не загнётся, то прогресс пойдёт увеличения ёмкости/производительности носителей, а сжатие будет никому не нужно.


KSergey ©   (27.08.19 14:07[31]

> Dimka Maslov ©   (27.08.19 09:28) [30]
> а сжатие будет никому не нужно.

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

Да хотя бы даже пресловутые видеокодеки - нормально себе живут и развиваются. Как пример, когда алгоритмы какого-либо сжатия - живее всех живых.


KSergey ©   (27.08.19 14:10[32]

Одно мне не понять: Win95 работала на 4 МБ памяти. 8 - просто роскошь, когда уже совсем было хорошо. Включая офис там и проч. Т.е. вместе с программами.

Win10 работает за 8 ГБ памяти ровно также, включая запущенный софт.

Вопрос: что программисты делают не так?


Dimka Maslov ©   (27.08.19 14:38[33]


> Это только видимость для того,


Мы же смотрим на 100 тире 500 лет вперёд?


Германн ©   (28.08.19 02:35[34]


> KSergey ©   (27.08.19 14:07) [31]

Алгоритмы сжатия дошли уже до максимума.


Германн ©   (28.08.19 02:38[35]


> KSergey ©   (27.08.19 14:10) [32]
>
> Одно мне не понять: Win95 работала на 4 МБ памяти. 8 - просто
> роскошь, когда уже совсем было хорошо. Включая офис там
> и проч. Т.е. вместе с программами.
>
> Win10 работает за 8 ГБ памяти ровно также, включая запущенный
> софт.
>
> Вопрос: что программисты делают не так?
>

Ты забыл про "плюшки". :)


Dimka Maslov ©   (28.08.19 09:36[36]


> Ты забыл про "плюшки". :)


Может и не плюшки, а что-то другое. Как-то в прошлом году пришла ко мне идея ознакомиться с С++17, что я и сделал. Не так давно решил проверить производительность "старого" кода и "нового". За счёт проведённой ревизии тонких мест и их оптимизации я ожидал 20-30% прирост в скорости. Но получил код на 10-15% м е д л е н н е е. Это всё "стандартная библиотека" которая и тормозит от версии к версии всё больше. Что за плюшки они туда пихают - никому не известно.


KSergey ©   (28.08.19 12:07[37]

> Dimka Maslov ©   (28.08.19 09:36) [36]
>  Не так давно решил проверить производительность "старого" кода и "нового".

Тонкие места выявлялись профайлером или логикой? Это важно.

А вообще да, С++ он слишком много знаний требует "что там под капотом". Слишком - ключевое слово для меня. Особенно в новомодных причиндалах.


Dimka Maslov ©   (28.08.19 13:21[38]


>
> Тонкие места выявлялись профайлером или логикой?


Всеми доступными разрешёнными законом способами.


KSergey ©   (28.08.19 13:48[39]

Вы хотите "опорочить" новую библиотеку, но говорите, что предварительно провели манипуляции с кодом.
Вот что меня смущает в эксперименте :)


Dimka Maslov ©   (28.08.19 14:16[40]


> KSergey ©   (28.08.19 13:48) [39]


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


kilkennycat ©   (28.08.19 19:01[41]


> Германн ©   (28.08.19 02:35) [34]
>
> > KSergey ©   (27.08.19 14:07) [31]
>
> Алгоритмы сжатия дошли уже до максимума.


только на текущей архитектуре.


Германн ©   (29.08.19 02:06[42]


> kilkennycat ©   (28.08.19 19:01) [41]
>
>
> > Германн ©   (28.08.19 02:35) [34]
> >
> > > KSergey ©   (27.08.19 14:07) [31]
> >
> > Алгоритмы сжатия дошли уже до максимума.
>
>
> только на текущей архитектуре.
>  

О какой архитектуре речь? И коим образом алгоритмы зависят от вышеупомянутой?


KSergey ©   (29.08.19 08:22[43]

> Dimka Maslov ©   (28.08.19 14:16) [40]
> А если взять старый код и перекомпилировать его, получится больший размер медленней работающего кода.

Про большие размер спорить не буду, это отдельная для меня загадка, хотя я и могу предположить одну здравую версию помимо теории заговора.
А вот скорость - она тестировалась? или это предположение?
В самом деле, не будете же вы утверждать, что "больший объем -> гарантированно медленнее работа".


Dimka Maslov ©   (29.08.19 11:34[44]


> KSergey ©   (29.08.19 08:22) [43]


Она тестировалась. Она уменьшается от версии к версии компилятора.


KSergey ©   (29.08.19 13:12[45]

Тогда пичаль


kilkennycat ©   (29.08.19 19:48[46]


> Германн ©   (29.08.19 02:06) [42]

> какой архитектуре речь? И коим образом алгоритмы зависят от вышеупомянутой?

странный вопрос.


Германн ©   (30.08.19 02:14[47]


> kilkennycat ©   (29.08.19 19:48) [46]
>
>
> > Германн ©   (29.08.19 02:06) [42]
>
> > какой архитектуре речь? И коим образом алгоритмы зависят
> от вышеупомянутой?
>
> странный вопрос.
>

Говоря про алгоритм сжатия я имел в виду сначала логику, а после неё математику. Логика точно не зависит ни от какой архитектуры. Математика конечно зависит отчасти. Но это уже проблема не алгоритма, а его практической реализации.


KSergey ©   (30.08.19 08:08[48]

> kilkennycat ©   (29.08.19 19:48) [46]
> странный вопрос.

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


Кщд2 ©   (30.08.19 08:48[49]

Германн ©   (28.08.19 02:35) [34]
>Алгоритмы сжатия дошли уже до максимума.

вот, надысь, в Удмуртии фрактальное сжатие на порядок ускорили фрактальное сжатие
с оговорками, но факт
https://cyberleninka.ru/article/v/tehnologiya-fraktalnogo-szhatiya-videoinformatsii
сделала это студентка Попова
заштатного (уж простите, ижевчане и ижевчанки) университета


Кщд2 ©   (30.08.19 08:49[50]

>фрактальное сжатие на порядок ускорили фрактальное сжатие
простите, что повторяюсь повторяюсь


Dimka Maslov ©   (30.08.19 09:47[51]


> Кщд2 ©   (30.08.19 08:48) [49]


При сжатии видео мы не обязаны на выходе получать ровно то же самое, что было на входе. Главное, чтобы глаз не сильно замечал помехи.
А во вторых, кто в 2016 году передавал 1,24 мегабайта за 2,5 минуты по ISDN каналу?!!


Кщд2 ©   (30.08.19 11:35[52]

>Dimka Maslov ©   (30.08.19 09:47) [51]
>При сжатии видео мы не обязаны на выходе получать ровно то же самое, что было на входе.
да
в данном случае, сжатие с потерей
это доказывает что?..

>А во вторых, кто в 2016 году передавал 1,24 мегабайта за 2,5 минуты по ISDN каналу?!!
как минимум, г-жа Попова
но, возможно, и некий Пантелеймон)


ВладОшин ©   (31.08.19 13:13[53]


>  кто в 2016 году передавал 1,24 мегабайта за 2,5 минуты
> по ISDN каналу?

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


kilkennycat ©   (31.08.19 16:39[54]


> Германн ©   (30.08.19 02:14) [47]
> KSergey ©   (30.08.19 08:08) [48]


мы не таблицу умножения обсуждаем, в которую можно смело просто верить и молиться, что она постоянна.
обсуждается алгоритм сжатия. Так вот, насколько б не был многозначным термин "архитектура", как впрочем, и "сжатие" - всякие заявления о чем-либо справедливы только на текущий момент.  Завтра выпустят трибитный проц с полуторакубитами, и понеслось очередное изобретение алгоритма. Послезавтра заказчик скажет: - тут на днях выяснилось, что бросание коробок с дисками в лестничный пролет можно оптимизировать, сжав пролеты.
И понеслось снова, уже с привлечением чернодырных физиков.
Так что, всякое приближение к чему-то идеальному - оно возможно лишь сейчас. Завтра будет другим. А может, и ваще не нужно будет.


Inovet ©   (31.08.19 18:54[55]

> [54] kilkennycat ©   (31.08.19 16:39)

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


kilkennycat ©   (31.08.19 23:23[56]


Inovet ©   (31.08.19 18:54) [55]
> Если о сжатии без потерь, то есть предел, через который никак не перелезть.

не уверен, что это так. Ты еще скажи, что эфира нету )


Inovet ©   (31.08.19 23:35[57]

> [56] kilkennycat ©   (31.08.19 23:23)
> Ты еще скажи, что эфира нету )

Это во второй части поста про ноль.


kilkennycat ©   (01.09.19 01:53[58]


> Inovet ©   (31.08.19 23:35) [57]

да. но я всё равно сомневаюсь, что тот предел, через который не перелезть -
а) реализуем (предполагается бесконечное стремление к нему)
б) универсальный для всех случаев


Dimka Maslov ©   (01.09.19 11:44[59]


> это доказывает что?..


Предел сжатия изображения с потерями был достигнут 100 лет ныне покойным Казимиром Малевичем, задолго до появления компьютеров.


Кщд2 ©   (02.09.19 04:56[60]

>Inovet ©   (31.08.19 18:54) [55]
>Если о сжатии без потерь, то есть предел, через который никак не перелезть.
да, т.к. математически доказано: для любой последовательности данных существует теоретический предел сжатия, который не может быть превышен без потери части информации.

но из этого не следует, что имеющиеся на данный момент алгоритмы этого предела достигли


KSergey ©   (02.09.19 06:36[61]

> Кщд2 ©   (02.09.19 04:56) [60]
> но из этого не следует, что имеющиеся на данный момент алгоритмы этого предела достигли

Имеющиеся алгоритмы отстают не очень сильно от этого теоретически посчитанного предела. Так что прорыва "на порядок" ждать не приходится.
В этом смысле мне искренне не понятно, почему на момент выхода rar он в самом деле жал заметно лучше zip. Вроде сейчас такого не наблюдается. Хотя, возможно, просто перестал я сравнивать сколь-нибудь внимательно итоговые размеры архивов, ибо неактуально.


Кщд2 ©   (02.09.19 07:34[62]

>KSergey ©   (02.09.19 06:36) [61]
>Имеющиеся алгоритмы отстают не очень сильно от этого теоретически посчитанного предела.
где можно увидеть расчёты?


KSergey ©   (02.09.19 07:52[63]

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


Styx ©   (02.09.19 10:11[64]

У rar принципиальное преимущество в возможности создания solid архивов. За счёт этого может быть многократный рост компрессии, если разные файлы похожи друг на друга.


Кщд2 ©   (02.09.19 11:47[65]

>KSergey ©   (02.09.19 07:52) [63]
>Помню что было в учебниках, в разделах энтропии применительно к теории информации.
>Но было давно и деталей (и даже место) я точно уже не припомню, конечно.
сам предел очень нагугливается: обратная теорема Шеннона
увы, ничего не нагугливается на тему близости текущих методов сжатия к пределу
поэтому: откуда выводы о принципиальной невозможности появления алгоритмов сжатия без потерь, имеющих существенно лучшие характеристики (степень сжатия)?


KilkennyCat ©   (04.09.19 01:56[66]


> Кщд2 ©   (02.09.19 11:47) [65]
> поэтому: откуда выводы о принципиальной невозможности появления
> алгоритмов сжатия без потерь, имеющих существенно лучшие
> характеристики (степень сжатия)?

из пальца, помещенного в ротовое отверстие и странной веры в разум человеков


KSergey ©   (04.09.19 07:17[67]

> Кщд2 ©   (02.09.19 11:47) [65]
> поэтому: откуда выводы о принципиальной невозможности появления
> алгоритмов сжатия без потерь, имеющих существенно лучшие характеристики (степень сжатия)?

Тут наверное вопрос в том, что взять за критерий сжатия.
Если, например, считать сколько байтов удавалось запихнуть на единицу объёма HDD в 90-х годах прошлого века и сейчас - то степень сжатия выросла просто на несколько порядков.

А вот если сравнивать в байтах объём архива, созданного pkzip в тех же 90-х прошлого века и современным 7-zip - то разница там будет не такая и разительная, хотя тоже заметная, конечно. но точно не про порядки речь.

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


Кщд2 ©   (04.09.19 08:25[68]

>KSergey ©   (04.09.19 07:17) [67]
это косвенные и во многом субъективные наблюдения/выводы, согласны?
достигнут современными алгоритмами предел или нет - это не вопрос веры, но математики


DayGaykin ©   (04.09.19 16:12[69]

Можно же меру энтропию измерить. Чем больше энтропия - тем лучше сжатие.


Кщд2 ©   (05.09.19 07:44[70]

>DayGaykin ©   (04.09.19 16:12) [69]
>Можно же меру энтропию измерить.
нужно
в рамках вопроса "достигли современные алгоритмы предела?" что это доказывает

>Чем больше энтропия - тем лучше сжатие.
наоборот


Leonid Troyanovsky ©   (05.09.19 12:22[71]


> Кщд2 ©   (05.09.19 07:44) [70]

> >Чем больше энтропия - тем лучше сжатие.
> наоборот

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

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

--
Regards, LVT.


Кщд2 ©   (06.09.19 06:41[72]

>Leonid Troyanovsky ©   (05.09.19 12:22) [71]

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

я об энтропии источника
именно она упоминается в теореме Шеннона


Inovet ©   (06.09.19 06:51[73]

Автор ветки пропал. Должно быть, написал запаковщик и рекурсивно запаковал им его самого, может и себя случайно.


Кщд2 ©   (06.09.19 12:47[74]

>Inovet ©   (06.09.19 06:51) [73]
Один мужчинка из села Савёлово
Засунул в свою попу свою голову.
Вскоре весь туда влез. И бесследно исчез.
Жаль - мужчинка был нрава весёлого!


версия для печати

Написать ответ

Ваше имя (регистрация  E-mail 







Разрешается использование тегов форматирования текста:
<b>жирный</b> <i>наклонный</i> <u>подчеркнутый</u>,
а для выделения текста программ, используйте <code> ... </code>
и не забывайте закрывать теги! </b></i></u></code> :)


Наверх

  Рейтинг@Mail.ru     Титульная страница Поиск, карта сайта Написать письмо