Upakowanie danych do stringa

Cześć,

Problem dotyczy kwestii kodowania formularza do prostego ciągu znaków.

Wyobraźmy sobie, że mamy tablicę z danymi: w pierwszej kolumnie bedą liczby od 1 do 3000 będą to liczby którym przyporządkowano jakieś produkty, w drugiej kolumnie liczby od 1 do 200 - czyli ilość jaką może zamówić klient.

Zatem zamówienie dokonane przez klienta będzie w formie ciągu liczb np.:

0001 100 0022 200 1000 002

co oznacza, że
produkt z katalogu o symbolu :

0001 jest zamówiony w ilości 100 sztuk,
0022 jest zamówiony w ilości 200 sztuk,
1000 jest zamówiony w ilości 2 sztuk,

Teraz pytanie:

Jak upakować to do takiej formy, żeby klientowi wyświetlił się kod zakupów w formie o wiele krótszej, np. :

A7X77B

Chodzi o to, że klient po złożeniu zamówienia u siebie w komputerze mógłby za pomocą np. telefonu podać kod zakupow, a ja ten kod odkoduje i zreal;izuje zamówienie..

Sory, że tak szczegółowo to opisałem ale chciałem, żeby to było w miare czytelne..

Ma ktoś jakieś propozycje?

Dzięki

Znajdz se jakis komponent to pakowania stringow i viola. Na torry.net widzialem kilka.

Przy każdym zamówieniu zwiększaj o 1 jakiś licznik (przechowywany np. w pliku) i ślesz go klientowi.

// Dopisane
A czy ja mówię coś o wysyłaniu pliku przez telefon? Plik ma być na kompie z bazą danych, po to, żeby po restarcie aplikacji pamiętało ostatni numer zamówienia i przy kolejnym zamówieniu podawało już następny. A przez telefon możesz powiedzieć słownie, albo dodać do programu obsługę modemu i niech jakieś nagranie mówi.

hmm, tylko jak przyślę ten plik przez telefon ??? ;)
czyżbym w poście zapomniał napisać, że ten string ma być przesyłany za pomocą... telefonu?

jak masz bazę danych zakupów to robisz dla takowego zakupu unikalny kod zakupu (8 znaków, możliwości znaków to duże litery alfabetu łacińskiego + liczby w systemie dziesiętnym bez zera (bo ludziom trudno odróżnić 0 od O w niektórych czcionkach)) jak masz już takie coś zrobione to przez telefon podać takie coś nie problem, wyszukać to w bazie też nie problem... no i gdzie problem? i po co w ogóle kompresowac string, jak mozna spokojnie na podstawie unikatowego kodu zakupu identyfikowac to wszystko, obsługiwać zamówienia... cały problem zostaje spalony prostym rozwiązaniem.

obawiam się, że się nie rozumiemy szanowny panie hakger :)

chodzi o to, że każdemu towarowi został przyporządkowany unikatowy, 4-cyfrowy numer. ilość różnych produktów będzie powiedzmy 3000. klient może kupić od 0 do 200 sztuk z każdego produktu.

Zatem gdyby założyć, że kupi po 100 sztuk z każdego produktu, ciąg znaków zamówienia wyglądałby następująco:

0001 100 0002 100 0003 100 0004 100 itd. aż do 3000.

Pomyślałem, że może jest jakiś sposób zapisać taki ciąg liczb do bardzo krótkiej postaci max 12 cyfrowo-literowej. Jeżeli to jest w ogóle możliwe, klient dokonawszy zamówienia na swoim komputerze (nie mający dostępu do sieci) odczytuje taki kod - symbol zamówienia, następnie dzwoni do sklepu i podaje właśnie ten symbol. Taka czynność potrwałaby 20 do 30 sekund, natomiast złożenie zamówienia przez telefon i podawanie nazwy towaru oraz jego ilości (w założeniu, że nadal chciałby kupić 3000 pozycji) potrwałaby pewnie od śniadania do obiadu.. :)

Mam nadzieję, że tym razem trochę lepiej wyjaśniłem problem

Napisałeś, że produktów jest 3000 - przyjąłem dla pełnego wykorzystania 12 bitów, że może ich być 4096. Pozostałe 4 bity wykorzystam w następujący sposób:

jeśli będę chciał kupić od 1 do 15 produktów o numerze 1234 (4D2h) to będą to 2 bajty:
x4D2 - gdzie x - 1..f

jeśli będę chciał kupić od 16 do 271 produktów o numerze 1234 (4D2h) to będą to 3 bajty:
04D2yy - gdzie yy - 00..ff (00 = 16 produktów, ff = 271 produktów)

jeśli będę chciał kupić ponad 271 produktów o numerze 1234 (4D2h) to będą to Nx3 bajty + ewentualnie 2:

np. chcę kupić 857 produktów 4D2h:
04D2ff 04D2ff 04D2ff 04D22C

a jeśli np. 821 to:
04D2ff 04D2ff 04D2ff 84D2

teraz można to przepuścić przez mime64/base64 - każde 3 bajty zamienią się na 4 znaki [a-zA-Z0-9+/] i ewentualnie '=' na końcu

Wg mnie ciężko będzie osiągnąć krótszy ciąg.
To takie nocne przemyślenia o 5:25 nad ranem :)

ale wiecie, że gdyby był na to sposób to jest nobel?

kiedyś myślałem że można by zrobić coś takiego:

układ współrzędnych. na nim proste wychodzące z początku układu pod różnymi kątami na I ćwiartce. na osi x dać pozycje katalogową a na osi y ilość zamawianych sztuk. dane punkty umieszczać na wspomnianych prostych ( o znanym nachyleniu) po nałożeniu na takich prostych punktów utworzy się wielobok płaski. oczywiście dla maszyny proces rozlokowania takich punktów nie był by żafdnym problemem.

Teraz można by założyć, że każdy wielobok płaski posiada grubość nieskończenie małą lub tworzy coś o stałej gęstości. Na podstawie znanych współrzędnych tego wieloboku jesteśmy (program komputerowy( w stanie szybko wyznaczyć środek masy tego czegoś - jako koordynaty czyli podać x i y. te dwa punkty powinny opisać wszystkie dane wierzchołków. Założenie jest takie, że zmiana dowolnego położenia wierzchołka ma wpływ na koordynaty XY symbolu wyjściowego, ponieważ te wierzchołki nie mogą się swobodnie poruszać tylko każdy z nich ma ograniczenie funkcji liniowej pod jakim kątem może zmieniać swoje wartości..

i jak? było by co z tego ?

Na podstawie znanych współrzędnych tego wieloboku jesteśmy (program komputerowy( w stanie szybko wyznaczyć środek masy tego czegoś - jako koordynaty czyli podać x i y. te dwa punkty powinny opisać wszystkie dane wierzchołków.

po pierwsze - X,Y to jeden punkt, a nie dwa, po drugie wiele różnych figur ma środek geometryczny (środek "ciężkości") w tym samym miejscu. więc bez jaj. :|

jesteś w błędzie mój przyjacielu, ponieważ wierzchołki na których będą położone punkty będą ograaniczone funkcjami. czyli ograniczone zostaną stopnie swobody przemieszczania się tych punktów. chyba nie wziąłeś tego pod uwagę...

KERMI normalnie jak to przeczytalem to az mi sie spodobalo ale o ile dosc latwo bedzie to zapisac (tak mi sie na razie wydaje :) ) to jaki masz pomysl na odczytanie tego? Ale tak moze ciut dokladniej niz tylko mam punkty x i y i odczytuje :)

kod produktu 4 cyfry, ilość 3 cyfry czyli potrzebujesz 23bity na jeden towar, towarów możesz miec do 9999 (4 cyfry), wiec 23*10000=23kB a to jest tylko 23000 znaków ASCII sorry, ale jak każesz klientowi recytować taki ciąg przez telefon...
a co do figury, moga być dwie taki które mają rózne wierzchołki (może też rózną ilość) i będę miały srodek w tym samym miejscu. musiałbyś wiec dodatkowo przesyłać przynajmniej ilośąć wierzchołków albo jeszcze jakieś dodatkowe dane. Ake pewnie w sumie wyszłoby też 23KB po prostu żeby zakodować dwie ró.zne info trzeba mieć dwa satny, 4 - cztery stany bądź 2x2, tego nie przeskoczysz :(

co do pierwszej części twojego postu, to niestety :( masz rację..
z drugą częścią jesteś w błędzie bo nie wziąłeś pod uwagę tego, że wierzchołki nie mogły by być rozrzucane po pierwszej ćwiartce chaotycznie tylko musiały by mieś dokładnie jeden stopień swobody - ograniczone przez dowolną funkcję najlepiej nieliniową i już.

pozdrawiam

KERMI normalnie wszystko super ale wez napisz moze jak bys to odczytal majac dane tylko x i y? :) Ja troche nad tym myslalem i nic :-/

hej, z przykrością muszę stwierdzić, że chciałbym - ale nie wiem jak odczytać poszczególne xy, nie no - na pewno jest prosta (matematyczna) metoda odczytu koordynatów.

Problem w tym, że jak w takie coś będziemy chcieli wsadzić dużo danych (wierzchołków) to układ obrazowo będzie zwiększał swoja rozdzielczość.. :( i x i y będą długimi liczbami...

prawda?

ponieważ wierzchołki na których będą położone punkty będą ograaniczone funkcjami. czyli ograniczone zostaną stopnie swobody przemieszczania się tych punktów.

Mi sie wydaje, że te same wierzchołki można uzyskać róznymi funkcjami, a że bęzdie ich własciwie nieskończenie wiele, to to ograniczenie też będzie dość cienkie :(

co do pierwszej części twojego postu, to niestety :( masz rację..
z drugą częścią jesteś w błędzie bo nie wziąłeś pod uwagę tego, że wierzchołki nie mogły by być rozrzucane po pierwszej ćwiartce chaotycznie tylko musiały by mieś dokładnie jeden stopień swobody - ograniczone przez dowolną funkcję najlepiej nieliniową i już.

popatrz na to logicznie - skoro mam rację co do pierwszej częsci to te dane będą zajmować 23KB
skoro nie mam racji co drugiej części to można te dane odwzorowac za pomocą jednego x i jednego y. czyli dwóch zmiennych. Jeśli obie będą miały nawet long double, to w sumie zajmą 20bajtów.
wniosek z tego taki, że 23kB możesz jednoznacznieodwzorować w 20 bajtach
to ponad 1000krotna kompresja danych przecież.
Wyobraź sobie teraz taki filmik na DVD - 4giga -> stosując ten system kompresji zajmowałby 4M!!!!
Nawet jeśli komp musiałby go najpierw przez tydzień dekompresować to i tak rewelacja.
A spróbujmy spakować te 4MB jeszcze bardziej, o kloejne 1000 razy - już zajmuje tylko 4KB, jeszcze raz -> 20 bajtów.

Z tego wynika, ze dowolną informacje da sie spakować w 20 bajtów. ale to tylko 2⁸20 czyli 2^{160 czyli ok. 10}48 różnych informacji.
a co z całą resztą???

Ja kiedyś popełniłem podobny błąd - testowałem, testowałem i ciągle mi wychodziło, że w 31 bitach da się zmieścić 32. dopiero po długim czasie odkryłem błąd. I baaaardzo sie zawiodłem :(

Wyobraź sobie teraz taki filmik na DVD - 4giga -> stosując ten system kompresji zajmowałby 4M!!!!

Nieprawda, bo coś pod 5 MB. 4 GB to 41024 MB, a nie 41000 MB :-P

Z tego wynika, ze dowolną informacje da sie spakować w 20 bajtów.

Eee, na pewno nie. Założę się, że znalazłoby się wiele różnych plików, które po takiej kompresji wyglądałyby identycznie.

szybko wyznaczyć środek masy tego czegoś - jako koordynaty czyli podać x i y. te dwa punkty powinny opisać wszystkie dane wierzchołków. Założenie jest takie, że zmiana dowolnego położenia wierzchołka ma wpływ na koordynaty XY symbolu wyjściowego, ponieważ te wierzchołki nie mogą się swobodnie poruszać tylko każdy z nich ma ograniczenie funkcji liniowej pod jakim kątem może zmieniać swoje wartości..

1. Nie każdy trójkąt jest równoboczny... Wiele figur może mieć w tym samym miejscu środek ciężkości... Wystarczy tylko tak je dobrać, żeby wierzchołki wypadły gdzieś w zbiorze wartości którejkolwiek z tych funkcji liniowych...

2. Każdą informację można zakodować do 20bajtów... :| Zapominasz o tym, że trzeba też zakodować matrycę (te linie), i że double float nie zawsze wystarczy.
   <font color="blue">[</span><font color="red">ADD</span><font color="blue">]</span>

Wyobraź sobie teraz taki filmik na DVD - 4giga -> stosując ten system kompresji zajmowałby 4M
(...) A spróbujmy spakować te 4MB jeszcze bardziej, o kloejne 1000 razy - już zajmuje tylko 4KB, jeszcze raz -> 20 bajtów.
Z tego wynika, ze dowolną informacje da się spakować w 20 bajtów. ale to tylko 2⁸20 czyli 2^{160 czyli ok. 10}48 różnych informacji.
a co z całą resztą???

1. Informacja - uporządkowany zbiór danych
2. Ta metoda kompresji nie uwzględnia kolejności danych (film jest uporządkowanym zbiorem - jak by nie patrzeć)
3. double float już nie wystarczy

PPS> Choć trzeba przyznać, że sam pomysł takiej kompresji jest ciekawy (aż szkoda, że nierealny)

<font color="green">[</span><font color="blue">ADD</span><font color="green">]</span>

A co z całą resztą??? (...) Ja kiedyś popełniłem podobny błąd

• faktycznie, źle cię zrozumiałem, przepraszam... (do postu poniżej)

Nieprawda, bo coś pod 5 MB. 4 GB to 41024 MB, a nie 41000 MB :-P

no tak pomyliłem się ;-))

Z tego wynika, ze dowolną informacje da sie spakować w 20 bajtów.

Eee, na pewno nie. Założę się, że znalazłoby się wiele różnych plików, które po takiej kompresji wyglądałyby identycznie.

No własnie o tym pisałem.

2. Każdą informację można zakodować do 20bajtów... :| Zapominasz o tym, że trzeba też zakodować matrycę (te linie), i że double float nie zawsze wystarczy.

Jak wyżej - pisałem w sensie że się nie da, a jak widzę, wszyscy odczytali że uważam że się da :(

i zajęło Wam jeszcze jedną stronę dojście do tego, co napisałem dwa tygodnie temu - szkoda, że nikt nie spróbował tego zrozumieć. ech, gorące głowy, czy jak to się tam mówi... :p