Дайте идея

имам поредица от 33 цифри, които могат и да се разделят да отделни групи
aabbccddeeffffggghhiiiijjjkllmmnn. всяка група си има максимално допустима стойност.
00<=aa<=23
00<=bb<=59
00<=cc<=59
00<=dd<=90
00<=ee<=59
0000<=ffff<=9999
000<=ggg<=180
000<=hh<=59
0000<=iiii<=9999
000<=sss<=200
0<=k<=9
00<=ll<=31
00<=mm<=12
00<=nn<=20

та въпроса е как тази поредица от 33 цифри (или 14 групи) да я запиша във възможно най-малко памет

за сега съм се сетил за... абе няма да казвам да не ви влияе на мисленето (пък и не е нищо кой знае колко умно)

Kvo shte kajesh za tova:
nn + mm * 21 + ll * 13 * 21 ...... (vsyaka grupa se umnojava po proizvedenieto na vsichki max st-ti (+1) na poleta do tozi moment. Poluchava se edno golyamo chislo: LN

Posle sa extractvat taka:

nn = LN % 21
mm = (LN / 21) % 13
i t.n.t.

Ako predpochitash:
LN =(... ((aa * 60 + bb) * 60 + cc ) * 91 + dd) * 60 + .....) * 21 + nn

extraction formulata e sashtata.

това е решение, но не спестява кой знае колко :(

може би ако се избере подходяща подредба на групите ще се получи по-малко число

ne "moje bi"! to si e napravo sigurno :)

Klasicheskia variant e da se vidi v kolko bita se subira vsiako chislo - naprimer:
23 - 5 bita
59 - 6 bita
90 - 7 bita i t.n.
Sledva slepvaneto na bitovete v edna dulga poredica, koiato se predstavia kato bytes, words ili kvoto ti kefne.
v sluchaia:
23 -> 10111
59 -> 111011
90 -> 1011010
10111+111011+1011010 -> 10111111 01110110 10 (ostavat 6 bita i t.n.)
sigurno ima i po-zabavni varianti, ma toia mi se vizda nai-prost

чети и дишай по-леко

Tova koeto dade FP kato otgovor dawa naj-kompaktnoto reshenie i winagi edin i susht rate na "kompresia" (abe ne e kompresia ama me razbirate).

Sushsit nachin az izpolzwam w moja speech engine da pazja okolo 20000 speech-file koito se tursjat po razlichni kljuchove - i gledam tezi kljuchove da zaemat minimalno mjasto - i tochno taka, katko FP napravih :)....

Ako ima njakoj spec po entropiata - mozhe bi toj shte ti pomogne da napravish analiz koi stojnosti na kljuchovete se sresthat naj-chesto/malko - ili da premahnesh po njakakuw nachin nevuzmozhnite kombinatzzii - no ne znam tova tochno kak stava...

Naprimer jasno e che za DEN 31 i MESETZ 2 (Fewruari) - tova ne e wuzmozhno
i wmesto kljucha ti za data/mesetz (ot 0 zapochwam, ne ot 1)

dd/mm (0..30, 0..11) -> key = 31 * mesetz + day, maximalnia ti kljuch e - 31*11 + 30 = 371, No ako wmesto data/mesetz zapiswash prosto den ot godinata togava maximalnia ti kljuch shte e 365/366 - spestjawash malko (nagledno s tozi primer ne spestjawash bitove, a chast ot bita - no ako imash i ot drugade entropia - mozhe i da spestish poveche). Problema sus 365/366 e che trjabwa da zapishesh i data i da proverish dali e wisokosna ili ne - i po tova da opredelish tochno denja si (zaradi 29 Fewruari)

tirulirutatuutuu

Tozi metod dava po-loshi rezultati ot aritmetichniya. (vapreki che po-chesto se izpolzva). (izpolzva se po-chesto, zashtoto se realizira po-lesno i raboti po-barzo)

Hihihi, mi az mai kazah "klasicheski"... Puk moze da razbirame "klasika" po razlichen nachin, to si e normalno.

чети и дишай по-леко

Това е типична задача за кодиране на информация, т.е. първо определяш keyspace-а на възможните стойности чиято последователност ще кодираш. И си правиш някакъв кодиращ engine, който знае колкото се може повече за информацията, която ще кодираш (точно това е ентропийния анализ за който ти спомена Malkia
Мисля, че теоретичния максимум на компресия може да постигнеш ако разглеждаш целия 33 цифрен стринг като един символ, направиш хъфманов речник на голямо множество от такива 33-цифрени поредици и след това при всеки конкретен случай правиш хъфманова компресия на данните, която става за една стъпка, щото всички възможни стойности са ти в таблицата. Естествено на практика няма да можеш да използваш този метод с такъв голям символ, а ще трябва да разделиш стринга на някакви символи, но не е задължително това да са aa, bb, cc.., които са написани. Може да е по-добре да се разглеждат някакви комбинации например aabb, ccdd, eeffff, и.т.н. При всички случаи обаче този, който ще мисли алгоритъма трябва да има допълнителна информация за това какво точно представляват данните които се кодират. Накратко - хъфманова компресия на стринга след като е подбрано множеството от символи, които се кодират.
И още нещо ако всеки бит е ценен, то в съм виждал поне 2 USA компании които срещу заплащане по дадени от клиента правят анализ на данните и разработват подходящ алгоритъм за компресия.

Безсмислено е да разглеждаш общия вид на поредицата. Трябва да си направиш извадка от много такива стрингове и да ги разглеждаш тях.

Ako se trygne po nachina na na FP se poluchawat 93 bita, koito ako zakryglim do 96, sa 12 bajta (ne sym chuwal njakoj da prawi problem za 3 bita, ama znae li chovek).

Ako priemem che poredicata e 33 cifreno desetichno chislo, togawa brojat na bitowete shte e 33/0.31=106.45, koeto shte zakryglim na 112, koeto e 14 bajta i e po-losho.

Ako broim bitowe, kakto predlaga Pechenia, togawa poluchawame 98 bita, koeto shte trjabwa da zakryglim na 104, koeto e 13 bajta.

Izglezda che 12 bajta e minimuma, ako ne se pribjagwa do po-slozni nachini.

Благодаря на всички! Ама много!