On Fri, 23 Nov 2012 22:38:50 -0800 (PST), e...@g...com
wrote:
> Oj, gdyby mi ktos przyszedl na rozmowe ubrany w taki garniturek,
> jaki nosza "manadzerowie sprzedazy" [1] (gdzie mozna takie gajerki
kupic?=
> powinienem miec jeden taki), to mialbym problem
> z rozpoczeciem w ogole rozmowy.j

He he, a w innych postach się kreowales na takiego oswieconego,
który nie zwraca uwagi na takie przyziemne uwagi jak strój.

RW

do góry

W dniu sobota, 24 listopada 2012 04:50:02 UTC-5 użytkownik Roman W napisał:
> On Fri, 23 Nov 2012 22:38:50 -0800 (PST), e...@g...com
> wrote:
> > Oj, gdyby mi ktos przyszedl na rozmowe ubrany w taki garniturek,
> > jaki nosza "manadzerowie sprzedazy" [1] (gdzie mozna takie gajerki
> kupic?=
> > powinienem miec jeden taki), to mialbym problem
> > z rozpoczeciem w ogole rozmowy.j

> He he, a w innych postach się kreowales na takiego oswieconego,
> który nie zwraca uwagi na takie przyziemne uwagi jak strój.

Zwracam uwage na czlowieka, stroj to element. Taki gajerek bardzo
rozpraszalby moja uwage.

Jakby student na taki pomysl wpadl zeby miec taki malowniczy garniak,
to bym jedynie stwierdzil, ze potrzebowac bedzie troche czasu
(na polroczny testdrive przy niewielkim wynagrodzeniu ;)

--
Edek

do góry

On 2012-11-24, Michoo <m...@v...pl> wrote:
> Mamy problem znalezienia dominanty w zbiorze liczb 16 bajtowych. Jeżeli
> dobrze szacuję (a nie chce mi się poświęcać na to zadanko za dużo czasu):
> - dla działania w miejscu mamy O(n^2)

Da się lepiej.

> - dla dodatkowej pamięci na dysku w rozmiarze 16*n schodzimy do
> O(n*log(n)) (Ale z uwzględnieniem losowych odwołań do dysku)
> - dla dodatkowej pamięci na dysku w rozmiarze 2*16*n schodzimy do
> O(n*log(n)) (Z sekwencyjnym dostępem, więc wielokrotnie szybciej niż w
> poprzednim przypadku.)
>
> n to oczywiście liczba liczb w ciągu

Mówiąc inaczej. Zaproponowany problem jest de facto równoważny
posortowaniu zbioru wejściowego.

pozdrawiam,
PK

do góry

W dniu sobota, 24 listopada 2012 04:44:05 UTC-5 użytkownik Jacek napisał:

> > I obie strony sa szczesliwe.

> Chyba mnie nie zrozumiałeś.
> Chodzi o to, że przez brak krawata, jakaś _pinda_ odsieje kandydata, który
> może być dobrym specjalistą, bo ona ma takie patrzenie na świat.
> Nigdy nie miałem wąsów, brody, a krawat miałem kilka razy na sobie i cieszę
> się, że pracuje sam dla siebie.

Musialbym bardzo chciec. W przeciwnym wypadku pytanie jest takie:
dlaczego witaja mnie taka pinda? Za co? I jeszcze ona o wszystkim
decyduje w moim przypadku? No to super, dalej moze byc tylko gorzej.

--
Edek

do góry

On 2012-11-24, e...@g...com <e...@g...com> wrote:
> Oj, gdyby mi ktos przyszedl na rozmowe ubrany w taki garniturek,
> jaki nosza "manadzerowie sprzedazy" [1] (gdzie mozna takie gajerki kupic?
> powinienem miec jeden taki), to mialbym problem
> z rozpoczeciem w ogole rozmowy.

Nieźle wyglądający, schludny i wygodny (wełna) garnitur można dostać
poniżej 1000 zł w zwyczajnych sieciówkach odzieżowych. Za podobną
kwotę można sobie zorganizować garniak szyty na miarę.

pozdrawiam,
PK

do góry

On 2012-11-24, Stachu 'Dozzie' K. <d...@g...eat.some.screws.spammer.invalid> wrote:
> Ze dwa lata temu, przy ostatniej przeprowadzce. Dostęp zdalny
> i wirtualizacja czynią cuda, wiesz.

Dostępem zdalnym wpinasz kable? To chyba jakaś nowa technologia!

pozdrawiam,
PK

do góry

W dniu sobota, 24 listopada 2012 06:22:29 UTC-5 użytkownik PK napisał:
> On 2012-11-24, e...@g...com <e...@g...com> wrote:
>
> > Oj, gdyby mi ktos przyszedl na rozmowe ubrany w taki garniturek,
> > jaki nosza "manadzerowie sprzedazy" [1] (gdzie mozna takie gajerki kupic?
> > powinienem miec jeden taki), to mialbym problem
> > z rozpoczeciem w ogole rozmowy.

> Nieźle wyglądający, schludny i wygodny (wełna) garnitur można dostać
> poniżej 1000 zł w zwyczajnych sieciówkach odzieżowych. Za podobną
> kwotę można sobie zorganizować garniak szyty na miarę.

Tak po zastanowieniu nad soba stwierdzam, ze w ubiorze tych gosci
najbardziej mi sie rzucaja w oczy spodnie. Moje pytanie brzmi nie
za ile moge kupic garniak, tylko gdzie kupic tak tanio wygladajacy,
moze byc i za 5tys.

--
Edek

do góry

W dniu 2012-11-24 02:49, Michoo pisze:
> On 20.11.2012 18:23, slawek wrote:
>
>> Aby nie być posądzanym o niekonstruktywną krytykę zapodam przykład (ktoś
>> chciał informatycznych wyzwań, żeby coś ciekawego było itd.) - to takie
>> zadanko:
>
> W ten sposób usunąłeś z zadanka jeden z ciekawych elementów, czyli "o co
> tu chodzi".
>
>>
>> "Dany jest plik długości 2 gigabajtów (tj. 2*1024*1024*1024). Wśród
>> wszystkich możliwych podciągów 16-bajtowych (których jest 2**31 - 2^4 +
>> 1, bo wybieramy kolejne bajty) znaleźć taki, który najczęściej występuje
>> w tym pliku. Uwaga: dane w pliku /mogą/ być zupełnie przypadkowe, może
>> też cały plik być wypełniony zerami itd. itp. - wszystkie złośliwe
>> przypadki dozwolone - tzn. nie wolno zgadywać, trzeba sprawdzić.
>> Premiowane będą rozwiązania szybkie i oszczędzające pamięć (zakładamy że
>> mamy tylko 512 MB RAM do dyspozycji)."
>
> Mamy problem znalezienia dominanty w zbiorze liczb 16 bajtowych. Jeżeli
> dobrze szacuję (a nie chce mi się poświęcać na to zadanko za dużo czasu):
> - dla działania w miejscu mamy O(n^2)
> - dla dodatkowej pamięci na dysku w rozmiarze 16*n schodzimy do
> O(n*log(n)) (Ale z uwzględnieniem losowych odwołań do dysku)
> - dla dodatkowej pamięci na dysku w rozmiarze 2*16*n schodzimy do
> O(n*log(n)) (Z sekwencyjnym dostępem, więc wielokrotnie szybciej niż w
> poprzednim przypadku.)

> n to oczywiście liczba liczb w ciągu

Być może opisuje to samo, co Ty w ostatnim punkcie.

Mając dodatkową pamięć dysku równo pierwotnej tablicy
(a tak naprawdę 0.5) możemy posortować tablicę
w 4 przebiegach _sekwencyjnego_ odczytu/zapisu.

Dominantę w posortowanej tablicy znajdujemy już
liniowo i szybko.

Jak sortujemy: pobieramy paczki po 512MB (albo mnijsze,
jeśli nasze 512MB jest sztywne i nie możemy dodać tym
czegoś lon(n)), sortujemy w RAM czymkolwiek sprawnym.

Mamy 8 posortowanych fragmentów pliku. Łączymy je mergesortem.
w 4, w 2, i w końcu w posortowany.

Co istotne, merga robimy nie bezpośrednio na dysku, ale na
buforach w ramie. Pobieramy odcinki po jakies 100MB,
kręcimy procedurą w mergesort, jak któryś bufor się wyczerpie,
napełniamy go ponownie kolejnymi danymi z dysku.

Dzięki temu czytamy sekwencyjnie, dysk nie lata ciągle np między
początkiem a środkiem pliku.

Niestety, nadal n log (n) i n*log(n/|RAM|) operacji (Sekwencyjnych)
na dysku, ale równoważnych przesłaniu tych kilkudziesięciu GB
- robialne.

BTW. w Cormenie chyba były algorytmy 'sortowanie zewnętrznego'.
Może warto zajrzeć, bo będzie coś sprytniejszego.


Kołaczą mi się sztuczki ze statystyką i nie jestem pewien,
czy nie da się tego zrobić lepiej. Ale ciężko będzie,
5 przbiegów po dysku to podejrzewam minimum.
W koncu nawet log(n) jest większe.

pzdr
bartek

do góry

W dniu 2012-11-24 12:36, bartekltg pisze:

>
> Mając dodatkową pamięć dysku równo pierwotnej tablicy
> (a tak naprawdę 0.5) możemy posortować tablicę
> w 4 przebiegach _sekwencyjnego_ odczytu/zapisu.
>
> Dominantę w posortowanej tablicy znajdujemy już
> liniowo i szybko.
>
> Jak sortujemy: pobieramy paczki po 512MB (albo mnijsze,
> jeśli nasze 512MB jest sztywne i nie możemy dodać tym
> czegoś lon(n)), sortujemy w RAM czymkolwiek sprawnym.
>
> Mamy 8 posortowanych fragmentów pliku. Łączymy je mergesortem.
> w 4, w 2, i w końcu w posortowany.
>
> Co istotne, merga robimy nie bezpośrednio na dysku, ale na
> buforach w ramie. Pobieramy odcinki po jakies 100MB,
> kręcimy procedurą w mergesort, jak któryś bufor się wyczerpie,
> napełniamy go ponownie kolejnymi danymi z dysku.
>
> Dzięki temu czytamy sekwencyjnie, dysk nie lata ciągle np między
> początkiem a środkiem pliku.
>
> Niestety, nadal n log (n) i n*log(n/|RAM|) operacji (Sekwencyjnych)
> na dysku, ale równoważnych przesłaniu tych kilkudziesięciu GB
> - robialne.

Optymalizacja: znajdowanie dominanty można upchnąć w ostatnią
fazę mergesorta. Odpada jeden odczyt.
Jeśli posortowana tablica nie jest nam do szczęścia potrzebna,
możemy też jej nie zapisywać.
Czyli 4 odczyty i 3 zapisy (4 zapisy, jeśli chcemy zachować
posortowaną tablicę na potem)
oba +1 jeśli użyjemy kawałków po 256MB.

pzdr
bartek

do góry

On 2012-11-24, bartekltg <b...@g...com> wrote:
> Kołaczą mi się sztuczki ze statystyką i nie jestem pewien,
> czy nie da się tego zrobić lepiej. Ale ciężko będzie,

Oczywiście czasem można przybliżać każdą statystykę (więc także modę)
przez badanie mniejszej próbki, ale trzeba coś wiedzieć o danych. To nie
jest taka sytuacja.

W każdym razie nie istnieje żadna "sztuczka" pozwalająca w magiczny
sposób wyciągnąć modę (choć można próbować coś wymyśleć w przypadku
momentów).

pozdrawiam,
PK

do góry