الگوریتم فشرده سازی

[Mehdi_FT]

من از بچه های با تجربه 11 ساله در برنامه نویسی هستم اما فکر کنم شما نه !

بابا شوخی کردم ناراحت نشو سابقت زیاد ولی نه به اندازه من :)
::درسته که بستر مقایسه IL هست. اما شما با استفاده از IL اون بحث بافرینگ که مطرح کردم را تحت شعاع قرار دادید. چون زمان اجرای کد شما توی IL آنقدر توی LOOP زیاد می شه باعث می شه زمان خواندن اطلاعات از بافر به چشم نیاد. در اون حالتی که کد شما سریعتر اجرا می شه بخاطر کمتر بودن کد اجرایی در IL هست::
همون رو تو C++‎ با API امتحان کن ببین چه نتیجه ای می گیری فرقی نمی کنی.

بهتره بدونی که سیستم عامل و حتی خود هارد دیسک اطلاعات خوانده شده از هارد دیسک را بافر می کنن ! پس حرف شما صحت نداره. بهتره بری کتاب سیستم عامل را یه نگاه بندازی تا متوجه بشی

نمی دانم شما چرا اینقدر اصرار داری روی این اشتباه روش خوندن اطلاعات (در برنامه نویسی) یا (بایتی و ساختاری) و یا خواندن کلی اصلا چه ربطی به بافر سیستم عامل داره پسر خوب برنامه بالا نشان می داد (دو روش خواندن اطلاعات با استفاده از برنامه نویسی)بایت به بایت خواندن با توجه به هر روشی که سیستم عامل داره از خواندن یکجا کندتر.
بعدم اگه قرار بود سیستم عامل اینقدر هوشمند باشه که با دست گذاشتن برنامه نویس روی هر فایلی خودش بافر کنه، خودش کنترل کنه دیگه لازم نیست برنامه برای مدیریت فایل برنامه بنویسیم سیستم عامل خودش همه چی درست میکنه (من خودم سیستم عامل درس میدم).
حالا اگه قبول نمی کنی من دیگه حرفی ندارم(شایدم آن اول منظورت ازبایت به بایت خواندن این بوده که اول سکتورها یا کلاسترها را بخونی بعد بایت به بایت اطلاعات را بخونی بعدش افتادی تو بحث ... :) )

این حرف شما هم حرف من را تایید می کنه که گفتم با C++‎ بنویسید ! چون فقط توی C++‎ می شه وسط کد Assembly نوشت !

اگه نمی زنی توی PASCAL و زبانهای دیگه ای هم می شد و توی زبانهای ویژوال مثل Delphi هم می شه به شرطی که از INT استفاده نکنی.

طراحی کامپایلر با توجه به هدف زبان انتخاب می شه مثلا زبان C به طور همه منظوره طراحی شده می شه گفت ترکیبی از اهداف COBOL و FORTRAN و .. بوده وقتی یک چیزی به طور کل خوب باش معلوم نیست که برای همه چیز خوب باشه چون زبان C زبانی کاملا تخصصی نیست و اینجاست که کامپایلر با توجه هدف بهینه می شه البته در کل با توجه به عمومیت زبان C کامپایلرها ی بهینه تری با توجه به هدفش وجود داره(منظور در نوع خودش). منظورم اینه ممکن C به طور کل نمره بالایی را بگیره ولی تو زمینه ای که من می خوام کار کنم نمره C از زبانهای دیگه کمتر باشه.

ببین به خدا من خودم از زبان C و ++C خوشم می میاد.
موفق باشید

[soorena]

عزيزم 12 سال از عمرتو هدر دادی رو چيزی که ممکن نيس...جلوی ضرر رو از هر جا بگيری منفعته ... پس جون من بيخيال اين الگوريتم خفنت شو...آقا اصلاً چرا اين کارو بکنی... يه کاری کن.بيا يه دکدر بنويس و فايل enwiki8 رو توش بزار که با يک کليک دکد بشه و فايل رو اکسترکت کنه.يعنی يه فايل که وقتی روش دوبل کليک ميشه enwiki8 رو باز سازی کنه....فايل رو بزار رو اينترنت تا ما امتحانش کنيم...البته بعد اينکه ثبتش کردی...
دوست دارم
عزيزم بر اساس
http://www.mattmahoney.net/dc/dce.html#Section_11
و بر اساس
http://www.faqs.org/faqs/compression...section-8.html
اين کاری که شما کردی يا بهتر بگم دوس داری بکنی غير ممکنه راستی همين لينک دوم رو اگه بخونی يه سری سابقه از افرادی مثله خودت نوشته که قبلاً اين کارا رو کردن و حتی ثبت هم کردن ولی پا خوردن....
ببين در هر صورت چند تا راه اثبات برای رد کردن ادعای شما وجود داره و از اونجا که شما رابطه خوبی با رياضی نداری من ساده ترينشو ميگم...
تا حالا چيزی به اسم اصل لانه کفتری به گوشت خورده؟؟؟؟
اين اصل ميگه 100 تا کفتر تو 99 تا لونه حتماً 2 تاشون تو يه لونه اند...قبول داری؟؟؟؟
پس اگه برنامه تو قادر باشه هر فايل اي رو تو 100 byte ذخيره کنه پس حد اکثر 2 به توان 100 فايل رو ميتونه فشرده کنه و اگه بشه 2 به توان 101 اونوقت حتماً(طبق لانه کفتری) 2 تا فايل مثل هم فشرده شدن و اين يعنی اينکه ديگه به طور منحصر به فرد قابل برگشت نيستن عزيزم....
اين فقط يه راه اثبات هستش....اين قضيه فشردسازی بازگشتی اينقدر ديگه تابلو شده که من که اينقدر اسکلم 3 تا اثبات رياضی برای نقضش بلدم....ديگه چه برسه به شما دوستان که همه دانشمندين....
من يه نظر ديگه هم بدم ديگه از تايپ کردن خسته شدم....آقا در مورد اون بحث برنامه نويسی که دوستان ميکردن حرف behrooz_cs رو کاملاً قبول دارم و اين اصلاً يه چيز سليقی ای نيست که روش بحث بشه کاملاً مشخصه که هم به زبان ربط داره هم به کامپايلر و c يا ++c هم از همه بهتره(البته برای اين کار !!!)....حوصله اثبات کردن ندارم ولی اثباتشو تو ويکی هم ميتونيد پيدا کنيد(يعنی ميخوام بگم اينقد قضيه تابلويه که تو ويکی هم هست...)
نوکريم....تو فکرتونم...

[Behrooz_CS]

آقا من هر چر سرمو می خارونم نمی تونم قبول کنم که این چیزی که دوستمون ادعا می کنه رو قبول کنم ! آقا حتما هممون رو گذاشته سر کار ببین جوون اینقدر الکی وقت ما و خودتو نگیر
یا اعتراف کن که سر کارمون گذاشتی یا ثابت کن که حرف حساب می زنی ! شما تا حالا فقط حرف ( مجانی ) زدی ! بیا 4 تا حرف منطقی بزن یا اون کاری که بهت گفتم (( از دسکتاپت فیلم بگیر بدون کلک )) انجام بده.

من هم 8 سال تو فکر یه همچین چیزی بودم ! آخرش وقتی ازش نا امید شدم که یه الگوریتم واقعی که فایل را فشرده می کرد از خودم ابداع کردم که کار هم می کرد اما اصلا چشمگیر نبود ! بعدش واقعا با تمام وجودم احساس کردم که این کار غیر ممکن هست !!

ببن اگر تو ثابت کنی که کارت درسته من حاضرم N میلیون بهت سفته بدم و رایگان الگوریتمتو با C++‎ بنویسم جوری که سرعتش هم حداقل 20 برابر این چیزی باشه که خودت با VB6 نوشتی !

قربانت
دوستار شما بهروز

[afceaglee2013]

یه کار خیلی راحت تر برای اثبات این مسئله
حتما اسم teamviewer رو شنیدید. این برنامه یه محیط امن برای دیدن صفحه ی دسکتاپ دیگران رو فراهم میکنه
دوستمون میتونن این برنامه رو نصب کنن و به یکی از ما اجازه ی کار با برنامه ی exe ای که ایجاد کردند رو بدن تا ما یک فایل رو به دلخواه انتخاب کنیم و با برنامه شون فشرده کنیم و از حالت فشرده هم خارج کنیم تا ببینیم کار میکنه یا نه حتی فکر کنم بشه چند نفر به دسکتاپ یک سیستم رو ببینن ..
از این روش ایشون هم میتونن برای بازاریابی برنامه شون استفاده کنن ..

[ژوپیتر]

متاسفم که بعضی ها بی پایه و اساس ادعایی می کنند و وقتی چند نفر(به هر دلیلی) اون رو جدی میگیرن، طرف تو جواب دادن و اثبات ادعاش کاری انجام نمیده، این به این معنی که ادعای شما بی پایه و اساسه و تا زمانی که نتونید دیگران رو متقاعد بکنید، اون بقول خودتون اختراع همیشه ور دل خودتون میمونه. من در سال 1381 در دانشگاه روشی رو برای فشرده سازی صدا بر حسب الگوریتم ADPCM پیاده سازی کردم که برای هر Sample صدای 16 بیتی تنها یک بیت خروجی میداد و در ریت 44100 در حالت کاملا استریو کار میکرد، من به عنوان پایان نامه دانشگاه این موضوع رو انتخاب کردم و از ادعایی که کرده بودم دفاع کردم، در سال 1383 متوجه شدم که شرکت motorola از الگوریتمی به نام CVSD استفاده میکنه که خیلی از مشخصاتش با روش من مشابه بود ولی در حقیقت من چرخ رو از اول اختراع کرده بودم و اون الگوریتم از روش من خیلی قدیمی تر بود و در حال حاضر هم در سیستم های مخابراتی استفاده میشه. این باعث نشد که کار من بی ارزش بشه، چون من الگوریتم خودم رو طوری پیاده سازی کرده بودم که به راحتی قابل تبدیل به ASIC و پیاده سازی رو FPGA بود و خودم اون رو روی FPGA هم پیاده سازی کردم.
منظورم از طرح این مطلب اینه که همیشه سعی کنید چیزی رو بنویسید که بتونید زیرش رو امضا کنید.
دوستان خودتون رو متقاعد کنید که شما الگوریتمتون درست با مشخصاتی که ادعا کردید کار میکنه.

[soorena]

سلام
دوستان حتماً با آقای marcus hutter و جايزه معروف ايشان آشنا هستن....
برای کسايی که آشنا نيستن ميگم اين آقا يکی از دانشمندن علم هوش مصنوعی هستش.
که متعقده که فشرده سازی يه مسئله AI هستش...(حالا توضيحش مفصله...)
بهر حال ايشون يه جايزه مشخص کرده که 000 50 يورو پول نقد هستش برای کسی که بتونه حالا با يه سری
شرايط که تو سايتش کامل نوشته شده فايل enwiki8 رو که 100 مگا byte هستش به کمتر از 15 MB که رکورد
فعلی هستش برسونه....شما نميخواد از دسکتاپ فيلم بگيری يا هيچ نرم افزاری نصب کنی...تو اين challenge شرکت کن
هم اين50000 يورو رو ببر حالشو ببر هم به ما ثابت کردی....چطوره؟؟؟
اينم لينکش
prize.hutter1.net
دوستون دارم

[MahbobeSdaghat]

سلام
ماشالله چه بحث جالبی بود
من چنند صفحه پیش هم یه پست دادم( مربوط به تقریبا نه ما پیش میشه)که اونجا گفتم اینجا مهد نا امیدیه
نه اینکه با سایت یا دوستاان توهینی کرده باشم نه خوب یکی میاد تو کتش نمیره که این میشه یا اون نمیشه یه سری دلایل میاره که خوب واقعا هم درسته ولی میشه از یه راه دیگه هم گفت که نا درسته
از پستهای صفحات قبل میگذرم و اینجا هم فقط یه پستی هست که دوس دارم یه توضیح بدم
از بالا پست دوم قسمتی که گفته اصل لانه به قول خودش کفتری
اثبات کرده کاملا هم صحیح بهتر از این هم نمیشد به اون یکی دوستمون بگی که " این ره که میروی به ترکستان است"
ولی همین قضیه در رابطه با برنامه های دیگه هم صدق میکنه
همین اصل لانه کبوتر یا به قول دوستمون کفتری در مورد مثلا وین رار
هم صدق میکنه یه کران بالا بگیریم مثلا فایل های با حجم n به پایین رو می خوایم فشرده کنیم
حالا ما چند فایل میتونیم داشته باشیم ؟
دو به توان n +1 فایل داریم حالا این خانم وین رار این فایل ها رو فشرده میکنه ماکزیمم فایلمون حجمش میاد m که کمتر از فایل اصلی هست ( حجم ها رو به بیت در نظر بگیرین تا اشتباه نشه)
حالا وینرار چند تا فایل رو میتونه بسازه ؟ دو به توان m+1 درسته؟
تعداد فایل اصلی چقدره؟دو به توان n+1 و میدونیم چون n>m
(دو به توان n+1) > (دو به توان m+1)
و اینجا هم بنا به اصل لانه کبوتر همه فایل ها رو وین رار نمیتونه فشرده کنه
پس چه نتیجه می گیریم؟ نتیجه اینکه وین رار فایل هایی هم هست که به اندازه n یا بیشتر تبدیل میکنه
یعنی n<=m
درست ؟
اما با این حال که خانم وین رار فایلهایی حتی بزرگتر از فایل های اصلی تولید می کنه اما خیلی کاربرد داره
خیلی استفاده میشه وخیلی هم طرفدار داره


حالا با توجه با این اثبات و وضعیت وین رار و محبوبیتش
نمیشه گفت این برنامه ای که دوستمون نوشتن ( البته اگه به قولا خالی نبسته باشه که امید وارم همینطور باشه )
به درد نمی خوره که البته خیلی هم به درد می خوره
یه چیزی هم یه این دوست برنامه نویسی که واقعا جا داره همینجا من بهش تبریک بگم هم موفقیتش رو وهم پشتکارش رو و انشا لله که بی ثمر هم نمی مونه
و اون چیزی که می خوام بگم اینه
شما تو حرفا تون گفتید که الگوریتم نوشته شده به صورت متوالی داره تکرار میشه و هر جایی دوس داشته باشی میشه اون رو متوقف کرد
من کد شما رو ندیدم ولی با توجه با اثبات لانه کبوتری که بالا دوستمون ( ببخشید من اسم نمیبرم ..... شرمندتون هم هستم ولی واقعا نمیشناسم)
اثبات کردن شما محدود به یه اندازه ثابت هستید این محدودیت رو بردارید مثلا شما میتونید الگوریتم رو یه جا متوقف کنید و هرچه بشتر فشرده کنید
تعداد تکرار حلقه هم بالا میره . شما تو حلقه یه اندیس بزار و اون رو به کدی که اخر سر میدی بیرون اضافه کن و البته از این عدد یه جوری استفاده کن
هم انجوری خروجی از حالت حجم ثابت بیرون میاد و هم اینکه احتمالا سرعتت میره بالا

من زیاد حرف زدم نمیدونم چیزی فهمیدید یا نه
امیدوارم مفید واقع بشه

هدف اصلیم از این پست فقط این بود که از اون دوستمون که 12 سال تلاش کرده تا این برنامه رو بسازه حمایت کنم و بگم که این بنده خدا این هم تلاش کرده 12 سال زحمت
کشیده و شاید واقعا هم برنامش کاملا درسته . این هم زحمت کشیده و پله ها رو یکی یکی اومده بالا حالا تو پله های آخر با این حرفاتون نا امیدش نکنید
من اگه جای ایشون باشم نا امید بشم افسردگی ابدی می گیرم
12 سال عمر که میشه کلی تفریح و سرگرمیو .... رو گذاشته کنار نشسته فکرش رو گذاشته رو این کار حالا نا امید بشه ( نا امیدش کنن)
شما باشید در جا سکتتو نمیزنه؟
بگو بسم الله برو جلو مطمئن باش خدا هواتو داره
خدا بنده هاش رو رها نمیکنه
بهترین ها رو برای تک تکتون از خالق هستی آرزو مندم
در پناه حق
خدا نگهدار

[soorena]

سلام
اول از همه اينکه من اسمم سورنا هستش همون طور که از ايدی هم مشخص هستش.
دوم اينکه چون از نرم افزار فينگيليش به فارسی استفاده ميکنم شرمنده اگه نوشته هام غلط املا يی داره.
خوب حالا ميرسيم به بحث اصليمون:
اول اينکه آقای behrooz_CS شما هر کی هرچی بنويسه کلاً تشکر ميکنی ديگه ها؟ بدون اينکه اصلاً بخونی پستشو؟
خيلی باحالی بابا تو!!!!!!
اگه يه بار نوشته اين خانوم mahbobesdaghat رو ميخوندی الکی تشکر نميزدی!!!!!
دوم اينکه خانوم mahbobesdaghat اين استدلالی که دادين کاملا مزخرفه(البته بی احترامی نشه) حالا بگو چرا؟؟؟

هم صدق میکنه یه کران بالا بگیریم مثلا فایل های با حجم n به پایین رو می خوایم فشرده کنیم
حالا ما چند فایل میتونیم داشته باشیم ؟
دو به توان n +1 فایل داریم حالا این خانم وین رار این فایل ها رو فشرده میکنه ماکزیمم فایلمون حجمش میاد m که کمتر از فایل اصلی هست ( حجم ها رو به بیت در نظر بگیرین تا اشتباه نشه)
حالا وینرار چند تا فایل رو میتونه بسازه ؟ دو به توان m+1 درسته؟
تعداد فایل اصلی چقدره؟دو به توان n+1 و میدونیم چون n>m
(دو به توان n+1) > (دو به توان m+1)
و اینجا هم بنا به اصل لانه کبوتر همه فایل ها رو وین رار نمیتونه فشرده کنه
پس چه نتیجه می گیریم؟ نتیجه اینکه وین رار فایل هایی هم هست که به اندازه n یا بیشتر تبدیل میکنه
یعنی n<=m
درست ؟

خوب عزيزم شما فايل هايی با حجم n به پايين رو ميخوای فشرده کنی حالا چند تا فايل با حد اکثر اين حجم ميتونی داشته باشی؟؟؟؟؟؟؟؟ شما دانشجوي کامپيوتر هستی؟؟؟؟؟
دو به توانه n+1 ؟؟؟؟؟؟؟؟ آره؟؟؟؟؟؟؟؟
ميشه :
256+256 ^2+256^3+....+256^n
اگه يه کم فکر کنين ميفهمين چرا اينجوری ميشه...
پس باز هم به اين نتيجه ميرسيم که کار اون دوستمون با اون اختراعش کاملاً بی پايه و اساس هستش.
ضمناً يه خبری هم بهتون بدم اون دوستمون رفته اون اختراعش رو تو يه سايتی ثبت کرده که حالا بعداً
لينکش رو براتون ميزارم و تا يه مدتی همون صفحه سايت شده بود نقل مجلس forum های خارجی و بهش ميخنديدند.
مشکل ما ها اينه که فکر ميکنيم همه چی برنامه نويسی هستش ولی در اصل اين رياضی هستش که حرف اول رو تو اين علم ميزنه و programming فقط يه ابزار برای پياده سازی هستش و بس.
من واقعاً به دوست عزيزمون پيشنهاد ميکنم قبل از اينکه 12 سال بعدی عمرش رو هدر بده يکم بيشتر در مورد مطلب مورد نظر تحقيق بکنه.
ضمناً دوستانی که علاقمند بودن من يه تاپيک با عنوان فشرده سازی هم تو اين forum هم تو p30world راه انداختم که متأسفانه اصلاً استقبال نشد.
http://forum.p30world.com/forumdisplay.php?f=274
https://barnamenevis.org/showthread.p...A7%D8%B2%DB%8C
ضمناً winrar خانوم نيست آقاست و اصلاً هم جزو نرم افزار های قوی محسوب نميشه.

[Cancer]

سلام سلام سلام.

در جواب اون دوستی که با حجم ثابت فشرده می کرد.

ما یه همشهری داشتیم اتفاقا که می خواست صفر و یک رو نقض کنه الان فرار کرده همین جاست....
خب آخه این چه حرفی که با یه حجمی که از n بیشتر نمیشه فلانی ادعا میکنه که می تونه همه فایلها رو فشرده کنه خب معلوم که از 2 به توان n بشتر نمی تونه فایل فشرده کنه و باقیش رو هم میفته دیگه (چند ورودی یه خروجی دارن) خب وقتی که این طوری بشه چطوری می خوای به حالت اول برش گردونی؟

و ما هم چقدر بیکاریم که داریم برای یه ادعای بی اساس وقتی می ذاریم (می ذاریم فکر کنم اشتباه نوشتم «ببخشید»).

بسه دیگه تموم شد بریم سر خونه زندگیمون.

[mebd12]

سلام دوباره همه دوستان
من این تاپیک را بکلی فراموش کردم از نظرات همه دوستان متشکرم . به هر حال این کار انجام شده و در واقع یک الگوریتم جدید و یک فرمول خاص میباشد که روی بیتها انجام شده و کاری به فایل و برنامه نویسی ندارد.اون تکه برنامه که نوشتم فقط برای تست کار بود. نظر همه دوستان محترم می باشد و یک سوالی از دوستان دارم آیا اختراعاتی که قبلا انجام شده خالق آن میدونسته که این کار حتما انجام می شود یا نه ؟ و آیا برای دیگران قابل درک بوده؟ پس اگر اینجانب مطلبی را بیان کردم حتما کاری انجام شده است و شاید برای شما قابل در ک نباشد. و اما شما دوست عزیز گفتید در تاپیک های خارجی مورد مضحکه قرار گرفته خوب این برای اینجانب مهم نیست چون وقتی من داشته هایم را دارم خیلی خوشحال میشوم . چرا که همه اینها وقتی نتیجه کار وروش را ببیننداز کارشان پشیمان می شوند. چرا فکر میکنید که فقط خارجیها علم شان بیشتر از ما میباشد.اما برای اثبات این موضوع زمانی را مشخص کرده و بصورت آنلایان تست فایل ها را از webcam انجام دهم تا نتیجه را ببینید. اگر من تا الان دست دست میکنم به خاطر بهینه کردن و کارایی الگوریتم و انجام یک پروژه تجاری که بزودی تمام میشود صبر میکنم. و اما چرا در تاپیکهای مختلف کار را مطرح کردم بخاطر اینکه هر چی اینکار بیشتر گسترش یابد و مورد مضحکه دیگران واقع شوم ارزش کار بالا میرود. اما نکته قابل توجه این فشرده سازی اینه که در انتقال داده ها کارایی زیادی دارد آیا میدانی که یک دستگاه PCM در مخابرات با یک روش ریاضی هر 8 بیت را دوبیت در خروجی تحویل میدهد
آیا کسی از این روش خبر دارد یا در انحصار سازنده این روش فشرده سازی می باشد. حالا اگر من بتوانم صدها بیت را طبق زمان معقول فشرده کرده و در خروجی بدهم چه اتفاقی میافتد. متاسفانه اینجا ایرانه اگر در کشور دیگر بودم بعضی از مشکلات را نداشتم. اما نکته قابل توجه برای شما که این ادعا را قبول ندارید آیا نمی شود با روش شبیه سازی حداقل یک حالت از هزاران حالت را کم کنی ؟ یک شکلی در پایین قرار میدهم تا متوجه بشوی به چه صورت میشود . اصل کار باشد بعدا که کارم تمام شد.خود بخود معرفی میگردد و نیازی نیست در این تاپیک روی میشه یا نمیشه بحث کرد. دوست گرامی اون تاپیکی خارجی که گفتید روی آن دارد بحث می شود بگذارید تا جوابشان را بدهم.
...... 00
.........010 110
...01 1110 010 000
11110 0001 010 1111
این بالا را نگاه کنی همه چیز در این مثلث نهفته هستش البته بیتها با فرمول خاصی در هر خط ایجاد میشه که secret میباشد . این مثلث تا هر خطی که به جوابم برسه که حداقل یک بیت کم شود تمام میشود. درضمن هر خط که رو به پایین میرویم بیتهای جدیدی که ترکیبی از خط بالایی و بیتهای داده های اصلی که بتواند در فرمول من صدق کند قرار می گیرد .و دوباره این عمل تکرار میگردد. در آخر هم دوست عزیز بلاخره متوجه شدم سرعت در این روش اصلا مهم نیست چرا که با روش شبیه سازی دسته ای می شود برای فشرده کردن داده های فایل استفاده کرد .با تشکر

[soorena]

اما شما دوست عزیز گفتید در تاپیک های خارجی مورد مضحکه قرار گرفته خوب این برای اینجانب مهم نیست چون وقتی من داشته هایم را دارم خیلی خوشحال میشوم

عزيزم چيزی که غير ممکن هستش و با اثبات رياضی به غير ممکن بودنش ميرسيم ديگه اصلاً جای بحث کردن نداره.

آیا میدانی که یک دستگاه PCM در مخابرات با یک روش ریاضی هر 8 بیت را دوبیت در خروجی تحویل میدهد

شما چرا فکر ميکنی اين قضيه عجيبه؟؟؟؟ مگه ما از پشت کوه آمديمکه ندونيم؟؟؟ بله الگوريتم هم هستش که هر 8 بيت رو ميکنه 1 بيت و اصلاً هم چيز عجيبی نيست!!!!
تاحالا قضيه اساسی شانون در فشرده سازی به گوشت خورده؟؟؟؟ هر مدلی برای فشرده شدن يه حد پايينی داره که فقط برای اون مدل بدرد ميخوره.....(توضيحات بيشتر تو اينترنت)
ولی يادت باشه برای يک مدل خاص کارايی داره!!!!
در صورتی که طبق گفته شما برنامتون برای همه فايل ها کار ميکنه که اين اصل شانون رو زيره سؤال ميباره!!!

آیا کسی از این روش خبر دارد یا در انحصار سازنده این روش فشرده سازی می باشد.

شما يه روش جديد رو ميتونی patent بکنی ولی اينکه فکر کنی کسی از الگوريتم اش خبر دار نميشه سخت در اشتباهی!!! اولين برنامه اي که بدی تو بازار خيلی سريع الگوريتم کار رو ميشه....(reverse engineering)

[mebd12]

بله دوست عزیز همه اینها را که گفتی را میدانم نگفتم که الگوریتم را ثبت نمیکنم ویا کسی از ان خبردار نمیشه . چون اینها را میدانم در حال حاضر از چند کمپانی پیشنهادی دارم و خودم هم کاری دارم انجام میدهم . وقتی به نتیجه رسید کار ثبت نهایی میگردد. اما در مورد قضیه شانون بله هر جا که رفتم کارم را نشان بدهم راجع به این قضیه خیلی صحبت شده و درست هم می باشد. ولی تست برنامه را دیدند تعجب کردند. هر چند سرعت خیلی پایین می باشد. اما یک مثال ساده میزنم ببین الگوریتم هایی که موجود میباشد بیشتر انها یکسری کدهایی باید ذخیره کرد تا بتوانی عملیات فشرده سازی را انجام بدهی این خود باعث می شود که نتونی تا بی نهایت داده هارا جلو ببری اما اگر روشی باشد که بطور اتوماتیک تشخیص بدهد که چه داده ای در کجا تکرار شده و یا مکانی را تشخیص بدهی و بتوانی حداقل یک حالت را کم کنی مسلما داده ها تا بی نهایت جلو میرود. بنظر شما با این کار نظریه شانون نقض شده ؟ اگر شده خوب چه بهتر اگر نشده باز هم فرقی نمیکنه در نهایت امیدوارم استفاده خوبی از این روش در آینده گردد. اما در مورد سرقت کد برنامه یا الگوریتم با این روش در آینده میشود اگر مشکل سرعت حل شود بحث امنیتی در مورد نرم افزارهارا گسترش داداین کار امکان دارد و کاری که هم الان دارم انجام میدهم راجع به همین مورد می باشد. راجع به بالا رفتن سرعت هم مطمئنم به سرعت معقولی خواهد رسید البته نه فقط با این روش بلکه ترکیبی از روشهای مختلف و شبیه سازی آن.

[powerboy2988]

کلی استفاده کردم از این تاپیک.. به هر حال خیلی مشتاقم که ببینم آخر داستان به کجا ختم میشه...

اما دلیل اینکه میگید من n سال کار کردم و ... چیه واقعا؟؟؟ چه استفاده ای داره؟؟

ممنون...

[hamidhws]

با سلام

مدتی نبودم و گویا هنوز بحث اینجا ادامه داره !

دوستان بحث هایی رو ارائه میدن که بیشتر از روی نداشتن اطلاعات است . مثلا دوستی گفته بود برای تست الگوریتم روی همه قایل ها تست کن ! آخه عزیز من وقتی الگوریتم روی بیت ها کار میکنه هیچ فرقی نمیکنه نوع فایل چی باشه یا حجمش چقدر باشه . برای تست فقط کافیه روی تمام حالات اون مقدار بیت (مثلا اگر قرار بود 4 بیت رو به 3 بیت تبدیل کنه باید بتونه هر حالتی از 16 حالت رو به 3 بیت تبدیل کنه) حالا پایین بیشتر توضیح میدم.

جناب mebd12 نزدیک به 2 سال از ادعای شما میگذرد و هم اکنون حتی آن را ثبت نکرده اید !
دوست عزیز برای ثبت این موضوع اصلا احتیاجی به ساخت برنامه فشرده ساز نیست . شما فقط کافیه الگوریتم خودتون رو ارائه بدید . فقط قبلش به مسائل زیر دقت کنید.

بنده روند فشرده سازی رو به 2 قسمت تقسیم میکنم و در مورد هر کدوم توضیح میدم.

1- فشرده سازی 100%

با یک مثال ساده تشریح میکنم .
فرض کنید برنامه شما قادره مثلا هر 16 بیت رو در 15 بیت ذخیره کنه . تا اینجا درست؟

16 بیت = 65536 حالت .

0000000000000000
0000000000000001
0000000000000010
0000000000000011
.
.
.


خوب!
حالا اگر ادعا میکنید که الگوریتم شما به طور 100% همه فایل ها را فشرده میکند , باید به طور کامل روی 65536 حالت تست کنید . (حتی اگر روی 65535 حالت فشرده سازی انجام شد و تنها و فقط تنها روی 1 حالت فشرده سازی انجام نشد این ادعای شما رد میشود)

نکته :
البته این ادعا از لحاظ منطقی و ریاضی کاملا غیر منطقیست!
به مثال زیر توجه کنید (فرض کنید الگوریتم ما قرار است 2 بیت (4 حالت ) را در کمتر از 4 حالت (3 حالت =حداقل فشرده سازی) ذخیره کند )

1=00
2=01
3=10
4=11

به طور منطقی از 4 حالت کمتر نمیشه جز اینکه حالتی 2 بار تکرار بشه

1=00
2=01
3=10
3=11

که همینطور که در این حالت میبینید در این صورت تناقص بوجود میاد

در انتها : به طور ساده تمامی الگوریتم هایی که ادعای فشرده سازی 100% رو دارند باید بتونن n حالت رو در حداقل n-1 حالت ذخیره کنن (که با اثبات بالا این کار غیر ممکن است)

منم خودم خیلی تلاش کردم که بتونم به 100% برسم اما منطق به شکل زیبایی اجازه اینکارو نمیده !

به هر حال ممکنه الگوریتم شما روی خیلی از فایل ها عملیات فشرده سازی رو انجام بده (همانطور که الگوریتم من اینکارو میکرد) اما تا زمانی که روی تک تک حالات بیت ها تست نکنید نمیتونید اونو جزئی از این روش بدونید

(( در صورت انجام فشرده سازی با این روش حجم فایل تا مرز صفر و به صورت تساعدی کم میشه و منطق فعلی در همه زمینه های منطقی و ریاضی زیر سوال میره ))
__________________________________________________ __________________________________________________ ___________________________________________

2-فشرده سازی کمتر از 100%

بر خلاف نمونه اول این نمونه کاملا منطقیست .

در این روش شما نمیتونید ادعا کنید تمام فایل ها با هر حالت بیت رو میتونید فشرده کنید . اما موفقترین روش طبیعتا روشی است که افزاینده نباشه .

به 2 روش زیر دقت کنید

1- الگوریتمی که احتمال عدم فشرده سازی 1 بایت در اون 1 به 256 هست (بالاتر از 99% , قادر هست 255 حالت رو فشرده کنه و تنها اگر 1 حالت خاص بود فشرده سازی انجام نمیشه) و مقدار افزاینده در اون صفر است(در صورتی که فشرده سازی انجام نشه افزایشی هم در کار نخواهد بود)

2- الگوریتمی که احتمال عدم فشرده سازی 1 بایت در اون 1 به 256 هست و مقدار افزاینده در اون 2 است.


همانطور که مشاهده میکنید در بدترین شرایط که احتمال اون 1 به 256 هست در الگوریتم اول نه فشرده سازی صورت میگیره و نه افزایش . اما در الگوریتم دوم در همین شرایط باعث افزایش بیت ها خواهد شد.

پس همانطور که میبینید الگوریتم اول بهینه تر و بهتر است .

((یک الگوریتم بهینه در این روش هم ممکنه بتونه ججم یک فایل رو به صورت تساعدی تا مرز صفر پایین بیاره اما هیچ تضمینی وجود نداره که روی همه حالات این نتیجه رو بده . هر اندازه الگوریتم شما درصد بالاتری از حالات رو پوشش بده و مقدار افزاینده اون کمتر باشه احتمال اینکه در بیشتر فایل ها و حالات عملیات فشرده سازی انجام بشه بیشتر هست.

((در حال حاضر هم روی الگوریتمی در همین دسته کار میکنم و امیدوارم بتونه جای الگوریتم هافمن که بر پایه تکرار استوار بود رو بگیره ))
.................................................. ...........
یک راهنمایی برای دوستانی که میخوان الگوریتمشون رو تست کنن ببینن روی همه فایل ها جواب میده یا نه -> همیشه سعی کنید الگوریتمتون رو در بدترین شرایط و حالت تست کنید . برای مثال اگر الگوریتم شما تکرار محور هست , روی یک فایل با کمترین مقدار تکرار تست کنید


امیدوارم مطالب به درد دوستان بخوره
موفق باشید

[soorena]

مثلا دوستی گفته بود برای تست الگوریتم روی همه قایل ها تست کن ! آخه عزیز من وقتی الگوریتم روی بیت ها کار میکنه هیچ فرقی نمیکنه نوع فایل چی باشه یا حجمش چقدر باشه . برای تست فقط کافیه روی تمام حالات اون مقدار بیت (مثلا اگر قرار بود 4 بیت رو به 3 بیت تبدیل کنه باید بتونه هر حالتی از 16 حالت رو به 3 بیت تبدیل کنه) حالا پایین بیشتر توضیح میدم.

عزیزم الگوریتم‌های فشرده سازی تشکیل شده از یک مدل + یک کدر . کدر که حالت عمومی داره و معمولان از arithmetic coder استفاده می‌شه. (گاهی اوقات هم هنوز از هافمن یا شانون‌فانو استفاده می‌شه.). مهم‌ترین قسمت همون مدل یا predictor هستش که بر روی داده‌های مختلف به صورت‌های مختلف عمل می‌کنه و معمولا به صورت عمومی نیست برای همین هستش که هیچ چیزی به اسم الگوریتم فشرده سازی یونیورسال(universal) وجود نداره.

در حال حاضر هم روی الگوریتمی در همین دسته کار میکنم و امیدوارم بتونه جای الگوریتم هافمن که بر پایه تکرار استوار بود رو بگیره

هافمن برای دهه ۶۰ بود و خیلی‌ وقت که دیگه مرده و به طور عمده به جای اون از arithmetic استفاده می‌شه که به حد اساسی‌ شانون در تئوری اطلاعات بسیار نزدیک هستش.من قبلا یک مقاله تو ieee دادم که الگوریتم هافمن رو ارتقا میده ولی‌ حتی با ارتقا هم نمی‌شه به arithmetic رسید مگر از مرتبه‌های بالاتر مثلا مرتبه ۲ یا ۳ یا حتی بالاتر استفاده کنی‌ که در اون صورت هم پیچیدگی‌ محاسباتی زیاد می‌شه و هم از لحاظ مموری مقرون به صرفه نیست پس بهت پیشنهاد می‌کنم که وقتت رو روی هافمن نگذاری..

یک راهنمایی برای دوستانی که میخوان الگوریتمشون رو تست کنن ببینن روی همه فایل ها جواب میده یا نه -> همیشه سعی کنید الگوریتمتون رو در بدترین شرایط و حالت تست کنید . برای مثال اگر الگوریتم شما تکرار محور هست , روی یک فایل با کمترین مقدار تکرار تست کنید

یک راهنمایی‌ هم از من بشنو دوست عزیز : هیچ وقت الگوریتمت رو رو بد‌ترین حالت تست نکن. باتوجه به اینکه هیچ فشرده سازی به صورت یونیورسال وجود نداره پس همیشه یک نوع دیتا پیدا می‌شه که الگوریتم شما روش کار نکنه از این بابت مطمئن باشید . شما هر نرم‌افزار فشرده سازی رو که دوست داری اینجا اسمش رو بذار من یه فایل برات آپلود می‌کنم که اگه با اون فشرده بشه حتی حجمش بیشتر هم می‌شه و علت هم بر میگرد به همون مدل سازی که بالا برات توضیح دادم.پس سعی‌ کنید برای شروع با دیتا‌های خاص شروع کنید و کارتون رو محدود کنید تا کم‌کم به یه الگوریتم خوب برسید.

قضیه این برنامه دوستمون هم که اگه پست‌های قبلی‌ من رو بخونی‌ متوجه میشی‌ که کاملا چرند محض هستش و فقط داره وقت تلف می‌کنه.

[hamidhws]

بهت پیشنهاد می‌کنم که وقتت رو روی هافمن نگذاری..

شاید هافمن ارتقا داده شده باشه اما کماکان همگی الگوریتم ها از پدرشون (هافمن) تبعیت میکنن (دلیلشم خیلی سادس. همگی روی تکرار استوارن!یا چیزی شبیه اون >> به همین دلیل هم هست که اگوریتم های فشرده سازی با فایل های تصویری مشکل دارن)
به اینها میشه گفت ارتقا نه نوآوری

روشی هم که بنده مدت ها روش کار میکنم هیچ ربطی به الگوریتم های فعلی منجمله هافمن نداره. به همین دلیل عرض کردم میتونه جاشو بگیره . و همچنین میتونه چندین بار متوالی فشرده بشه >> چیزی که الگوریتم های فعلی فاقد اون هستن.
دلیل این وقفه طولانی هم این بود که میخواستم به فشرده سازی 100% برسم . اگر چه به این به اصطلاح غیر ممکن نرسیدم اما الگوریتم های زیادی ساختمو تست کردم که بهترینشو ارتفا میدم .

عزیزم الگوریتم‌های فشرده سازی تشکیل شده از یک مدل + یک کدر . کدر که حالت عمومی داره و معمولان از arithmetic coder استفاده می‌شه. (گاهی اوقات هم هنوز از هافمن یا شانون‌فانو استفاده می‌شه.). مهم‌ترین قسمت همون مدل یا predictor هستش که بر روی داده‌های مختلف به صورت‌های مختلف عمل می‌کنه و معمولا به صورت عمومی نیست برای همین هستش که هیچ چیزی به اسم الگوریتم فشرده سازی یونیورسال(universal) وجود نداره.

دوست عزیز شما متوجه عرض بنده نشدید گویا !
دوستمون ادعا کردن عمل فشرده سازی مستقیم روی بیت ها انجام میشه و شامل همگی حالات ! در این صورت ربطی نداره که فایلمون چی هست یا چه نوعیه

هر نرم‌افزار فشرده سازی رو که دوست داری اینجا اسمش رو بذار من یه فایل برات آپلود می‌کنم که اگه با اون فشرده بشه حتی حجمش بیشتر هم می‌شه

البته این دقیقا به الگوریتم نرم افزار بر میگرده

یک راهنمایی‌ هم از من بشنو دوست عزیز : هیچ وقت الگوریتمت رو رو بد‌ترین حالت تست نکن.

در هر صورت الگوریتمی که تولید میکنیم یکی از 3 حالت زیر هست :

1- 100% کاهنده
2- تا 99% کاهنده -بدون احتمال افزایش
3-تا 99% کاهنده - احتمال افزایش

همینطور که میدونید حالت سوم بدترین حالت و حالت اول بهترین . اگر شما یک فایل رو توی بهترین حالت تست کنید همگی به یک اندازه فشرده میشن. اما اگر در بدترین شرایط تست کنید ...

تست روی بدترین حالت کمترین فایدش اینه که میفهمیم الگوریتممون از دسته سوم هست یا نه .
و با توجه به این که حالت اول فعلا غیر ممکنه پس فقط حالت دوم میمونه که شرط برتری برای این حالت اینه که درصد بیشتری از حالت ها رو پوشش بده تا در نتیجه احتمال فشرده سازی یک فایل تا نزدیک 100% برسه

[soorena]

1- 100% کاهنده
2- تا 99% کاهنده -بدون احتمال افزایش
3-تا 99% کاهنده - احتمال افزایش

من نمیدونم این تقسیم بندی جالب رو کی‌ به شما گفته یا از کجا آوردی ولی‌ پیشنهاد می‌کنم کتاب‌های the data compression book by mark nelsonو introduction to data compression by khalid sayood رو حتما تو این زمینه اگه علاقه داری بخون.

دلیلشم خیلی سادس. همگی روی تکرار استوارن!یا چیزی شبیه اون >> به همین دلیل هم هست که اگوریتم های فشرده سازی با فایل های تصویری مشکل دارن)

اینکه چرا فایل‌های تصویری و عکس‌های jpeg مخصوصاjpeg2000 فشرده نمیشن به این علت هستش که اونا خودشون الگوریتم فشرده سازی مخصوص خودشون رو دارن که حوصله ندارم برات توضیح بدم ولی‌ لینکش رو می‌گذارم اگه حال کردی بخون.
http://en.wikipedia.org/wiki/JPEG
http://en.wikipedia.org/wiki/JPEG_2000
http://www.wotsit.org/

دوستمون ادعا کردن عمل فشرده سازی مستقیم روی بیت ها انجام میشه و شامل همگی حالات ! در این صورت ربطی نداره که فایلمون چی هست یا چه نوعیه

اینکه فشرده سازی روی بیت‌ها انجام می‌شه بهش اصطلاحا میگنbitwise encoding که خوب اصلا جدید هم نیست و چندین سال هستش که استفاده می‌شه ولی‌ باز هم به مدل بستگی داره.(کتاب khalid sayood رو حتما بخون. )

[hamidhws]

ن نمیدونم این تقسیم بندی جالب رو کی‌ به شما گفته

شما یه فشرده سازی مثال بزن که خارج از این 3 تا دسته باشه ! (بدون اتلاف)

اینکه چرا فایل‌های تصویری و عکس‌های jpeg مخصوصاjpeg2000 فشرده نمیشن به این علت هستش که اونا خودشون الگوریتم فشرده سازی مخصوص خودشون رو دارن

فکر کنم شما همه وقتتو صرف حفظ کردن کتاب میکنی! نخیر همه دلیلش این نیست >> دلیل اصلیش اینه که فایل تصویری و همچنین ویدئویی تراکم بیت هاشون زیاده. اینکه چرا زیاده میتونید طبق علاقتون مطالعه کنید!

اینکه فشرده سازی روی بیت‌ها انجام می‌شه بهش اصطلاحا میگنbitwise encoding که خوب اصلا جدید هم نیست و چندین سال هستش که استفاده می‌شه ولی‌ باز هم به مدل بستگی داره.(کتاب khalid sayood رو حتما بخون. )

به نظرم شما یه کتابفروشی باز کن :D
آخه عزیز . من چیکار اصطلاح یا جدید بودنش دارم؟ وقتی شما مستقیم با بیت ها کار کنید = تمام حالات , و همچنین بتونید بطور 100% (به اون 3 دسته رجوع شود) حتی 1 حالت از تعداد حالات n بیت کم کنی . در نتیجه فایل تا n بیت فشرده میشه و هیچ ربطی هم به اینکه چه فایلی هست یا صوتی یا تصویری یا فضایی یا ... نداریم هرچی باشه فشرده میشه که یعنی شانون و منطق همچی زیر سوال میره. حالا متوجه شدی یا بازم توضیح بدم دوست عزیز(این توضیح ها توی کتاب نیست وگرنه بهت معرفی میکردم :)

----------------------------------------------------------------------
دوست عزیز بهت پیشنهاد میکنم بجای اینکه توی جواب بقیه سریع بری توی اینترنت سرچ کنی 4 تا کلمه انگلیسی رو کپی پیست کنی یکم از خودت مایه بذارم گلم. همینکارارو میکنیم که هنوز جهان سومیم دیگه!(ناراحت نشیا کلی گفتم)

[soorena]

سلام

هرچی باشه فشرده میشه که یعنی شانون و منطق همچی زیر سوال میره.

شما درست میگی‌ بگرد دنبال معجزه که همه چی‌ رو زیر سوال ببری.
از این حرفا گذشته من حقیقتا خوشحال میشم اگه بتونی‌ دستاورد‌هایی‌ رو که تاحالا تو این زمینه داشتی‌ به اشتراک بگذاری ایشالا که بتونیم استفاده کنیم. می‌شه لطفا الگوریتم‌هایی‌ رو که تاحالا طبق اصولت پیاده سازی کردی معرفی‌ کنید؟

اگرم دوس داشته باشی‌ میتونیم یه benchmark اینجا در زمینه فشرده سازی بدون تلفات بذاریم و با یه سری فایل مرجع (corpus) الگوریتم‌ها مون رو امتحان کنیم. اگه نظرات مساعده ، یه تاپیک جدید برای این کار راه بندازیم.
---------------------------------------------------------------------------------------
متأسفانه بر خلاف تصور بسیاری از دوستان تو این علم معجزه جایی‌ نداره بلکه به شدت درگیر ریاضیات و احتمال هستش و اینکه مثلا بعضی‌ از دوستان تو ذهنشونه که "یه برنامه بنویسیم که یه فایل ۱۰۰ مگابایت رو بکنیم ۵ بایت" چنین چیزی ممکن نیست و با ریاضی‌ هم قابل اثبات هستش. با خوندن یک کتاب احتمال می‌شه به غیر ممکن بودن این قضیه آگاه شد به هر حال هنر فشرده سازی یه بخشی از هوش مصنوعی هستش که هنوز خیلی‌ جای کار داره....ولی‌ رویا پروروندن به علت نداشتن اطلاعات علمی‌ کافی‌ تو این زمینه هستش. برای همین فکر می‌کنم اگه تو یک * هر ادعا رو با پیاده سازی اون با یک برنامه کامپیوتری نشون بدیم بهتر همدیگه رو درک کنیم.

[hamidhws]

متأسفانه بر خلاف تصور بسیاری از دوستان تو این علم معجزه جایی‌ نداره بلکه به شدت درگیر ریاضیات و احتمال هستش

کاملا موافقم

اینکه مثلا بعضی‌ از دوستان تو ذهنشونه که "یه برنامه بنویسیم که یه فایل ۱۰۰ مگابایت رو بکنیم ۵ بایت" چنین چیزی ممکن نیست

البته همانطور که خودتون هم عرض کردید از انجا که در حال حاضر 100% وجود نداره , اما باز ممکنه بتونیم یک فایل 100 مگابایتی رو در 5 بایت (کمی بیشترو کمتر) ذخیره کنیم ! اما چیزی که اینجا مهمه اینه که نمیتونیم ادعا کنیم روی هم فایل ها و همه حالات جواب میده و فقط ممکنه در تست بهترین شرایط (که معمولا با الگوریتم های فعلی خیلی کم پیش میاد) به این مقدار فشرده سازی رسید.

می‌شه لطفا الگوریتم‌هایی‌ رو که تاحالا طبق اصولت پیاده سازی کردی معرفی‌ کنید؟

اگرم دوس داشته باشی‌ میتونیم یه benchmark اینجا در زمینه فشرده سازی بدون تلفات بذاریم و با یه سری فایل مرجع (corpus) الگوریتم‌ها مون رو امتحان کنیم. اگه نظرات مساعده ، یه تاپیک جدید برای این کار راه بندازیم.

حتما! اما قبلش فکر کنم بهتر باشه الگوریتمو ثبت کنیم , نظر شماچیه ؟

[soorena]

نمیدونم منظورت از ثبت کردن چی‌ ولی‌ خوب اگه به صورت مقاله بدین هیچ مشکلی‌ پیش نمیاد.

می‌شه برای یه کنفرانس تو ieee فرستد یا جاهای دیگه.

من معمولان چیزایی‌ رو که کار می‌کنم تو صفحهٔ خودم میگذارم اینجا...

http://www.maroofi.persiangig.com

[perysa]

جناب mebd12 من این بحث رو قبل خوندم وشما اینجا فقط ادعا کردید که این کار را انجام دادی و دوستان از شما خواستند که ادعای خود را ثابت کنی مثلا onlin یا هر روش دیگری وشما هنوز کاری انجام ندادی
اگه راست می گی ثابت کن تا ببینیم وگرنه با این حرفا وقت بقیه رو نگیر

[soorena]

سلام

چیزی که ایشون میگن از نظر علمی‌ غیر ممکن هستش و من بار‌ها این رو براشون گفتم. ایشون تو یک سایت خارجی‌ هم رفتن همچین ادعایی کردن و اونجا هم مورد تمسخر دیگران واقع شدن.

[یوسف زالی]

من الان این جا رو دیدم،
می شه یک فایل 70 گیگی رو تنها در 10 بایت ذخیره کرد،
مثال:
FF FF FF FF FF FF FF FF FF 41

9 بایت اول اون نشانگر تعداد تکرار هست و بایت آخر (در اینجا A) نشانگر چیزی که قراره تکرار شه!
با اکسترکت کردن اون به راحتی می شه به یک فایل 70 گیگی رسید.

پس دیدید که می شه!
اصلا هم مسخره نکردم

[FastCode]

من الان این جا رو دیدم،
می شه یک فایل 70 گیگی رو تنها در 10 بایت ذخیره کرد،
مثال:
FF FF FF FF FF FF FF FF FF 41

9 بایت اول اون نشانگر تعداد تکرار هست و بایت آخر (در اینجا A) نشانگر چیزی که قراره تکرار شه!
با اکسترکت کردن اون به راحتی می شه به یک فایل 70 گیگی رسید.

پس دیدید که می شه!
اصلا هم مسخره نکردم

حداقل سایز رو درست مینوشتید که معلوم باشه مسخره نکردید.

در بعضی مواقع واقعا میشه.
مثل ۸ گیگ در ۶۱۲ بایت با فرمت lzma.tar.lzma
با lzma -c1 که کمترین حد فشرده سازی قابل قبول برای این الگوریتم هست.(بهترین فشرده سازی با -9)
الگوریتمی مثل جی زیپ در همین وضعیت فایلی به شدت حجیم تر تولید میکنه.
شاید بشه الگوریتمی با قدرت خیلی بیشتر از چیزی که الان میتونیم تصور کنیم نوشت ولی مطمئنا به این سادگی ها نیست.و مطمئنا نمیتونه به این شکلی که mebd12 گفتن باشه.

من برای رد کردنش ۶ تا دلیل دارم.

[یوسف زالی]

جا نشد محاسباتم..!
من برای رد کردنش یک دلیل دارم. اون آقا اگر تشریف آورد بحث رو ادامه می دیم..

[soorena]

دوستان اگر دوست دارین تو این زمینه به صورت تخصصی بحث و تبادل نظر کنیم میتونیم یک تاپیک جدید باز بکنیم و الگوریتم‌ها و برنامه همون رو توش بذاریم.

[the king]

دوستان اگر دوست دارین تو این زمینه به صورت تخصصی بحث و تبادل نظر کنیم میتونیم یک تاپیک جدید باز بکنیم و الگوریتم‌ها و برنامه همون رو توش بذاریم.

با این تفاوت که بجز ارائه الگوریتم یا نمونه کد و تحلیل مستندات ارائه شده فعالیتی داخلش انجام نشه وگرنه
اگه در اون تاپیک هم ادعا های غیر منطقی مطرح بشه، مثل این تاپیک از موضوع اصلی اش منحرف خواهد شد.

[abol122]

دوستان سلام
میخواستم بدونم قیمت الگوریتم فشورده سازی در سه حالت تقریبی 25و50و75 در صد بدون دونستن نوع فایل چقدر است؟(در ضمن زمان استاندارد مورد نیاز چقدر است)

[farid_new]

سلام میشه لطفا به من بگین از کجا ایگوریتم های فشرده ساز رو پیدا کنم .مرسی

[FastCode]

دوستان سلام
میخواستم بدونم قیمت الگوریتم فشورده سازی در سه حالت تقریبی 25و50و75 در صد بدون دونستن نوع فایل چقدر است؟(در ضمن زمان استاندارد مورد نیاز چقدر است)

بدون دونستن نوع فایل غیر ممکنه.
دو تا شرکت هستن که jpg و mp3 رو فشرده میکنن.
یکی هم هست که با درصد خیلی کمتر از چیزی که گفتید همه چیز رو فشرده میکنه.
۷۵ هم به جز فایلهای متنی یا enteropy خیلی کم غیر ممکنه.

بعضی چیزها با پول حل نمیشه.باید فکر کنید.

[abol122]

بدون دونستن نوع فایل غیر ممکنه.
دو تا شرکت هستن که jpg و mp3 رو فشرده میکنن.
یکی هم هست که با درصد خیلی کمتر از چیزی که گفتید همه چیز رو فشرده میکنه.
۷۵ هم به جز فایلهای متنی یا enteropy خیلی کم غیر ممکنه.

بعضی چیزها با پول حل نمیشه.باید فکر کنید.

تشکر بابت راهنماییتان
اگر ساخته شده باشه قیمت تقریبی اش چقدر است (بدون دونستن نوع فایل)

[FastCode]

معمولا این برنامه ها زیر ۱۰۰ دلار هستن
بدون دونستن نوع فایل ۱۰۰ هزار دلار هم که باشه من مشتری اولشم.

[abol122]

معمولا این برنامه ها زیر ۱۰۰ دلار هستن
بدون دونستن نوع فایل ۱۰۰ هزار دلار هم که باشه من مشتری اولشم.

جناب FastCode فکر کنم قیمتی که برای فشرده ساز بدون نوع دادین خیلی پایینه .دوستان دیگه نظری ندارن

[FastCode]

جناب FastCode فکر کنم قیمتی که برای فشرده ساز بدون نوع دادین خیلی پایینه .دوستان دیگه نظری ندارن

100 هزار دلار کمه؟

[abol122]

100 هزار دلار کمه؟

خوب میشه از این برنامه در ارتباطات ماهواره ای و نظامی استفاده کرد.(در ضمن کمپرس تا بالای %93)

[یوسف زالی]

دوستان قسمت فنی این ماجرا کجاست؟؟

[abol122]

دوستان قسمت فنی این ماجرا کجاست؟؟

زمان و هزینه های دیگر در مقایسه با گسترش علم

[soorena]

سلام

ادعائی که شما میکنی‌ خیلی‌ جالبه من برای اینکه به این بحث مسخره پایان بدم یه فایل براتون آپلود کردم که دقیقا ۱۰۰،۰۰۰ بایت هستش اگر تونستی حتا ۱ بایت این فایل رو فشرده تر بکنی‌ خبر بده.
http://maroofi.persiangig.com/test_c...mpressible.dat

[3ddisplay]

با سلام به همگی
خوب دوستان در مورد فشرده سازی نظر خودشون دادن من تازه وارد این سایت شدم . و اما در مورد فشرده سازی لازم چند نکته رو بدونیم هر چند همه استادنند . الگوریتم های زیادی در فشرده سازی کاربرد دارند و نکته مهم تو کاربردشون هست . یکی برای عکس ، فایل ویدئو ، صدا و... پس اولین قدم انتخاب نوع الگوریتم هست . یادمون باشه الگوریتم فشرده سازی ویدئو توی صدا و یا دیتای خام شاید جواب مفی هم بده .اول نوع داده و ماهیت اون رو مشخص کنید و بعد در موردش بحث کنید . من نظر کاملا متفاوتی رو در خصوص فشرده سازی دیتا دارام . اینجا منظورم همون 0و1 هست . اول بر میگرده به حافظه های در دسترس ما و ساختار داخلی اونها به نظر من این حافظه ها از توانایی فشرده سازی و عمل عکس اون در سرعت های بالا برخوردار نیستند در واقع نمی تونند باشند و این بر میگرده به نوع آدرس دهی در آنها هر جند در چند سال اخیر رشد قابل ملاحظه ای در این خصوص از خود نشان داده اند .مورد دیگه مربوط به رابط های حافظه با پردازنده و نحوه تبادل دیتا با اون هست که خودش موضع مفصلی هست. و اینکه ایا امکان فشرده سازی با ضریب بالا وجود داره ؟چند سالی هست دارند روش کار می کنند شاید این رو یکی از انقلاب هادر دنیای دیجیتال به حساب آورد . برای نزدیک شدن به موضوع اشاره ای به دستورات اسمبلی در arm رو دارم arm یک پردازنده 32 بیتی هست ولی برای کاهش مصرف در حافظه و کدهای تولیدی دستورات 16 بیتی به نام thumb داره و حالا این چی هست باشه برای بعد. در واقع با یک دستور 16 بیتی در فظای 32 بیتی همون کار مشابه دستور 32 بیتی در پردازنده های دیگه رو انجام میده . پس این فشرده سازی ممکنه فقط باید دید چی رو از دست میدیم روشی که مد نظر من هست فشرده سازی با سرعت بالا و نحوه ذخیره و بازیابی در حافظه ها است . تو یه پروژه مجبور شدم برم دنبالش و چند تا طراحی رو انجام بدم . نکته اینه که الگوریت هایی که من روشون کار میکنم کامپیوتر های معمولی به سختی می تونند با سرعت بالا اون اجرا کنند و خیلی کندند و یا اصلا نمی تونند انجام بدند. زبان برنامه نویسی برای این الگوریت ++c و اسمبلی هست . امکان فشرده سازی تا 16 برابر در این الگوریت وجود داره و اینم بگم هر چی داده هامون بیشتر باشند امکان فشرده سازی اون بیشتر هست نکته خیلی مهم کاهش شدید سرعت در فشرده سازی با افزایش ضریب و اندازه بسته های دیتا از معایب این الگوریتم هست بنابر این با توجه به سخت افزار در دسترس این گزینه تنظیم می گردد . اشاره می کنم این روش ارتباط مستقیم با نوع حافظه ای که استفاده میشه داره . بعد کلی تلاش میشه گفت در صورتی که از حافظه های بافر چند کاناله (منظورم تعداد باس دیتا و آدرس ، دسترسی چند کاناله به دیتای درون اون هست) بشه ساخت با سرعت خیلی زیاد میشه این کار رو انجام داد، البته به بسته دیتا و سطح فشرده سازی بستگی داره. سرعت 1/20 کلاک رو میتونه بده . ساده بگم فرض کنید یه توپ دارین داخل توپ دیتا هست و سطح خارجی توپ رو آدرس ها شامل میشوند. و قطر کره ،اگه از هر وجه به اون نگاه کنید بی نی نهایت قطر دارین و بی نهایت مرکز قطر که همون مرکز کره هم هست خب بقیش هم باشه برای وقتی که کامل شد . و در نهایت بگم قراره یه چیپ طراحی بشه که دارای یه همچین بافری هست که بین حافظه ها و پردازنده قرار میگیره و با سرعت خیلی زیاد دیتا رو zip,unzip میکنه . مثلا اگه شما یه فلش با ظرفیت 8 گیگ و با سرعت تبادل 60M/S داشته باشین بدون اینکه متوجه بشین تا 4 برابر حجم اون رو کاهش میده . البته بزرگترین ضعف این روش قیمت تمام شده هست در بسیاری از موارد از قیمت خود حافظه هم تجاوز میکنه . تا 4 برابر قابلیت پیاده سازی در کامپیوتر های امروزی رو داره . شاید در آینده این الگوریتم مستقیما روی cpu ویا چیپ ست های مادر بورد پیاده سازی بشه . این الگوریتم در انتقال دیتا خیلی بیشتر از یه ذخیره سازی رو حافظه می ارزه . در حال حاظر این الگوریتم فقط در مورد حافظه ها قابل اجر است چون باید به فایل های بزرگ دیتا دسترسی داشته باشه . مدل ساده شده آن در nandflash ها با سرعت متوسط کاربرد داره و شاید دراینده بخشی از این حافظه ها رو به خودش اختصاص بده [IMG]file:///C:\Users\allah\AppData\Local\Temp\msohtmlclip1\01\ clip_image001.gif[/IMG]موفق باشین . اگه ساخته شد خبرتون میکنم