الگوریتم فشرده سازی [بایگانی]

B-Vedadian

چهارشنبه 03 دی 1382, 09:46 صبح

با سلام،

روشهای فشرده سازی به دو دسته با تلفات (Lossy) و بدون تلفات (Lossless) تقسیم می شوند که در روشهای بدون تلفات تنها الگوریتم اهمیت پیدا می کند ولی در روشهای با تلفات مانند فشرده سازی صوت بخش اعظم کار تحقیقات فیزیولوژیکی می باشد.

روش huffman: این روش در واقع یک الگوریتم است که براین پایه استوار است که تعداد تکرار داده های درون یک فایل با هم یکسان نیستند مثلا در مورد بانک داده های نمرات دانش آموزان که نمرات تعداد تکرار یکسان ندارند.

با این الگوریتم داده های با تعداد تکرار بیشتر کدهای کوتاهتر نسبت داده میشود و در نتیجه به داده های با تعداد تکرار کمتر کدهای بلند تر. برای مثال:

(الف) تعداد تکرار 5 (ب) تعداد تکرار 6 و (ج) تعداد تکرار 30 را در نظر بگیرید

برای نمایش 3 داده به 2 بیت نیاز است. بنا بر این فایل معمولی شامل 5*2+6*2+30*2 یعنی 82 بیت خواهد بود. اما با الگوریتم Huffman به (ج) کد 1 بیتی به (ب) کد 2 بیتی و به (الف) کد 2 بیتی نسبت داده می شود. لذا به 5*2+6*2+30*1 یعنی 52 بیت داده نیاز است.

http://www.byui.edu/ricks/employee/CAMERONG/cs235/chap10.5.pdf

روش Run length: در این روش هم بنا بر تعداد تکرار غیر یکسان داده هاست، به این ترتیب که داده های تکراری که پشت سرهم نوشته شده باشند (مثلا داده «الف» 13 بار پشت سرهم تکرار شده باشد) ابتدا تعداد تکرار و بعد داده نوشته می شود (در همان مثال ابتدا 13 و بعد «الف» ذخیره میشود.)

روش LZW: این روش توسط دو دانشمند به نامهای Lempel و Ziv پایه گذاری شده و توسط Welch تکمیل گشت. این هم یک الگوریتم است که بر مبنای یافتن «الگو»های تکراری استوار است. الگوهای تکراری داده در فایل پیدا شده و به هر کدام یک کد نسبت داده می شود و به جای هر الگو تنها یک کد در فایل مقصد قرار می گیرد.

http://ginger.cs.uwp.edu/Cis580/LZWovrhd.pdf

روش Linear Prediction یا LP: این روش یک روش با تلفات است که بیشتر برای صدای انسان بکار میرود. پکیج های آماده Celp , Melp بر این مبنا کار میکنند.

در این روش حنجره انسان با یکسری استوانه های با قطرهای متفاوت و با طول یکسان مدل میشود. این مدل با تقریب خوبی برای 10 میلی ثانیه صادق است.

برای خیشومی مانند خ و ش و ... یک نویز سفید (داده های تصادفی با انرژی ثابت برای تمام فرکانسها که یک نوع تابع آماری است و به راحتی تولید میشود) کافیست تا با مدل بالا تولید صدای دلخواه را بکند یعنی تعداد محدودی (معمولا 5 ضریب) عدد 4 بیتی برای 10 میلی ثانیه صوت داده های لازم را فراهم می کند. این 20 بیت را با 110.25 * 8 بیت که تقریبا حد اقل داده مورد نیاز برای صوت در 10 میلی ثانیه است مقایسه کنید.

روش JPEG: این روش که استاندارد حرفه ایهای فایلهای گرافیکی است باز هم با تلفات است و براین مبنا کار می کند که چشم انسان به تغییرات سریع شدت نور کمترین حساسیت را دارد. در این روش ابتدا داده های تصویری را با تبدیل DCT به حوزه فرکانس برده و سپس فرکانسهای بالا را با تعداد بیت بیشتر و پایین را با تعداد بیت کمتر ذخیره میکنند. نتایج کار دوباره به روش Huffman فشرده میشود.

B-Vedadian

دوشنبه 08 دی 1382, 09:04 صبح

با سلام،

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

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

در این لحظه فقط می توانم این مستند عالی راجع به پیشگویی خطی را معرفی کنم:

http://www-ccrma.stanford.edu/~jos/SMAC03S/SMAC03S.pdf

marandi

دوشنبه 08 دی 1382, 12:20 عصر

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

در مورد برنامه های فشرده ساز من خودم هم برنامه هایی را دارم که حدود 60 الگوریتم را به صورت Open Source در اختیار گذاشته اند. حقیقتش من و خیلی از دوستان حوصله کنکاش به صورت خط به خط را نداریم ولی امیدوارم که یک معلم آگاه همانند شما که اطلاعات جامع ای از این روش ها دارد خیلی راحتتر بتوانید ما را در زمینه ساخت این الگوریتم ها کمک نمایید.

B-Vedadian

چهارشنبه 10 دی 1382, 09:09 صبح

با سلام،

نخست من معلم آگاه نیستم!

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

-«جدول» درخت دودویی جستجو با داده های زیر در گره
*مقدار:نوع مثلا کاراکتر
*فرکانس تکرار
- رابطه مقایسه گره ها همان مقایسه فرکانس تکرار.

-«لیست» یک لیست پویا با عناصر از نوع گره های درخت.

1- به تعداد انواع داده در فایل گره با مشخصات زیر بساز:
*فرزند چپ:پوج
*فرزند راست:پوچ
*فرکانس تکرار که مشخص است.
*مقدار:خود داده

2-گره های «جدول» را در لیست قرار بده.

3-گرههای «آ» و «ب» با کمترین تعداد تکرار را در «لیست» پیدا کن. (آ و ب به ترتیب صعودی)
4-گره جدیدی در «جدول» با مشخصات زیر بساز:
*فرزند چپ:«ب»
*فرزند راست:«آ»
*فرکانس تکرار: مجموع فرکانسهای تکرار «آ» و «ب»
*مقدار: مهم نیست.
5-والد «آ» و «ب» را گره جدید قرار بده.
6- گرههای «آ» و «ب» را از «لیست» حذف کن.
7- آیا فرکانس تکرار گره جدید برابر کل اندازه فایل است؟
> بلی: برو به 8
> خیر: برو به 3

8- برای گرههای آخرین لایه درخت (لایه ای که هیچ فرزندی ندارد) بصورت زیر کد نسبت بده:
:> با شروع از اولین لایه (گرهی که هیچ والدی ندارد) مسیری که به گره مورد نظر میرسد را طی کن. به ازای هر حرکت از «والد» به «فرزند چپ» یک صفر و به ازای حرکت از «والد» به «فرزند راست» یک به کد اضافه کن.

...

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

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

در مرحله بعد سعی می کنیم درختی بسازیم که از ریشه آن با کمترین مسیر به داده ای برسیم که بیشترین تکرار را دارد. با ساختن این درخت مسیر از ریشه به هر داده مورد نظر ما کد آن داده باشد و لذا نتیجه دلخواه بدست آید.

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

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

امیدوارم مفید واقع شود.

aspersica

یک شنبه 16 اسفند 1383, 21:33 عصر

دوستان عزیز درست میگن!
روشهای زیادی وجود داره مثل Huffmann ! اما Huffmann فقط برای compress هست!
یه کارهایی هست که در واقع فایل رو کوچیک نمی کنن اما باعث میشن که huffmann بهتر کار کنه!
یکی از این روشها BWT هست( Burrows-Wheeler Transform )
این روش از 3 الگوریتم مختلف به دنبال هم استفاده میکنه!
1 - borrows -wheeler algorithm
2 - move to front coding algorithm
3 - huffman compresing

اگه کسی خواست به من اطلاع بده که اونها رو بیشتر توضیح بدم!

aspersica

سه شنبه 18 اسفند 1383, 16:02 عصر

توضیح بده اخوی که مشتاقیمباز هم سلام !‏

از اونجایی که مقدار بحث ها زیاده به نظرم اگه قسمت قسمت بشه بحث خیلی بهتره!‏
خوب از باروز-ویلر شروع کنیم!‏

الگوریتم باروز ویلر در سال 98 به اثبات رسید و در واقع از 1986 داشت روش کار می شد. مقاله های زیادی در ‏مورد اون هست. در واقع خود الگوریتم نتیجه ای است از یک مقاله تحقیقاتی که در سال 1986 ارائه شد ( توسط ‏باروز و ویلر ) اما خوب اثبات بهینه بودنش در سال 1998 به اتمام رسید.‏

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

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

فرض کنید یه رشته مثل ‏abnshdbswd‏ داشته باشیم! ‏
اونچیزی که بر میگرده رشته ی ‏dadwhsbnbs‏ و عدد 2 خواهد بود!‏

اما چطوری؟؟
یه جدول مثل جدول زیر در نظر بگیرید:‏
‏1 - ‏abnshdbswd
‏2 - ‏bnshdbswda
‏3 - ‏nshdbswdab
‏4 - ‏shdbswdabn
‏5 - ‏hdbswdabns
‏6 - ‏dbswdabnsh
‏7 - ‏bswdabnshd
‏8 - ‏swdabnshdb
‏9 - ‏wdabnshdbs
‏10 - ‏dabnshdbsw

خوب چه اتفاقی افتاد؟‎ ‎ما رشته اولیه مون رو در واقع یه دونه یه دونه ‏rotate ‎‏ دادیم! همین!‏
حالا همین رشته ها رو با همین شماره ها شون به ترتیب حروف الفبا می کنیم! ‏

نتیجه اینه :‏
‏1 - ‏abnshdbswd
‏2 – ‏bnshdbswda
‏7 – ‏bswdabnshd
‏10 – ‏dabnshdbsw
‏6 – ‏dbswdabnsh
‏5 – ‏hdbswdabns
‏3 - ‏nshdbswdab
‏4 - ‏shdbswdabn
‏8 - ‏swdabnshdb
‏9 - ‏wdabnshdbs

آهان ! حالا شد! حالا همه ی حروف آخر ها رو که پشت سر هم بذاری میشه چی؟ می شه همون رشته ی جواب! ‏عدده هم که تابلو ! عدد یه که اونجا حرف آخر اولین حرف رشته است!‏

این کل الگوریتم ایه که اونهمه سال روش فکر شد! حالا چون نمی خوام خودم و شما ها خسته شین! بقیه اش رو ‏میذارم برای بعد! ‏

آهان یه چیزی! روی ‏reverse ‎اش فکر کنید! خیلی آسونه! ‏

دفعه بعد ‏reversesh ‎‏ رو میگم!‏

فعلا! ‏

hamidhws

جمعه 30 مرداد 1388, 03:17 صبح

با سلام خدمت دوستان عزیز
اول لازمه بدونید که من در حدود 8 سال هست که شاید بیشتر وقتمو صرف کار روی الگوریتمای فشرده سازی کردم
من مقاله های زیادی در مورد الگوریتم های زیپ خوندم و الگوریتمایی که در حال حاظر استفاده میشه اکثرا از نوع هافمن یا مشابه هستن و من این روش هارو حدود 6 7 سال پیش تست کردم (نمیدونم اونموقع الگوریتم هافمن ساخته شده بود یا نه:متعجب:) ولی هدف من چیز دیگه ای بود و هست و به نظر من الگوریتم های فشرده سازی در حال حاظر نوعی شوخی هستند و الگوریتمای بسیار پیش پا افتاده و ساده ای رو استفاده میکنند(قصد توهین به هیچ شخص حقیقی یا حقوقی رو ندارم و صرفا نظرم رو گفتم)
نکته 1-هیچکدام از روش های زیپ (تا اونجایی که میدونم) قادر به اعمال فشرده سازی پیاپی رو ندارند (یعنی نمیتونن یه فایل زیپو دوباره زیپ کنن) و این یعنی هیچکدوم با بیت ها سرو کار ندارند و الگوریتم های اونها صرفا روی کارکتر متمرکزه
نکته 2 - هیچکدوم ازروش های زیپ فعلی قادر نیستن یک فایل تصویری رو به روش unless فشرده کنن
و چنتا نکته و یا نقطه ضعف دیگه که الان به ذهنم نمیرسه
دوستان همه اینا بخاطر اینه که همگی روش های فعلی بر کاراکتر متمرکزه و هیچکدوم بر روی بیت ها کار نمیکنن !

و همین موجب شده که مدت ها وقتمو روی کار با بیت ها و ساخت الگوریتمای فشرده سازی کنم
هدف من خیلی بزرگه و چون هنوز جای کار داره شاید اگه بخوام مطرحش کنم خیلی ها براشون غیر قابل باور و نشدنی برسه درست مثل اینه که یه جهش زمانی کنی و به به زمانی که هنوز کالسکه اختراع نشده بود بری و بخوای از بوئینگ 747 بگی :متعجب::بامزه:

Babak.Hassanpour

جمعه 30 مرداد 1388, 09:17 صبح

درست مثل اینه که یه جهش زمانی کنی و به به زمانی که هنوز کالسکه اختراع نشده بود بری و بخوای از بوئینگ 747 بگی

علی الحساب که پنج سال برگشتی عقب.(سه شنبه 18 اسفند 1383 16:32 عصر)

hamidhws

جمعه 30 مرداد 1388, 14:59 عصر

علی الحساب که پنج سال برگشتی عقب.(سه شنبه 18 اسفند 1383 16:32 عصر)

خوب اینم یه جور جهش زمانیه دیگه
مثل سریال لاست :لبخند:

ولی از تذکرت ممنون داداش راستشو بخوای اصلا حواسم به زمانش نبود معذرت :خجالت:

goli jon

پنج شنبه 12 آذر 1388, 09:26 صبح

nima898

سه شنبه 17 آذر 1388, 13:41 عصر

نکته 2 - هیچکدوم ازروش های زیپ فعلی قادر نیستن یک فایل تصویری رو به روش unless فشرده کنن
میشه یه فایل تصویری رو بدون توجه به نوعش و بدون تلفات با winrar فشرده کرد

لطفا بیشتر در مورد الگوریتم هافمن توضیح دهید اصلا هافمن الگوریتم فشرده سازی هست یا نه؟
پاسخ آقای aspersica مربوط به پنج سال قبله

Behrooz_CS

سه شنبه 08 دی 1388, 12:56 عصر

اول لازمه بدونید که من در حدود 8 سال هست که شاید بیشتر وقتمو صرف کار روی الگوریتمای فشرده سازی کردم
من مقاله های زیادی در مورد الگوریتم های زیپ خوندم و الگوریتمایی که در حال حاظر استفاده میشه اکثرا از نوع هافمن یا مشابه هستن و من این روش هارو حدود 6 7 سال پیش تست کردم

سلام

من هم مثل شما توی فکر نوشتم همچین چیزی بودم
از سال 81
بارها الگوریتم و برنامه تستی نوشتم که با شکست مواجه شدم !
آخرین بار تونستم در حد زیپ فشرده کنم البته بدون توجه به کاراکترها و فقط از روی ترتیب بیت ها ! این موفقت خوبی بود و به خودم افتخار می کنم اما مشکل اینجاست که این کار رو قبلا انجام دادن !
من اینو 4 ماه پیش فهمیدم و خیلی توی ذوقم خورد !
اینو ببین ! امیدوارم شما هم مثل من دپرس نشی !!!
http://www.nosltd.com/index.php/products/inosso-for-win-mac-and-linux

اگر تونستی نرم افزارشو گیر بیاری برای من هم بفر ستی ممنونم می شم
موفق باشی

hamidhws

سه شنبه 08 دی 1388, 17:43 عصر

سلام

من هم مثل شما توی فکر نوشتم همچین چیزی بودم
از سال 81
بارها الگوریتم و برنامه تستی نوشتم که با شکست مواجه شدم !
آخرین بار تونستم در حد زیپ فشرده کنم البته بدون توجه به کاراکترها و فقط از روی ترتیب بیت ها ! این موفقت خوبی بود و به خودم افتخار می کنم اما مشکل اینجاست که این کار رو قبلا انجام دادن !
من اینو 4 ماه پیش فهمیدم و خیلی توی ذوقم خورد !
اینو ببین ! امیدوارم شما هم مثل من دپرس نشی !!!
http://www.nosltd.com/index.php/products/inosso-for-win-mac-and-linux

اگر تونستی نرم افزارشو گیر بیاری برای من هم بفر ستی ممنونم می شم
موفق باشی

دوست عزیز مرجع فارسی نداره ؟

میشه یکم بیشتر توضیح بدید ؟

مثلا آیا قادره همه فایل ها رو بدون توجه به پسوند فشرده کنه؟
و چند درصد؟ آیا توی همه فایل ها به یک اندازه هست؟

مثلا 100 مگابایت رو در چه مدت زمانی چقدر میکنه؟

با تشکر

Behrooz_CS

سه شنبه 08 دی 1388, 19:29 عصر

دوست عزیز مرجع فارسی نداره ؟

میشه یکم بیشتر توضیح بدید ؟

مثلا آیا قادره همه فایل ها رو بدون توجه به پسوند فشرده کنه؟
و چند درصد؟ آیا توی همه فایل ها به یک اندازه هست؟

مثلا 100 مگابایت رو در چه مدت زمانی چقدر میکنه؟

با تشکر

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

hamidhws

سه شنبه 08 دی 1388, 19:41 عصر

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

100 مگابایت شده 50 مگابایت؟

Behrooz_CS

چهارشنبه 09 دی 1388, 14:29 عصر

100 مگابایت شده 50 مگابایت؟

همین دیگه ! منم مخم سوت کشید !!!:عصبانی++:
هرچی دودو تا 4 تا می کنم درک نمی کنم !!
نمونه عملیش هم هست می تونی ببینی ! من این نرم افزارو می دونی چطوری پیدا کردم ؟
داشتم یه روز Acrobat Reader نصب می کردم رفتم توی Temp ببینم Extract می کنه چقدر می شه دیدم Setup که 20 مگ هست شده 70 مگابایت !!!! بعد 70 مگا بایت را RAR و 7z و ZIP کردم دیدم از 40 و 45 مگابایت کمتر نمی شه !!! اونجا بود که فهمیدم این یه فشرده ساز معمولی نیست !! بابا خیلی خفنه !!:گریه:
نرم افزارش هیچ جا نیست تا دانلود کنیم ! نامرد حتی DEMO هم نزاشته
ببین راهی نیست دانلودش کرد:گریه::متعجب:

تازه توی یه عکس دیگه گفته 100% فایل zip یا rar را می کنه 20% !!!!!!!!:متعجب: :متعجب: :متعجب: :متعجب: :متعجب: :متعجب: :متعجب: :متعجب: :متعجب: :متعجب: :متعجب: :متعجب: :متعجب: :متعجب: :متعجب:

hamidhws

پنج شنبه 10 دی 1388, 13:33 عصر

سلام

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

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

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

ببین دوست عزیز مبحث فشرده سازی خیلی خیلی خیلی پیچیدس و غیر از مبحث compress و
decompres باید زمان عملیات رو هم مد نظرداشت که در مجموع این 3 مولفه اگه بخواهیم به حداکثر نتیجه برسیم شاید یکی از سخت ترین فرضیات علمی در طول تاریخ بشر رو حل کرده باشیم!

خب حالا کاری که بنده در پی انجامش هستم و به نتایجی هم رسیدم اما نه 100% >> فشرده سازی فایل ها تا مرز 0 و تبدیل اونها به ارقام 10 تا 100 رقمی (هنوز تعداد به طور قطع مشخص نیست)

میدونم خیلی ها اصلا براشون این مساله قابل درک نیست که مثلا یه فایل (نوع فایل مهم نیست) 100 مگابایتی بشه یه کد 20 30 رقمی !

اما لازمه بگم حدود 50% کار طی این نزدیک به 1 دهه کار مداوم به نتیجه رسیده و هدف و کار هم کاملا برنامه ریزی شده و مشخصه و خیلی خوش بینم که تا چند سال دیگه به لطف خدا به نتیجه اصلی برسم

انشالله تا اونموقع همچین کاری نشه :ناراحت:
اونایی که روی همچین مسائلی زمان زیادی میزارن منظورمو بهتر میفهمن

به امید سرافرازی ایرانی

مصطفی ساتکی

پنج شنبه 10 دی 1388, 14:05 عصر

شما 3 سال وقت واسه چی می خای.اگر ایدتون پایه علمی داره همین حالا یه paper بفرستید برای IEEE وگرنه وقت تلف کنی.

hamidhws

پنج شنبه 10 دی 1388, 18:17 عصر

شما 3 سال وقت واسه چی می خای.اگر ایدتون پایه علمی داره همین حالا یه paper بفرستید برای IEEE وگرنه وقت تلف کنی.

عرض کردم کار هنوز تکمیل نشده به محض تکمیل شدن حتما

این زمانو هم حدودی دادم به عنوان حد اکثر چون تو این کار مشکلات غیر قابل پیش بینی زیاد هست

مصطفی ساتکی

پنج شنبه 10 دی 1388, 21:32 عصر

البته به شما بگم الان فشرده سازی ها 700 مگابایتو به 20 کیلو بایت تبدیل می کنند ولی زمان گیره شما بایستی این زمان یا این حجمو کاهش بدید

hamidhws

پنج شنبه 10 دی 1388, 22:12 عصر

البته به شما بگم الان فشرده سازی ها 700 مگابایتو به 20 کیلو بایت تبدیل می کنند ولی زمان گیره شما بایستی این زمان یا این حجمو کاهش بدید

میشه بفرمایید این مطلبو از کجا آوردید

مصطفی ساتکی

پنج شنبه 10 دی 1388, 23:48 عصر

ای بابا.این تو سی دی king هم پیدا میشه پس شما به روز نیستی

hamidhws

جمعه 11 دی 1388, 03:06 صبح

ای بابا.این تو سی دی king هم پیدا میشه پس شما به روز نیستی

چشم بنده به روز نیستم شما که به روز هستی میشه لطفا اسم این برنامه یا جایی که در موردش اطلاعات هست رو بفرمایید؟

به هر حال اگه شما نرم افزار فشرده سازی رو پیدا کردید که یه فایل تصویری رو بدون کاهش کیفیت نصف کنه (حالا 20 کیلو بایت هم نخواستیم) بنده شخصا برنامه نویسی رو کنار میزارم
توجه : منظور بنده فایل هایی از قبیل mkv ,.. نیست

در بالا منظور بنده فشرده سازی فایل بدون توجه به پسوند و نوع فایل بود که در غیر این صورت بعضی از فایل ها مثلا یا پسوند bin خیلی زیاد فشرده میشن که اینم به خاطر نوع تکرار بیت هاست (کاراکترها)

به همین دلیل هست که در مورد فایل های تصویری به دلیل درصد پایین تکراری بودن به نسبت درصد فشرده سازی هم با الگوریتم های موجود(معمولا هافمن) پایین میاد

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

به هر حال توصیه میکنم هر چیزی رو دیدید یا شنیدید قبول نکنید

با تشکر

Behrooz_CS

جمعه 11 دی 1388, 10:23 صبح

البته به شما بگم الان فشرده سازی ها 700 مگابایتو به 20 کیلو بایت تبدیل می کنند ولی زمان گیره شما بایستی این زمان یا این حجمو کاهش بدید

آقا منم شدیدا مشتاق شدم بدونم اون برنامه چیه ؟
مطمئنم سر کاریه !! احتمالان می خوای بگی KGB هست :لبخند:

مصطفی ساتکی

جمعه 11 دی 1388, 13:55 عصر

نرم افزار KGB می تونید برید تو سایتش http://kgbarchiver.net
یه نگاهی به UHARC compressed هم بیاندازید

hamidhws

جمعه 11 دی 1388, 20:02 عصر

نرم افزار KGB می تونید برید تو سایتش http://kgbarchiver.net
یه نگاهی به UHARC compressed هم بیاندازید

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

اگه اشتباه نکنم KGB همونه که آفیس رو کم حجم کرده بودن باهاش ؟ اگه این باشه شخصا میگم خودشو مسخره کرده و همچنین مردمو

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

با تشکر

MIDOSE

شنبه 12 دی 1388, 10:31 صبح

دوستان؛

الگوریتم فشرده سازیاسم تایپیک بیان گر محتوای اون هست؛ایده ها یا نظرات خود را یا از طریق پیغام خصوصی یا در چت روم ها مطرح کنید و با سایر بحث ها سبب اف شدن تایپیک نشوید.

پ.ن:تایپیک پاک سازی شد.

موفق باشید.

khamse

یک شنبه 29 فروردین 1389, 08:48 صبح

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

khamse

یک شنبه 29 فروردین 1389, 09:06 صبح

سلام
من ی سمینار درباره ی الگوریتم زیپ دارم میشه اطلاعات جدید بیشتری در اختیارم بزارین
ممنون میشم

Behrooz_CS

یک شنبه 29 فروردین 1389, 11:41 صبح

منبع فارسی من سراغ ندارم ! باید بری زبان اصلی بخونی ، در این زمینه کتاب های زیادی نوشته شده
می تونی خیلی راحت توی آمازون پیداشون کنی و از جاهای دیگه مثل رپید شیر دانلودشون کنی
Data Compression را توی آمازون جستجو کن

khamse

دوشنبه 30 فروردین 1389, 11:19 صبح

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

EbiPenMan

پنج شنبه 09 اردیبهشت 1389, 21:23 عصر

سلام بر همگی

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

سوالم اینکه باید روی چه الگوریتمی کار کنم؟ هافمن

هافمن فکر کنم خوب نباشه اگه هم خوب باشه ترکیبی با الگوریتم دیگه ای خوبه.

بعدش ام این برنامه ای که به سفارش همراه اول و همکاری دانشگاه شریف و شرکت آسان افزار
نوشته شده تو دربارهش نوشته که با الگوریتم " پروتکل ابرمتن فارسی انتقال پذیر، جهت بسترهای ارتباطی محدود" استفاده کردن.

می خوام ببینم که این پروتکل قضیه اش چیه؟ من درآوردی هست یا میشه چیزی در موردش تو اینترنت پیدا کرد ( من که هرچی گشتم نبود)

کسی می تونه کمک کنه؟

fakher

دوشنبه 11 مرداد 1389, 19:32 عصر

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

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

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

موفق باشید و پیروز

soorena

شنبه 23 مرداد 1389, 19:33 عصر

سلام
نميدونم چندمين پستمه تو اين forum ولی خوب خيلی حال کردم ديدم بچه ها تو اين ضمينه هم کار ميکنن.
راستش منم يه چند ماهی ميشه که تو اين ضمينه کار ميکنم و خوب خيلی خوشحالم که دوستان ديگه هم اينجا هستن.

فقط يه چند تا چيزه کوچولو هم ميخواستم بگم :

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

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

به نظر می توان الگوریتمی طراحی کرد که بدون در نظر گرفتن نوع و پسوند فایل فایلها را چنان فشرده کرد که بدون تلف شدن حتی یک بیت از داده اصلی آنرا در چندین بایت ناقابل خلاصه نمود

خوب يه چيزی که خيلی مهمه اينه که هيچ نوع فشرده ساز عمومی وجود نداره و اينکه داده های تصادفی هم قابل فشرده سازی نيس.پس هيچ وقت نبايد دنبال همچين الگوريتمی بود.
راستی من يه وب سايت هم دارم ميزنم که بيشتره مطالبش در مورد همين فشرده سازی هستش خوشحال ميشمگه کسی علاقمند باشه و اگه مطلبی يا هر کری تو اين ضمينه کرده بفرسته .
اينم ادرسش http://www.maroofi.persiangig.com

Behrooz_CS

یک شنبه 24 مرداد 1389, 09:23 صبح

سلام
نميدونم چندمين پستمه تو اين forum ولی خوب خيلی حال کردم ديدم بچه ها تو اين ضمينه هم کار ميکنن.
راستش منم يه چند ماهی ميشه که تو اين ضمينه کار ميکنم و خوب خيلی خوشحالم که دوستان ديگه هم اينجا هستن.

فقط يه چند تا چيزه کوچولو هم ميخواستم بگم :

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

خوب يه چيزی که خيلی مهمه اينه که هيچ نوع فشرده ساز عمومی وجود نداره و اينکه داده های تصادفی هم قابل فشرده سازی نيس.پس هيچ وقت نبايد دنبال همچين الگوريتمی بود.
راستی من يه وب سايت هم دارم ميزنم که بيشتره مطالبش در مورد همين فشرده سازی هستش خوشحال ميشمگه کسی علاقمند باشه و اگه مطلبی يا هر کری تو اين ضمينه کرده بفرسته .
اينم ادرسش http://www.maroofi.persiangig.com

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

nima898

دوشنبه 25 مرداد 1389, 09:11 صبح

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

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

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

soorena

دوشنبه 25 مرداد 1389, 11:44 صبح

خوب البته اين يک امر کاملا واضح هستش چون ما تا وقتی که نتونيم برای داده مون يه مدل بدست بياريم نميتونيم اونو فشرده کنيم و هرچه مدل ما بهتر باشه فشرده سازی بهتر خواهد بود.
اگر برای دوستان جالب هستش ميتونيد يه سری به سايت hutter prize بزنيد. اينم ادرسش (prize.hutter1.net) اينجا همين طور که ميبينيد يه رقابت برای فشرده سازی بيشتر تحت زمان و حافظه محدود هستش و جايزه هم داره!!!!!!!!!!! ميدونيد چه قد؟؟؟ 50000 يورو آره درسته به پول ما از 50 ميليون هم بيشتر ميشه.البته محاسبش فرمول داره و همه پول رو به کسی نميدن ولی به هر حال اگه دوس داشتيد بريد بخونيد.
راستی تو رنکينگ های جهانی در حال حاضر کمپرسور های سری PAQ که توسط matt mahoney اولين بار نوشته شد از همه قويترن ولی خوب مشکل اصليشون سرعت و حافظه هستش برای اطلاعات بيشتر بريد به (http://mattmahoney.net/dc) و ضمناً يک کتاب خوب هم به صورت online اينجا هست که به خوندنش ميارزه.
ممنون از تحملتون

soorena

سه شنبه 26 مرداد 1389, 00:09 صبح

خب حالا کاری که بنده در پی انجامش هستم و به نتایجی هم رسیدم اما نه 100% >> فشرده سازی فایل ها تا مرز 0 و تبدیل اونها به ارقام 10 تا 100 رقمی (هنوز تعداد به طور قطع مشخص نیست)

میدونم خیلی ها اصلا براشون این مساله قابل درک نیست که مثلا یه فایل (نوع فایل مهم نیست) 100 مگابایتی بشه یه کد 20 30 رقمی !

اما لازمه بگم حدود 50% کار طی این نزدیک به 1 دهه کار مداوم به نتیجه رسیده و هدف و کار هم کاملا برنامه ریزی شده و مشخصه و خیلی خوش بینم که تا چند سال دیگه به لطف خدا به نتیجه اصلی برسم

با عرض سلام خدمت دوست عزيز
جسارت نباشه بالاخره شما 1 دهه زحمت کشيدی عمرتو رو اين قضيه گذاشتی ولی خوب نميدونم يا من خيلی از معامله دورم يا شما !!!
تا جايی که من اطلاعات دارم همينطور که ميدونيد و البته اگه يه نگاهی به اين لينک بندازيد (http://mattmahoney.net/dc/dce.html#Section_12) متوجه ميشين که فشرده سازی حد پايين داره يعنی bounded هستش و از همه مهمتر اينکه :

Information theory places hard limits on what can and cannot be compressed losslessly, and by how much:

There is no such thing as a "universal" compression algorithm that is guaranteed to compress any input, or even any input above a certain size. In particular, it is not possible to compress random data or compress recursively.
Given a model (probability distribution) of your input data, the best you can do is code symbols with probability p using log2 1/p bits.
خوب همينطور که دارين ميبينيد البته اين نقل قول از طرف matt mahoney استاد دانشگاه florida و البته پيشتاز در علم فشرده سازی هستش و ديگه فک کنم واضح تو کتابش گفته که هيچ نوع الگوريتمی وجود نداره و نخواهد داشت که بتونه تضمين بکنه که هر فايلی رو بتونه به يه سايز مشخص برسونه و باز از همه مهمتر اينکه هيچ الگوريتمی به صورت بازگشتی(recursive) وجود نداره.اين قضيه از نظر رياضی کاملا اثبات شده پس فکر کنم اگه بيخيال اين پرژه بشين خيلی بهتر باشه.بازم هر جور که صلاح هستش.
حالا منظور از بازگشتی چيه؟؟؟
با يه مثال ميگم.اگه شما بتونی از تو هر 100 byte يک byte رو کم کنيد يعنی اگه هر 100 byte رو بتونيد بکنيد 99 byte، اونوقت هر نوع فايلی رو با هر حجمی ميتونيد تبديل به 99 byte بکنيد!!!(گرفتين قضيه چی شد؟؟؟) .به اين ميگن الگوريتم recursive که البته با اون recursive توی برنامه نويسی يه کمی معنيش فرق داره.
عزيزان اين کار امکان پذير نيست و حد اکثر کاری که ميتونيد بکنيد اين هستش که يک مدل خوب برای داده مون پيدا کنيم

mebd12

شنبه 17 مهر 1389, 20:36 عصر

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

mebd12

یک شنبه 18 مهر 1389, 09:05 صبح

خدمت دوست عزیز باید عرض کنم بله بازیابی را درست انجام میدهدچون تست نرم افزاری آن را انجام دادم با ویژوال بیسیک البته با C++‎‎ اکر از درختها و لیست پیوندی استفاده کنم سرعت تا 3برابر خواهد شد مسئله اینه توی ایران نوشتن نرم افزار فایده ای نداره امنیتی وجود نداردمن فعلا فکر فروش این اختراع هستم بعدا میخواهم کروهی تشکیل دهم برای کارهای امنیتی که با این روش انجام میشه داد . یکی از این کارها نرم افزاری برای فرستادن تصویر یا فیلم با اس ام اس که بازیابی را هم اتوماتیک انجام دهد. متاسفانه وضعیت مال من توان چنین کاری را فعلا نمی دهد خواهشا اکر برای ارتباط با کمپانی های بزرک چه ایران چه خارج راه حلی دارید به من کمک کنید . البته من در چند سایت خارجی اطلاعاتی کذاشتم ولی هیچ نتیجه ای نکرفتم .
http://www.patentauction.com/patent.php?nb=5636

esmit61

یک شنبه 18 مهر 1389, 20:32 عصر

الگوریتم توسط من بدست آمده که میتواند بی نهایت اطلاعات را روی حداکثر ده بایت ذخیره کند

این را طی ده سال تلاش برایم اثبات شده ولی قبول کردن ان برایم سخت بود چون معتاد این کار شدم حتما انجام بدهم . اکنون این را بدست آوردم
توی این 10 سال چیزی از قضایای اثبات شده نخوندید ؟

mebd12

یک شنبه 18 مهر 1389, 21:08 عصر

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

soorena

جمعه 07 آبان 1389, 11:28 صبح

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

hamidiatiye89

دوشنبه 29 آذر 1389, 08:23 صبح

سلام اگه کسی در مورد zipکردن کدهای‫در ﺑﺴﯿﺎری از ﻓﺎﯾﻞﻫﺎی ﻣﺘﻨ ، ﺗﻨﻬﺎ ﮐﺎراﮐﺘﺮﻫﺎﯾ ﻧﻮﺷﺘﻪ ﺷﺪهاﻧﺪ ﮐﻪ ﮐﺪ اﺳ‬کی
‫آنﻫﺎ ﺑﯿﻦ ٠ ﺗﺎ 127 ﻣﺤﺪود ﻣ ﺷﻮد. ﻣﺜﻞ ﻓﺎﯾﻞ ﻣﺒﺪء اﮐﺜﺮ ﺑﺮﻧﺎﻣﻪﻫﺎی ﻧﻮﺷﺘﻪ ﺷﺪه‬
‫در زﺑﺎنﻫﺎی ﻣﺨﺘﻠﻒ ﺑﺮﻧﺎﻣﻪﻧﻮﯾﺴ و ﯾﺎ دﯾگﺮ ﻣﺘﻦﻫﺎﯾ ﮐﻪ ﺷﺎﻣﻞ ﺣﺮوف ﻓﺎرﺳی‬
‫و ﻋﻼﺋﻢ ﺟﺪولﺑﻨﺪی ﻧﯿﺴﺘﻨﺪ. اﮔﺮ ﺑﻪ ﺑﺎﯾﺖﻫﺎی ذﺧﯿﺮه ﺷﺪه در اﯾﻦ ﻓﺎﯾﻞﻫﺎ ﺗﻮﺟﻪ‬
‫ﮐﻨﯿﺪ ﻣﺸﺎﻫﺪه ﻣ ﺷﻮد ﮐﻪ ﺑﻪ ﻃﻮر ﯾ ﺴﺎن ﺑﯿﺖ آﺧﺮ ﺗﻤﺎم ﺑﺎﯾﺖﻫﺎی ﻓﺎﯾﻞ ﺻﻔﺮ‬
‫روش ﺳﺎده ﺑﺮای ﻓﺸﺮدهﺳﺎزی اﯾﻨ ﻮﻧﻪ ﻓﺎﯾﻞﻫﺎ ﺣﺬف‬
‫ﺑﯿﺖ ﻫﺸﺘﻢ ﻫﺮ ﺑﺎﯾﺖ و ذﺧﯿﺮه دﻧﺒﺎﻟﻪای ﮐﻪ از ﭘﺸﺖ ﺳﺮ ﻫﻢ ﮔﺬاﺷﺘﻦ ﺑﯿﺖﻫﺎی‬
‫اول ﺗﺎ ﻫﻔﺘﻢ ﻫﺮ ﺑﺎﯾﺖ ﺑﺪﺳﺖ ﻣ آﯾﺪ اﺳﺖ. در اﯾﻦ ﺣﺎﻟﺖ ﺣﺠﻢ ﻓﺎﯾﻞ دﻗﯿﻘﺎً ٨/١‬
‫ﮐﺎﻫﺶ ﻣ ﯾﺎﺑﺪ.یه جوری باشه که بادر یافت فایل انرا فشرده کند ﺑﺎ اﯾﻦ ﻣﻔﺮوﺿﺎت میشه یک راهنمایی بکنیداز الگوریتم ممنون میشم

soorena

جمعه 03 دی 1389, 22:41 عصر

سلام
گفته شما کاملا درسته.اين کار حدوداً 12 درصد از حجم فايل کم ميکنه.
خوب اولين شرط انجام اين کار اينه که شما کار با بيت ها رو بلد باشی.ميتونی از کتابخونه هايی که تو اين
مبحث نوشته شده استفاده کنی که خيلی هم زياد هستن.من لينک يکيشو برات ميزارم.
http://maroofi.persiangig.com/bitio/bitio.html

Hossenbor

یک شنبه 26 دی 1389, 06:29 صبح

سلام خدمت دوستان عزیز ‏و Mebd12
من چند سال پیش اون موقع که نی نی بودم فکر میکردم بابیلون رو ایرانیا ساختن دلیلش دیکشنری اقا مهران بود خیلی ذوق کردم ولی بعدا که خواستم نصب کنم دیدم زبان فارسی توش نیست پیگیر شدم دیدم که در بیداری خواب شتر دیدم برای همین رفتم برنامه نویس بشم که نرم افزارهای ایرانی بسارم اگه خوبم نباشه حداقل ایرانی باشه خدا رو شکر تا حالا چندتا هم ساختم که پروژه ای رسیدم که دادهاش زیادند و مهم خواستم رو فشرده سازی کار کنم تایپک شما رو دیدم تا اخر خوندم و قبلا هم یک مقاله خوندم در مورد سیستم اعداد و قبلا یک ایده به نظرم رسیده بود اونم اینه که رو بایتها کار کنم تا اینکه این نکته یادم اومد که کامپیوتر هیچ چیز رو بجز صفر و یک نمیشناسه فکرشو بکن بگذریم خوب اقا mebd12 یکم نمیخوای تبلیغات کنی خوب چه جوری مثل کی بی جی که افیس رو فشرده کردخوب تو هم این کارو بکن ببینیم ذوق کنیم

mebd12

دوشنبه 27 دی 1389, 08:49 صبح

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

hamidhws

دوشنبه 27 دی 1389, 09:12 صبح

با سلام

به نظر بنده این تاخیر 2 دلیل داره :

1-کار کامل نشده
2-کار کامل نمیشه!

از نظر بنده پروژه ای که به ثمر برسه و تست بشه و درست انجام بشه برای ثبت 1 سال زمان نمیبره !

موفق باشید

mebd12

دوشنبه 27 دی 1389, 09:35 صبح

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

hamidhws

دوشنبه 27 دی 1389, 09:43 صبح

دوست عزیز شما این الگوریتم را روی فایل تست کردید(یا روی یه تکه بیت مثل 011010100110 )؟ تا به حال روی چتد فایل تست کردید؟ برنامه رو با چه زبونی نوشتید؟ حجم فایل هایی که تست کردید چقدر بوده؟ فایل فشرده شما در مرحله اول کم حجم میشه یا با فشرده سازی متوالی؟

با تشکر

mebd12

دوشنبه 27 دی 1389, 09:51 صبح

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

soorena

جمعه 01 بهمن 1389, 12:56 عصر

سلام آقای mebd12
آقا ما تازه رفتيم تو کار وارد کردن فلش memory از چين...رو همين حساب لطفاً اين اختراع جديدتو
الان معرفی نکن بزار جنس های ما از چين برسه بعد...چون با اين کشف جديد شما دنيا ديگه از hard ديسک و
فلش مموری بينياز ميشه چون ميتونه مثلاً بيش از 100000 فيلم رو روی يک فلاپی ديسک ذخيره کنه.
شما با اين حرکتت باعث برشکستگی چندين کارخانه سخت افزاری دنيا ميشی.مثلاً هر کسی با داشتن
يک فلش 2 گيگ ميتونه تمام فيلم هايی که تاحالا بدست بشر ساخته شده رو داشته باشه.
بزار من يه مثال برای دوستان بزنم که بهتر متوجه بشن مخصوصاً برايه کسايی مثله حميد که شما رو
مسخره ميکنن.
12 23 45 34 28 09 87 34 12 00
اين عدد ها رو ميبينيد؟؟؟؟ اين سری کامل مجموعه فوتباليست هاست.
09 56 56 07 34 34 03 44 05 56
اينا هم يک ده byte شامل 100 فيلم برتر دنيا به انتخاب IMDB هستش.
عزيزم
پسرم
برادرم
نکن اين کارتو...
من يه بار برات توضيح دادم که از نظر رياضی چيزی به اسم الگوريتم بازگشتی وجود نداره.(در بحث فشرده سازی بدون تلفات)

اصلاً بيخيال رياضی شو خودت يه کم فکر بکن...اين که هر چيزی رو بشه تو 10 byte ذخيره کرد يعنی
اينکه همچی رو هم ميشه تو 10 byte ذخيره کرد پس اين يعنی اينکه کل اطلاعات دنيا رو ميشه تو 10 byte ذخيره کرد.
اين يعنی اينکه ميشه رباتی ساخت با 10 byte حافظه ثابت که مليون ها بار از انسان باهوش تره...
تازه اين فقط يه جنبه قضيه است.خودت فکر بکن.....
نکن اين کاراتو......نکن....

mebd12

جمعه 01 بهمن 1389, 14:48 عصر

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

MahbobeSdaghat

پنج شنبه 11 فروردین 1390, 13:51 عصر

سلام
سال نو مبارک
من فقط عضو شدم که بگم که میشه فایلها را در 10 بایت فشرده کرد . بعضی از دوستان میگن فلان دانشمند اثبات کرده که اینجوریه و نمیشه و از این حرفا . اگه قرار به حرف دانشمندا باشه خیلیا هم گفتن که کار نشد نداره
من میگم اصلا به حرف این بچه ها گوش نکن . این تایپیک مهد نا امیدیه فرار کن:لبخند:
من یه سوال داشتم . می خوام بدونم این برنامه و این الگوریتمی که نوشتید حجم خودش و کدش چقدره ؟
من خودم قبلا همین ایده رو داشتم تقریبا 5 سال پیش اما واقعا باید وقت گذاشت که من نگذاشتم . ایده من اینگونه بود که مقلا یه پوشه یا یه درایو با بیش از 100 گیگ را بشه در 100کاراکتر خلاصه کرد ولی اگه متوجه بشید خواندن این حجم از هارد و فشرده کردنش خیلی طول می کشه و بد تر از همه اکستراکتش که هر بار اطلاعاتش را لازم داشته باشی باید فایل را کامل اکستراکت کرد . این اطلاعات به ذهنم اومد شاید برای شما و خیلیای دیگه مفید باشه .
1-مانند یک پوشه بشه به درون آن رفت و فقط فایل مورد نیاز را اکستراکت کرد که در این صورت سرعت خیلی بابا میاد
2-باز هم مانند پوشه بشه فایل ها را در یک محل خاص در هنگام فشرده سازی قرار داد ( مثلا در پوشه a و زیر پوشه b)
این پوشه بندی و اینا خودش حجم اشغال میکنه
آنچه که دانشمد مورد تایید دوستان گفته نمیدونم چیه ولی شاید منظورش این بوده باشه که بخاطر همین پوشه بندی ها حجم از یه سطحی پایین تر نیاد ولی ...
حرفم تموم نشده
3-این فایل فشرده بدست آمده که از حجم نهایت 1 مگابایتی خواهد داشت را بایک الگوریتم دیگر به گونه ای فشرده کنیم که 10 بایت دوستمون یا 100 کاراکتر بنده برسد
حالا برای اکستراکت چکار باید کرد ( یکی از دوستان تو همین تایپیک می گفتن : فکر می کردم که فقط من دیونه ام ولی بعد از خوندن این تایپیک فهمیدم که دیونه تر از من هم پیدا میشه ... )(برنامه نویسی همینه دیگه)
10 بایت یا 100 کاراکتر را میدیم به مثلا یه تابع و با توجه به آن این تابع یک فایل نهایتا 1 مگابایتی به ما میده که شامل کدهای فایل و فولدرهای فشرده شده هستند که به دلخواه هر کدام را که دوست داشته باشیم می توانیم در آدرس خاص اکستراکت کنیم

من شاید خیلی اینجا نیام . ولی اکثر مواقع تو forum.p30world.com هستم . شایدم یه روزی همونجا یه تایپیک برای ساخت اینجور برنامه ای درست کردم . اگه کسی حرفی داشت یا باایمیلم ( mahbobe_sdaghat@yahoo.com ) و یا تو p30world ( با یوزر MahbubeSdaghat ) می تونه ازم بپرسه
موفق و پیروز و سربلند باشید

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

باشه رفتم ... چرا می زنی حالا ... :چشمک:

afceaglee2013

پنج شنبه 11 فروردین 1390, 15:44 عصر

به قول اون دوستمون بابا اینا همشون دیوونن :لبخند: .. فکر فشرده سازی بازگشتی حدودا 9 یا 10 سال پیش به فکرم رسید چند ماهی هم رو الگوریتمش کار کردم ولی به نتیجه ای نرسیدم از طرفی هم وقتی مثلا 100 بیت رو بشه تو 99 بیت ذخیره کرد در مرحله ی اکسترکت از کجا بدونیم اون بیت صدم 0 بوده یا 1 یعنی در مرحله ای به جایی میرسیم که خروجی یک حالت 2 حالته و اینجا هست که ما قسمتی از اطلاعات رو از دست دادیم .. اینه که بعد چند ماه دیگه ولش کردم .. ولی با اینکه از نظر عقلی هیچ راهی برای برگردوندن اطلاعات نیست نمیدونم چرا متقاعد نمیشم که این روش غیر ممکنه..
ولی الان دوستمون mebd12 (http://barnamenevis.org/member.php?164699-mebd12) یه چیزی گفتن "بهم ریختن بیت ها" .. شاید بشه از این راه کاری انجام داد. با اینکه چشم آب نمیخوره ولی باز معتقدم بشه کاری کرد حالا شاید داده های تصادفی رو 100 درصد نشه فشرده کرد ولی احتمالا تا حد بالایی این روش کار برد داره ..
الان تو ایران خودمون که از نظر سطح علمی (در حالت کلی)واقعا نسبت به خیلی کشور ها پایینیم ، ( مطمئنا کسانی هم از ایران خودمون هستند که در سطح جهانی حرف های زیادی برای گفتن دارند منظورم از سطح علمی کلی ، سطح علمی افراد عادی مثل منو شما هستش ) همین ایده به ذهن چند نفر تو همین تایپیک رسیده مطمئنا به ذهن هزاران نفر هم در ایران رسیده و کارایی در این زمینه انجام دادن .. حالا همین رو در سطح جهانی در نظر بگیرید مطمئنا به ذهن برنامه نویس های نابغه ای هم رسیده و خیلی هم روش کار کردن ولی فعلا به نتیجه ای نرسیدن (شایدم ما نمیدونیم) .. و بسیاری از پیشگامان از قرار اعتقاد دارن فشرده سازی بازگشتی غیر ممکنه .. ولی با این همه فکر کنید که در طول تاریخ به چه چیز هایی غیر ممکن گفتن .. به قول یکی از فیزیکدانان بزرگ ژاپنی که در سطع جهانی شهرت دارن (اسمش یادم نیست) اختراعات و کشف های بزرگ وقتی بوجود میان که نظم نظام فعلی شکسته بشه ...
در کل به نظر من فشرده سازی بازگشتی غیر ممکن نیست و حداقل و از نظر من یه اپسیلون هم که شده امکان پیاده سازسیش وجود داره
در مورد کار دوستمون mebd12 (http://barnamenevis.org/member.php?164699-mebd12) فعلا در حد ادعا هست و چیزی برای اثبات ادعاشون وجود نداره ولی باز غیر ممکن نیست ...
من که خیلی مشتاقم ببینم برنامه ی این دوستمون واقعا اونطور که گفتن کار میکنه یا نه .. امیدوارم ایده ی ایشون واقعا کار کنه که هم جهش بزرگی در حد جهانی باشه ، هم افتخاری برای ایران و هم پول و پله ای دست خودشون برسه که معلومه بدش نمیاد از پول :چشمک: .. ولی بیشتر فکر میکنم خواستن منو شما رو سر کار بذارن ...

از دوست عزیزمون خواهش میکنم یه فیلمی چیزی از کار برنامه شون بذارن .. مثلا یه فایل رو تصادفی انتخاب کنن و اون رو فشرده کنن و بعد از فشرده سازی با یه نرم افزار آماده برای فایل اصلی و فایلی که بعد از اکسترکت به دست اومده کد MD5 بسازن .. @};-

Mehdi_FT

پنج شنبه 11 فروردین 1390, 23:08 عصر

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

mebd12

دوشنبه 15 فروردین 1390, 11:49 صبح

در پاسخ به دوست عزیز باید بگم بله زمان زیاد هستش منتها می شود با بهینه کردن تا 2مگا بایت در دقیقه در سیستم های معمولی افزایش داد. باز هم اگر سرعت هم پایین باشد استفاده زیادی خواهد شد چرا که شما اگر بتوانید حتی یک کیلوبایت را در چند بیت ذخیره کنی در تکنولوژی انتقال اطلاعات حتی بصورت سخت افزاری کارایی زیادی خواهد داشت. مثلا در سیم کارت ها که حافظه محدود دارند این روش در آنجا به صورت سخت افزاری پیاده شود چه اتفاقی می افتد بله شما می تواید یک فایل مثلا 50 کلیوبایت را در داخل ده بایت انتقال بدهی و طرف مقابل سیم کارت هم بطور اتوماتیک کل فایل باز یابی گردد . چه اتفاقی در پهنای باند می افتد آیا هیچ ترافیکی وجود دارد ؟ آیا نمی شود یک تصویر را در هزارم ثانیه انتقال داد. و یا مثال دیگر شما میتوانید یک مرورگر بوجود بیاوری که کلیه تصاویر و اطلاعات بصورت فشرده در دوطرف انتقال پیدا کند . چه اتفاقی می افتد؟ دنیای مجازی دگرگون می شود . اما حیف که سرمایه این کار ها راندارم بخاطر همین دوست گرامی در حال بازاریابی هستم . آیا به نظر شما کار به این مهمی را در هر جایی میشود ارائه داد اون هم در کشور ما که هیچ امنیت قانونی برای اختراعات وجود ندارد. بهر حال در آینده نزدیک مشخص میشود که آیا این ادعا به واقعیت هست یا نه . دوست گرامی اگر میتوانید در مورد نحوه ثبت در IEEE من را راهنمایی کنید . نکته قابل توجه دیگر هم این که نرم افزارهای فشرده سازی مثل winrar, KGB و غیره فایلهای تصویری و ویدئو را زیاد فشرده نمی کنند . و در مورد زمان هم باید بگم یک فایل 3مگا بایتی تصویری را با winrar فشرده کردم که ظرفیت فقط 5درصد کم شد و با KGB هشت درصد کم شد. اما winrar زمان کمی مصرف کرد ولی kGB در حدود یک و نیم دقیقه طول کشید. اما برنامه ای که با الگوریتم خودم پیاده شد 10 دقیقه طول کشید تا آنرا داخل چند بیت ذخیره کند.

mebd12

دوشنبه 15 فروردین 1390, 12:26 عصر

Mehdi_FT

دوشنبه 15 فروردین 1390, 13:58 عصر

سلام من به خاطر کارتون بهتون تبریک می گم
اما ببین سرعت انتقال داده اینقدر زیاد شده که یک دقیقه زمان زیادی اما ممکن روش شما بازهم قابلیت بهینه شدن را داشته باشه شاید از طریق روشهای heuristic در هرصورت چند تا نکته لازم گفته بشه:

1. ثبت روش در یک ژورنال معتبر (دقت کن با توجه کارت در کنفرانس بین المللی ثبت نکنی) اجازه می ده تا بقیه از روشت اطلاع پیدا کنند و توسعه بدهند و اگه روش مناسب باشه معروف می شی و پیامدهای آن...
2. در کل نظر من اینکه تمرکز رو روی دریافت scholarships (بورس تحصیلی) از دانشگاه معتبر بزاری تا فروش
3. بهترین راه برای اینکار اینکه بری سراغ ژورنال های معروف مثل (Springer و ..) ژورنال مرتبط با کارت توش پیدا کنی و با Editor chief این ژورنال ها صحبت کنی معمولا Email آنها را راحت پیدا می کنی تا بهت بگن باید چه کاری را انجام بدی معمولا این آدما برش زیادی در دانشگاه ها دارند و بهت کمک می کنند برای ورود به یک دانشگاه معتبر و یا فروش و راهنمایی در مورد حق کپی رایت.

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

Behrooz_CS

دوشنبه 15 فروردین 1390, 15:08 عصر

اما برای اثبات این موضوع که واقعا انجام شده یا نه یک تصویر از برنامه انجام شده گذاشتم که میتوانید مشاهده کنید در واقع با کدی که در کادر همراه با اندازه فایل ذکر شده می شود کل فایل 7745 بایتی را بازیابی کرد.68276

سلام
دوست عزیز لطفا یه فیلم از دسکتاپت بگیر و فایل را کمپرس کن بعد فایل اصلی را delete کن و بعد فایل کمپرس شده را باز کن. مثالت حتما روی یک فایل jpg باشه که وقتی uncompress کردی بازش کنی که بشه فهمید الگوریتمت درست کار کرده. از این عکس چیزی مشخص نیست. خواهش می کنم این کار رو بکن چون برای همه ما قبول کردن همچین چیزی خیلی سخته.

mebd12

دوشنبه 15 فروردین 1390, 15:19 عصر

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

Mehdi_FT

دوشنبه 15 فروردین 1390, 16:21 عصر

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

من یک سوال در مورد روشتون داشتم می خواستم ببینم درست می گم یا نه (البته انتظار ندارم توضیح واضحی بدید)

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

ممنون می شم اگه توضیح بدید.

mebd12

دوشنبه 15 فروردین 1390, 17:13 عصر

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

Mehdi_FT

چهارشنبه 17 فروردین 1390, 20:36 عصر

من روی روش شما تو این چند روز یک بررسی کردم (البته با توجه به حرفهای شما در مورد روشتون)
شما می گید که هر فایلی را شما می توانید به 10 بایت یا بیشتر (منظور یک تعداد ثابت بایت یا بیت) تبدیل کنه این روش امکان نداره به دلیل زیر:

* وقتی ما یک تعداد ثابت بیت داشته باشیم یعنی یک تعداد حالت ثابت داریم (2 به توان تعداد ثابت بیت) که اگر فرض کنیم هر حالت شما یک نوع فایل را نشان می ده پس:
یعنی ما به تعداد 2 به توان تعداد ثابت بیت می توانیم انواع فایل رو فشرده کنیم که مطمئنن این روش نمی تونه یک روش همه شمول باشه.

به نظر من حالا شما پس چیکار کردید دو حالت داره:
1.شما فشرده سازی را درست انجام نداید
در این حالت در حین فشرده سازی یکسری بیت ها رو گم کردید (مثلا به خاطر پیاده سازی بد که بعدا فکر کردید واقعا داره فشرده می کنه)
این روش منجر به تولید دو حالت می شه:
A منجر شده شما یک روش درهم سازی HASH جدید ایجاد کنید.
B منجر شده یک روش فشرده سازی پیدا کنید که یکسری داده ها را از دست می ده مثل روش فشرده سازی تصاویر.
2.شما فشرده سازی را درست انجام دادید.
در این حالت شما می توانید یکسری فایلها را فشرده کنید نه همه ی فایلها را به دلیل *

توصیه:
اگر حالت دو برای شما صادق نقاط بحرانی و حالتها را بدست بیاورید تا ببینید چه نوع ساختار فایلی را می تونید فشرده کنید.
اگر حالت B برای شما صادق سعی کنید میزان تلفات و نحوه ی آن را کنترل کنید.

موفق باشید.

mebd12

پنج شنبه 18 فروردین 1390, 17:47 عصر

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

Mehdi_FT

پنج شنبه 18 فروردین 1390, 19:05 عصر

سلام
دوست عزیز ببین روش شما مطمئنن باعث روی هم افتادگی خواهد شد منظورم چیه یک مثال می زنم

فرض کن من روشی ابداع کردم که هر فایلی را به صورت روبرو فشرده (دوبیت: اندازه فایل)

حالا با این برنامه می خوام پنج تا فایل 1000 بایتی رو فشرده کنم:

فایل یک را با نام x فشرده کردم خروجی فشرده شده مثلا می شه 1000:00
فایل دو را با نام z فشرده کردم خروجی فشرده شده مثلا می شه 1000:01
فایل سه را با نام y فشرده کردم خروجی فشرده شده مثلا می شه 1000:10
فایل چهار را با نام w فشرده کردم خروجی فشرده شده مثلا می شه 1000:11

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

حالا شما چرا با این مشکل بر نخوردی به خاطر اینکه شما آن را در 10 بایت ذخیره می کنی که این یعنی 2 به توان 80 حالت (اگه روش درست باشه) شما با توجه به تعداد محدود تست به مشکل روی هم افتادگی بر نخوردی (چون تنوع حالات زیاد است) (ببین این اصله مثل جمع دو با دو که می شه چهار)

در صورتی که برنامه تو بر روی فایلهای محدودی هم جواب بده بازم روش ارزشمندی خواهد بود

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

موفق باشید

mebd12

پنج شنبه 18 فروردین 1390, 19:18 عصر

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

Mehdi_FT

پنج شنبه 18 فروردین 1390, 23:27 عصر

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

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

2. برای ثبت مقاله در یک ژورنال معتبر شما می تونید اقدام بکنید روش به نام شما ثبت می شه و ممکن برای فروش نتونید کاری کنید (من زیاد از قانون های کپی رایت اطلاعی ندارم شایدم بشه) چون روش رو همه می فهمند.

بازم می گم سعی کنید توی نامه به شرکت های معتبر علمی صحبت کنید نه تبلیغاتی

یک مورد دیگه نمی خواد برای شرکت ها هدف تعیین کنید خودشون می دونند که باید چی کار کنند.

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

موفق باشید.

Mehdi_FT

پنج شنبه 18 فروردین 1390, 23:34 عصر

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

Mehdi_FT

پنج شنبه 18 فروردین 1390, 23:51 عصر

راستی یک چیزی بگم برای تست برنامه به نظرم لازم شاید انجام نداده باشی چند تا فایل با سایزهای مختلف و فرمت مختلف انتخاب کن سپس فشرده کن و از حالت فشرده خارج بعدش فایل بدست آمده را بیت به بیت با فایل اصلی چکش کن که مطمئن بشی هیچ بیتی از دست نمی ره.
من بودم فایلها در سایز کیلو و مگا در اندازه های عددی مختلف مثلا یک سایز با اندازه زوج یا فرد یا اول انتخاب می کردم همچین انواع مثل JPG یا فایل RAR یا فایل RAR که دوباره RAR شده باشه، TXT، DOC و ...
البته شایدم اینکار رو کرده باشی و من توصیه بیجا کرده باشم.

mebd12

جمعه 19 فروردین 1390, 10:29 صبح

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

mebd12

جمعه 19 فروردین 1390, 10:40 صبح

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

Behrooz_CS

شنبه 20 فروردین 1390, 09:26 صبح

برای بالا بردن سرعت نیازی به بافر کردن یه تعداد بایت نیست. شما همون بایت به بایت هم بخونی کافی هست
در ضمن برای بالا بردن سرعت حتما از زبان برنامه نویسی C++/C استفاده کن.

Mehdi_FT

شنبه 20 فروردین 1390, 15:32 عصر

Behrooz_CS

شنبه 20 فروردین 1390, 16:53 عصر

سلام
1. بایت به بایت خواندن مطمئنن کندتر خواهد کرد (مگه اینکه دوستمون از بایت به بایت خواندن منظور دیگه ای دارند)

مثال در C# برای خواندن یک فایل 5MB

روش یک خواندن بایت به بایت (20 ثانیه زمان) البته با توجه به کامپیوتر شخصی خودم

long T1 = DateTime.Now.Ticks;
System.IO.FileStream F = new System.IO.FileStream(@"1.pdf", System.IO.FileMode.Open, System.IO.FileAccess.Read, System.IO.FileShare.Read);
byte[] stream = new byte[F.Length];
int count=0;
while (count<F.Length)
{
stream[count] = (byte)F.ReadByte();
count++;
}
long T2 = DateTime.Now.Ticks;
MessageBox.Show((T2 - T1).ToString());

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

long T1 = DateTime.Now.Ticks;
System.IO.FileStream F = new System.IO.FileStream(@"1.pdf", System.IO.FileMode.Open, System.IO.FileAccess.Read, System.IO.FileShare.Read);
byte[] stream = new byte[F.Length];
F.Read(stream,0,Convert.ToInt32(F.Length));
long T2 = DateTime.Now.Ticks;
MessageBox.Show((T2 - T1).ToString());

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

نکته مهم هر چقدر می خوای سرعت بالاتر بره واسطه ها(منظور همان کتابخانه) را کمتر کن.

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

برای اثبات حرفم به لینک زیر یه نگاه بندازید
در ضمن وقتی از چیزی مطمئن نیستید اینقدر با اطمینان ازش حرف نزنید :
http://shootout.alioth.debian.org/u32/benchmark.php?test=all〈=all (http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=all)

Mehdi_FT

شنبه 20 فروردین 1390, 19:30 عصر

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

اینکه کاملا مشخصه که سیستم عامل کلاستری می خونه اما موقع برنامه نویسی اگه یک بایت هم بخونی مجبوره یک کلاستر رو بخونه در نتیجه خواندن بایت به بایت باعث می شه به ازای هر بایت یک کلاستر بخونه که در نتیجه زمان بیشتری می بره.

مثال شما توی C# مثال خوبی نیست چون کد شما توی IL اجرا می شه.

مقایسه من در دو روش داره از IL استفاده می کنه پس هیچ ربطی به IL نخواهد داشت.(بستر مقایسه یکسان)

در ضمن این که گفتم باید با C بنویسی دلیلش اینه که کد باینری تولید شده توسط کامپایلر فقط اگر Native باشه بیشترین سرعت را داره

مطمئنن حرف شما درسته. البته من منظورم نوع کامپایلر مثلا استفاده از کامپایلر intel به جای کامپایلر microsoft

موفق باشید.

Mehdi_FT

شنبه 20 فروردین 1390, 19:48 عصر

برای اثبات حرفم به لینک زیر یه نگاه بندازید
در ضمن وقتی از چیزی مطمئن نیستید اینقدر با اطمینان ازش حرف نزنید

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

Behrooz_CS

یک شنبه 21 فروردین 1390, 08:48 صبح

اینکه کاملا مشخصه که سیستم عامل کلاستری می خونه اما موقع برنامه نویسی اگه یک بایت هم بخونی مجبوره یک کلاستر رو بخونه در نتیجه خواندن بایت به بایت باعث می شه به ازای هر بایت یک کلاستر بخونه که در نتیجه زمان بیشتری می بره.

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

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

مطمئنن حرف شما درسته. البته من منظورم نوع کامپایلر مثلا استفاده از کامپایلر intel به جای کامپایلر microsoft
این حرف شماست :

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

باید قسمت های اصلی را با Assembly نوشت.

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

شما گفتید از C یا C++ استفاده کن من گفتم از کامپایلر بهینه تر استفاده کنید.
ایشون کدش را با VB6 نوشته می شه بگی با کدوم کامپایلری می شه سرعتش را افزایش داد تا به C++ برسه ! پس بازم به زبان ربط داره !!

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

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

Mehdi_FT

یک شنبه 21 فروردین 1390, 14:00 عصر

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

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

این حرف شما هم حرف من را تایید می کنه که گفتم با C++ بنویسید ! چون فقط توی C++ می شه وسط کد Assembly نوشت !
اگه نمی زنی توی PASCAL و زبانهای دیگه ای هم می شد و توی زبانهای ویژوال مثل Delphi هم می شه به شرطی که از INT استفاده نکنی.

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

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

soorena

سه شنبه 23 فروردین 1390, 19:16 عصر

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

Behrooz_CS

چهارشنبه 24 فروردین 1390, 10:29 صبح

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

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

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

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

afceaglee2013

چهارشنبه 24 فروردین 1390, 13:21 عصر

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

ژوپیتر

چهارشنبه 24 فروردین 1390, 14:31 عصر

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

soorena

چهارشنبه 24 فروردین 1390, 14:57 عصر

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

MahbobeSdaghat

دوشنبه 11 مهر 1390, 01:03 صبح

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

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

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

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

soorena

جمعه 15 مهر 1390, 23:50 عصر

سلام
اول از همه اينکه من اسمم سورنا هستش همون طور که از ايدی هم مشخص هستش.
دوم اينکه چون از نرم افزار فينگيليش به فارسی استفاده ميکنم شرمنده اگه نوشته هام غلط املا يی داره.
خوب حالا ميرسيم به بحث اصليمون:
اول اينکه آقای 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
http://barnamenevis.org/showthread.php?298809-%D8%A7%D9%84%DA%AF%D9%88%D8%B1%D9%8A%D8%AA%D9%85-%D9%81%D8%B4%D8%B1%D8%AF%D9%87-%D8%B3%D8%A7%D8%B2%DB%8C
ضمناً winrar خانوم نيست آقاست و اصلاً هم جزو نرم افزار های قوی محسوب نميشه.

Cancer

یک شنبه 17 مهر 1390, 13:12 عصر

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

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

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

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

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

mebd12

چهارشنبه 04 آبان 1390, 22:25 عصر

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

soorena

پنج شنبه 05 آبان 1390, 17:37 عصر

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

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

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

mebd12

پنج شنبه 05 آبان 1390, 18:42 عصر

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

powerboy2988

پنج شنبه 17 آذر 1390, 23:36 عصر

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

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

ممنون...

hamidhws

سه شنبه 06 دی 1390, 20:08 عصر

با سلام

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

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

جناب mebd12 (http://barnamenevis.org/member.php?164699-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

پنج شنبه 08 دی 1390, 20:16 عصر

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

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

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

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

hamidhws

جمعه 09 دی 1390, 10:20 صبح

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

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

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

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

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

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

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

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

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

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

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

soorena

جمعه 09 دی 1390, 12:07 عصر

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

جمعه 09 دی 1390, 12:50 عصر

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

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

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

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

soorena

جمعه 09 دی 1390, 19:52 عصر

سلام

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

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

hamidhws

جمعه 09 دی 1390, 23:48 عصر

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

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

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

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

soorena

شنبه 10 دی 1390, 00:00 صبح

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

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

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

http://www.maroofi.persiangig.com

perysa

چهارشنبه 11 بهمن 1391, 19:24 عصر

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

soorena

پنج شنبه 12 بهمن 1391, 15:36 عصر

سلام

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

یوسف زالی

سه شنبه 01 اسفند 1391, 01:10 صبح

FastCode

سه شنبه 01 اسفند 1391, 02:03 صبح

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

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

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

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

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

یوسف زالی

سه شنبه 01 اسفند 1391, 09:59 صبح

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

soorena

پنج شنبه 03 اسفند 1391, 11:59 صبح

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

the king

پنج شنبه 03 اسفند 1391, 15:48 عصر

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

abol122

شنبه 26 اسفند 1391, 10:36 صبح

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

farid_new

شنبه 26 اسفند 1391, 10:46 صبح

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

FastCode

شنبه 26 اسفند 1391, 10:59 صبح

دوستان سلام
میخواستم بدونم قیمت الگوریتم فشورده سازی در سه حالت تقریبی 25و50و75 در صد بدون دونستن نوع فایل چقدر است؟(در ضمن زمان استاندارد مورد نیاز چقدر است)
بدون دونستن نوع فایل غیر ممکنه.
دو تا شرکت هستن که jpg و mp3 رو فشرده میکنن.
یکی هم هست که با درصد خیلی کمتر از چیزی که گفتید همه چیز رو فشرده میکنه.
۷۵ هم به جز فایلهای متنی یا enteropy خیلی کم غیر ممکنه.

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

abol122

شنبه 26 اسفند 1391, 13:25 عصر

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

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

FastCode

شنبه 26 اسفند 1391, 16:22 عصر

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

abol122

شنبه 26 اسفند 1391, 17:42 عصر

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

FastCode

شنبه 26 اسفند 1391, 18:07 عصر

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

abol122

شنبه 26 اسفند 1391, 19:23 عصر

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

یوسف زالی

شنبه 26 اسفند 1391, 21:11 عصر

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

abol122

شنبه 26 اسفند 1391, 21:47 عصر

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

soorena

یک شنبه 27 اسفند 1391, 16:13 عصر

سلام

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

3ddisplay

سه شنبه 29 مهر 1393, 21:17 عصر

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