sobota, 27 września 2008
piątek, 12 września 2008
Error Resilience in Compressed Data
I've found very interesting PhD thesis "Error Resilience in Compressed Data — Selected Topics" by Marek Biskup; author concentrated on decoding broken messages encoded with Huffman codes. Additionally parallel decoding of Huffman-coded messages is shown.
Etykiety:
data compression,
huffman coding,
znaleziska
wtorek, 9 września 2008
Kompresja danych
Zakupiłem ostatnio książkę Artura Przelaskowskiego "Kompresja danych" (BTC 2005). To co do tej pory przeczytałem robi bardzo dobre wrażenie, wydaje mi się jakoś bardziej przyjazne od "Wprowadzenie do kompresji" Adama Drozdka.
Jednakże jednej rzeczy mi brakuje: indeksu; to naprawdę ważna rzecz dla czytelnika, kiedy często sięga po pozycję. Poza tym wydaje mi się, że rezygnacja z wcięć akapitowych ekstrawagancka jest.
Jednakże jednej rzeczy mi brakuje: indeksu; to naprawdę ważna rzecz dla czytelnika, kiedy często sięga po pozycję. Poza tym wydaje mi się, że rezygnacja z wcięć akapitowych ekstrawagancka jest.
piątek, 5 września 2008
Informatyka na Wikipedii
Kiedy w 2003 roku trafiłem na polską Wikipedię, był to projekt raczkujący, ledwie 20 tysięcy haseł (teraz 500 tysięcy i rośnie!). Wówczas wyczytałem na stronie jednej z osób, że jest informatykiem, ale zajmuje się innymi dziedzinami, bo "informatyka jest wyeksploatowana". To oczywista bzdura była i niestety jest nadal. Informatyka to bardzo zapuszczona działka. Przedwczoraj poprawiłem nieco hasło wątek - jego wcześniejsza wersja absolutnie nie dawała odpowiedzi na pytanie "czym jest wątek?". Nawet osoba, która raz w życiu napisała prosty program i od czasu do czasu "grepuje gzipy" nie byłaby w stanie skumać OCB, a cóż dopiero zwykły człowiek.
Moim marzeniem są hasła przystępnie napisane zarówno dla praktyków, teoretyków jak również zwykłych czytelników. Żeby ten ostatni przeczytał i mniej więcej wiedział czym jest to, o czym czytał, praktyk żeby widział jakie są podstawy teoretyczne, a teoretyk jakie zastosowania praktyczne.
Już niedługo Jerzy Ludwichowski poprowadzi dyskusję na konferencji Polskiego Towarzystwa Informatycznego właśnie na ten temat. Mam nadzieję, że m.in. dzięki temu Wikipedia przyciągnie większą liczbę profesjonalistów, nauczycieli akademickich, ażeby nasze wspólne dzieło było jak najlepsze.
BTW to ostatnie brzmi jak wyimek z manifestu Marksa, ale po prawdzie Wikipedia to najlepszy przykład an-archistycznego projektu. Wyobraźcie sobie jak wyglądałaby Wikipedia, gdyby w rządzie był minister do spraw Wikipedii, zaś budżet finansował serwery. Wyglądałoby to pewnie jak Polska Biblioteka Internetowa - 3 miliony złotych w plecy, bo funkcjonalność na poziomie Web 0,0001, zasoby biedne, skany kulawe. A na moje pytania ile w tym roku MSWiA wydało na PBI ministerialne biurwy nie odpowiedziały.
Moim marzeniem są hasła przystępnie napisane zarówno dla praktyków, teoretyków jak również zwykłych czytelników. Żeby ten ostatni przeczytał i mniej więcej wiedział czym jest to, o czym czytał, praktyk żeby widział jakie są podstawy teoretyczne, a teoretyk jakie zastosowania praktyczne.
Już niedługo Jerzy Ludwichowski poprowadzi dyskusję na konferencji Polskiego Towarzystwa Informatycznego właśnie na ten temat. Mam nadzieję, że m.in. dzięki temu Wikipedia przyciągnie większą liczbę profesjonalistów, nauczycieli akademickich, ażeby nasze wspólne dzieło było jak najlepsze.
BTW to ostatnie brzmi jak wyimek z manifestu Marksa, ale po prawdzie Wikipedia to najlepszy przykład an-archistycznego projektu. Wyobraźcie sobie jak wyglądałaby Wikipedia, gdyby w rządzie był minister do spraw Wikipedii, zaś budżet finansował serwery. Wyglądałoby to pewnie jak Polska Biblioteka Internetowa - 3 miliony złotych w plecy, bo funkcjonalność na poziomie Web 0,0001, zasoby biedne, skany kulawe. A na moje pytania ile w tym roku MSWiA wydało na PBI ministerialne biurwy nie odpowiedziały.
sobota, 30 sierpnia 2008
LZP - metoda kompresji
Jeśli kiedyś będziecie potrzebowali wiedzieć jak działa algorytm LZP, to na coraz bardziej niezawodnej Wikipedii znajdziecie. Dla stron polskich G**gle zwraca 10 stron na krzyż.
wtorek, 26 sierpnia 2008
Bylejakość
Na pewnej popularnej stronie dla programistów czytamy (przez litość nie podaję linku):
Z tego tekstu wynika, że liczba wielomianów potrzebnych do określenia krzywej jest równa stopniu wielomianu -- tak oczywiście nie jest. Liczba wielomianów zależy od liczby wymiarów przestrzeni w której określana jest krzywa, wielomiany mogą być dowolnego stopnia; np. można mieć krzywą przestrzenną (czyli 3 wielomiany) ale wielomiany stopnia 125.
Dalej, co to znaczy "wielomiany z pewnym parametrem"? Ja pamiętam jeszcze ze szkoły średniej zadania w rodzaju "dla jakiego parametru c wielomian jakiśtam nie ma pierwiastków", ale tutaj rzecz jasna nie chodzi o to. Mowa oczywiście o wielomianach jednej zmiennej, zwyczajowo argument jest tutaj oznaczany literką 't', a nie 'x' jak się przyzwyczailiśmy.
Dalej jest jeszcze jeden cymes:
Dlaczego o tym piszę? Bo razi mnie taka bylejakość, a poza tym lubię się czasem przypieprzyć; na Wikipedii taki tekst bychyba na pewno nie przeszedł (z resztą mamy na wiki całkiem nieźle opracowany temat krzywych i powierzchni Beziera).
27.08.2008 - dwie drobne poprawki
Krzywa Beziera to krzywa wielomianowa trzeciego stopnia, czyli taka która może być definiowana za pomocą trzech wielomianów (odpowiednio dla współrzędnych x, y i z) z pewnym parametrem t.Ludzie, co za kosmiczne bzdury! Wielomianowa krzywa Beziera nie ma ograniczonego stopnia, stopień wielomianów może być dowolny. Sama zaś krzywa Beziera jest krzywą parametryczną.
Z tego tekstu wynika, że liczba wielomianów potrzebnych do określenia krzywej jest równa stopniu wielomianu -- tak oczywiście nie jest. Liczba wielomianów zależy od liczby wymiarów przestrzeni w której określana jest krzywa, wielomiany mogą być dowolnego stopnia; np. można mieć krzywą przestrzenną (czyli 3 wielomiany) ale wielomiany stopnia 125.
Dalej, co to znaczy "wielomiany z pewnym parametrem"? Ja pamiętam jeszcze ze szkoły średniej zadania w rodzaju "dla jakiego parametru c wielomian jakiśtam nie ma pierwiastków", ale tutaj rzecz jasna nie chodzi o to. Mowa oczywiście o wielomianach jednej zmiennej, zwyczajowo argument jest tutaj oznaczany literką 't', a nie 'x' jak się przyzwyczailiśmy.
Dalej jest jeszcze jeden cymes:
Krzywe trzeciego stopnia są również krzywymi najniższego stopnia, które nie leżą w jednej płaszczyźnie w 3D.Czyli, że co -- nie można określić w przestrzeni krzywej trzeciego stopnia, która leżałaby na płaszczyźnie? (Odpowiedź brzmi oczywiście: nie, na całe szczęście można). A poza tym "w jednej płaszczyźnie" -- ale z czym? Bez sensu kompletnie. O co więc chodzi: krzywa 3-stopnia opisywana jest 4 punktami kontrolnymi, i taka liczba punktów może być niewspółpłaszczyznowa, a co za tym idzie krzywa nie będzie płaska.
Dlaczego o tym piszę? Bo razi mnie taka bylejakość, a poza tym lubię się czasem przypieprzyć; na Wikipedii taki tekst by
27.08.2008 - dwie drobne poprawki
niedziela, 24 sierpnia 2008
Wrap me!
Inheritance is fundamental way of creating new types in OOP. Apart of this, there is another important technique: composition, using many object to create higher level objects that provide interface to selected members of component objects. Inheritance is supported by many languages at syntax level, composition -- not!
Consider simple (real-world) example: we have GUI objects -- static label, and list box, we want another widget, labeled list box, a composition of these two simple widgets. We have to write tons of wrappers, that just call label or list methods. Here is example (C++):
Of course C++ compiler is able to inline LabeledListBox methods, but programmer have to write many lines of code that merely call another methods. He must know types of arguments, returned values and other. And if some class is changed, he must update classes that use this one. He must maintain all these stupid wrappers. Wrappers are evil.
Wrappers are so frequently used in programming, that I'm still don't know why syntax of popular languages do not reflect this state. This is my view of syntax, but I hope shows the intention -- simple things should remain simple on screen:
Consider simple (real-world) example: we have GUI objects -- static label, and list box, we want another widget, labeled list box, a composition of these two simple widgets. We have to write tons of wrappers, that just call label or list methods. Here is example (C++):
class Label {
public:
void set_text(string s);
string get_text();
};
class ListBox {
public:
void clear();
int add_item(string s, bool uppercase);
string get_item(int index);
};
class LabeledListBox {
public:
void set_label(string s) {label.set_text(s);}
string get_label() {return label.get_text();}
void clear() {box.clear();}
int add_item(string s) {return box.add_item(s, false);}
int add_item_uppercase(string s) {return box.add_item(s, true);}
string get_item(int index) {return box.get_item(inex);}
private:
Label label;
ListBox box;
};
Of course C++ compiler is able to inline LabeledListBox methods, but programmer have to write many lines of code that merely call another methods. He must know types of arguments, returned values and other. And if some class is changed, he must update classes that use this one. He must maintain all these stupid wrappers. Wrappers are evil.
Wrappers are so frequently used in programming, that I'm still don't know why syntax of popular languages do not reflect this state. This is my view of syntax, but I hope shows the intention -- simple things should remain simple on screen:
class LabeledListBox {
public:
method set_label is label.set_text; // rename
method get_label is label.get_text; // rename
method clear, get_item from box; // publish two methods of box object
method add_item is box.add_item with uppercase=false; // create simple wrappers
method add_item_upperacase is box.add_item with uppercase=true; // with default arguments set to const
private:
Label label;
ListBox box;
};
Subskrybuj:
Posty (Atom)