Не сме като онзи свещеник в градската легенда за френския език, дето измислил писмената форма на езика под влиянието на тънкия момент че му плащали за написан символ.

Любимият ми френски спелинг е:

Jacqueline (10) vs Жаклин (6)

Има и с по-голям коефициент на "компресия"
renault - рено (7/4)
peugeot - пежо (7/4)

Не съм споменал двоично дърво. Само показах, че представянето на число като база и степен, заема по-малко памет, от записа на самото число.
...

Спомена по-горе. Примера с името на премиера е честотен анализ. И след това представянето на символите в зависимост от честотите е двоично дърво

Въпрос:
Ако входните данни (текста,числото и т.н.) са бял шум - Абсолютно случайни битове и равномерно разпределени - ще може ли това да се смачка?

Според мен не.
И колко числа са именно такива - изглеждат като шум.
Сега тънкият момент е че ако успееш да видиш (или намериш) някъкъв патън, някакъв излишък от информация, някаква структура в този шум
то явно и той може да се смачка.

например може да се успее да се разложи едно число на някакви коефиценти.....Ама да не се укаже че в общият случай - за случайно избрани числа, групичката от тези коефиценти ще се получи точно толкова дълга колкото и оригиналното число?

Според мен би трябвало да може да се компресира. Иначе въпроса с изходния текст и неговата дължина е резонен. И аз си мисля че ще има входни текстове, които няма да може да се представят с по-къс изходящ текст, но не мисля че това ще зависи от ентропията. Защото ние дискутираме просто различно представяне на входящия тескт. И факта че (понякога) изходния текст ще е по-къс от входния т.е. ще имаме форма на компресия не зависи (според мен) е само страничен ефект от метода на представянето
И ако се върнем на алегорията на gat3way за компресирането не трябва да забравяме че ние внасяме енергия в системата и по този начин променяме (в една или друга посока) ентропията на изследваната система

[2]

Славянските езици в писмена форма на кирилица имат доста по-висока ентропия от английския, едно защото азбуката описва почти всеки звук и две защото по принцип не си позволяваме излишъци. Не сме като онзи свещеник в градската легенда за френския език, дето измислил писмената форма на езика под влиянието на тънкия момент че му плащали за написан символ.

Въпреки че тази цялата схема със степените ако се окаже работеща, не виждам какво общо има изобщо с ентропията на входните данни, то това е забавното в цялата работа.

Аз отворих сума за ентропията, защото по-горе 4096bits отвори дума за двоично дърво и честотен анализ на текста. Иначе да, наистина няма нищо общо с метода, който мислим

Целия интернет, като обем информация, на теория може да се събере така на няколко реда или страница. Затова в предни постове споменах за Народната библиотека на две дискети.

Излишъка от информация при обикновенният език е доста голям. За Аглийският език сметките бяха, че количеството информация е около 2 бита на буква.

Т.е. ако една буква се кодира в ASCII (127) това са 7бита.
максималната компресия която теоретично може да се постигне тогава ще бъде 7/2 = 3.5

по спомени е 5 и нещо бита на буква (английския), но това би имало значение само ако искаме предварително да обработим входящия текст за да намалим дължината му

Работеща е и ентропията няма никакво значение.

Работеща е ако можеш да се справиш с факторизация на големи числа (в обозримо време). Ама тогава ще можеш директно да разбиваш (примерно) RSA ключове

То това ще се наложи, най-малкото защото изчислителните ни възможности не са безкрайни.

Аз също и не съм убеден че е добра стратегия да ходим в крайности с прекалено голям брой прости числа, които да повдигаме на степен (че и да стигнем до толкова големи, че да не са "открити" още). Определено ще се появят проблеми с това и те са свързани с начина по който кодираме "не вземай предвид тази степен". Дори само един бит да е достатъчен за целта (а аз не виждам как ще стане това лесно) - разхищенията въобще няма да са малки. Далеч по-изгодно става да описваш по-големи степени, отколкото да описваш много прости числа, чиято степен не вземаш предвид.

Не знам дали един бит ще е достатъчно място за такъв флаг.  И аз се притеснявам повече за разделителя между степените, защото него ще трябва да го ползваме независимо дали има степен или не.
А ако вземем идеята ти за многовариантността можем да подберем големи степени на големи числа, което си мисля че ще съкрати тоталната дължина на изходния текст

Правилно! Записването на почти което и да е число като база и степен, заема по-малко памет, отколкото записа на самото число. Това е така дори за сравнително малки числа, като например 36. Което се представя двоично със 100100. Ако е със база и степен 110 10. Бит по-малко. Това е и идеята по-общо.
Употребата на прости числа се налага от самосебе си, но аз не мога да го обясня, така, че да ми допадне обяснението на мен самия, въпреки, че разбираз причината. Нямам знанията и езика за това.
....

Хм, трябва много да внимаваш с честотния анализ и разбиването на двоично дърво. Такова прекодиране може да има доста негативен резултат ако го прилагаш върху данни с голяма ентропия. Може примерно да се наложи да ползваш 13-14 бита за да кодираш текст от 100 символа вместо 7 бита константен размер.

[BG]

....
обаче все още се чудя как да ги записвам номерата - с префикса отпред BG123456789 DE123456789 или да ги сложа като суфикс  123456789BG 123456789DE

щото ако е отпред индекса ще е страшно неефективен. ще имам 99% BG123456789 и само тук таме някой западен номер.
....

Ами аз лично бих заложил на BG123.... защото това е формата на VIES. Не че нещо проблем при нужда да се генерира, но щом така и така ще трябва да имаш колона за страна и друга за номер вместо да ползваш композитен индекс да си ползваш обикновен (ако имаш нужда от индексиране де)

....
От друга страна са много по-трудни за генериране (е добре може да ползваш таблица с вече известните прости числа, но все пак имаш ограничение след което незнаеш следващото поред просто числа защото все още никой не го е открил)

Предполагам че нарастват по-бързо от степените на 2 но пък и предполагам можеш да измислиш друга редица, която нараства още по-бързо (незнам, примерно N**N**N**N...**N (N пъти) ) но къде е златния момент където една редица започва да нараства прекалено бързо за да е полезна, и къде е прекалено бавна - незнам.

Иначе да - трябва да е унифицирано представянето за това не споря.

Не мисля че са толкова трудни и ще се наложи да се ползват наистина големи числа. То това е и идеята на степените, да може да се генерира голямо число, което да има нужда от кратко "представяне" (запис). Иначе не знам от къде ми дойде идеята да са прости числа

Е как, и да не го е открил, ще циклиш числа нагоре и ще ги тестваш дали са прости, примерно с miller-rabin. Но това е прекалено теоретично - значи ако стигнеш дотам да ползваш толкова големи прости числа, че още никой да не ги е открил, значи ще имаш далеч по-големи проблем после да ги степенуваш така или иначе.

Ох, опрем ли до големи числа май ще е по-рационално просто да разрежем входния текст на приемливи по размер парчета, което да превръщаме индивидуално

Мне, степени на две са ти бинарното число. Докато аз искам да играя с прости числа ( и неограничено число за степен).

Добре де но какво е предимството на простите числа в този случай. Те са точно толкова на брой колкото и Естествените числа и в този контекст не са с нищо по-специални (виж ако беше разлагане на прости множители е друго, но при полиномите не виждам с какво са по-различни от кои да е други цели изброими положителни числа - примерно степените на 2)
...

Дребното предимство е че изрязвам голяма част от многовариантността и имам уникалност на основите. Освен това скоростта на нарастване на простите числа е по-голяма.
Вярно е че има варианти и за по-къси записи. Например 18446744073709551615 има доста къс запис (2⁶⁴-1)
Но крайната идея е да имаме унифициран метод за запис, който да е много по-кратък (статистически)

...
В смисъл аз поне много обичам да си обяснявам нещата с аналогии, а не съм физик за да правя точно такива аналогии, но пък и не се сещам за някаква по-добра в момента, така че се извинявам ако цялото това изглежда доста нелепо.

Ти изби рибата и разката мамата на ентропията .
Иначе има добра идея в думите ти (аз също не съм физик). Но в горната идея (според мен) не играем с ентропия въобще. Ние просто сменяме представянето на числото (входящия текст). И се опитваме да намерим такова представяне, което да може да се представи с много по-малко симвили (и наричаме това компресия).

това TIN явно е за физическите лица. в страницата има линк за проверка online check module  и там нашите ЕГН-та минават но не и булстатите.


а пък тука
http://ec.europa.eu/taxation_customs/vies/ минават бултатите но само на регистрираните по ДДС фирми а другите булстати на нерегистрираните ги изхвърля.

Не само регистрираните по ДДС. Трябва да са регистрирани и по ВИЕС (по спомени имаше такава особеност)

Ето нещо от сайта на ЕО: http://ec.europa.eu/taxation_customs/taxation/tax_cooperation/mutual_assistance/tin/index_en.htm

Виждам и още един проблем, но той е с представянето и не е огромен. За да има задачата решение, ще трябва да позволим нулевата степен, тоест да добавяме 1. В противен случай много лесно мога да дам примери за числа, които не могат да се разложат на сбор от степенувани прости числа. Но ще трябва да измислим и как да кодираме нулева степен и как да кодираме "степен която не вземаме предвид",

Мда, може да имаме 2**1+3**0+0*(5**0)+7**2 (само пример)
Но това е малка грижа, само пакетиране. Също трябва да се помисли и за разделителя между степените

...

А не е ли ключа от бараката в остатъка +y

....

Към остатъка можем да приложим същия алгоритъм докато получим остатък < от най-високата степен. Което ще е приемливо за съхранение

Дам, ясно е къде е разминаването.

Значи все пак остава проблема с намирането на въпросните степени. Всъщност, за да е по-забавно, според мен с голяма вероятност тази задача има повече от едно решение и на нас ни трябва най-оптималното.

О, да, това с повече от едно решение е вярно. Но си мисля че е малко вероятно. И (си мисля) най-оптималното (от гледна точка на изходния текст) е да се търси такова с максимална степен в най-старшите степени. Така ще се намалят степените на младшите степени

Мне, степени на две са ти бинарното число. Докато аз искам да играя с прости числа ( и неограничено число за степен).
Аз ползвах bc:

Код:

2^1001+3^1002+5^1003+7^1004
30090691925576896817762391525509448290021291652694477976838515130578\
50401758032175543096625694980013524398768228433773781226754037108985\
17651059802804979798484768641976994743857560231992664435245802456382\
24952238359797965144201922557281638378500540605675478022200061990959\
73912866172604361235340039603572959111685943913091130339534177547013\
17843801520417515248539351050470639392268748190736100952871290555680\
91121435476459597060793717288212898190929204165393698894492370374504\
21096019618874106997455906221489617420153364251120374225290721015378\
73657660270761184997490019018360201880218486096430110214122064160885\
68746471420401373365626640199969463405839927493038591480628621739250\
54881655693817009942449102429948644377952846221222565802991556417518\
72970391706917530334627032421438448735142261070333009765236602176970\
314664389375273450412548052549287

Може да го опростим още, да търсим полином от вида Н = 2^x + y

....

Ако го опростиш няма да получиш (в големия процент от случаи) "компресия". Но ако го разтегнеш за всички възможни степени и запазиш само степените (си мисля) че ще има голяма ползва. Е, остава въпроса с (по един или друг начин) разделяне на число на прости множители, което за големи числа си е проблем.
Примерно (генерирал съм си го)
300906919255768968177623915255094482900212916526944779768385151305785040175803217554309662569498001352439876822843377378122675403710898517651059802804979798484768641976994743857560231992664435245802456382249522383597979651442019225572816383785005406056754780222000619909597391286617260436123534003960357295911168594391309113033953417754701317843801520417515248539351050470639392268748190736100952871290555680911214354764595970607937172882128981909292041653936988944923703745042109601961887410699745590622148961742015336425112037422529072101537873657660270761184997490019018360201880218486096430110214122064160885687464714204013733656266401999694634058399274930385914806286217392505488165569381700994244910242994864437795284622122256580299155641751872970391706917530334627032421438448735142261070333009765236602176970314664389375273450412548052549287

се запазва като (десетични числа)
1001,1002,1003,1004
което прави компресия 19/850=1:50. Ако се компресира записа на степените под формата на двоични числа ще заеме 4*2 байта + 3 разделителя  (по байт) = 11 байта, докато числото в двоичен вид = 10^850 ~ 2^2550 = 318 байта, което си е почти 1:30 компресия