> tych releasow trzeba pilnowac - da sie zrobic, apple
> trzyma wysoki poziom - ale sama koniecznosc borykania
> sie z tymi releasami moze byc postrzegana jako minus

zwlaszcza ze wszystkie pojedyncze w skali aplikacji
alloki mozna by miec gdzies - i przejmowac sie tylko tymi
w petlach itp - tymczasem tu musisz raczej zadbac mozolnie
o releasa do wszystkiego :-/


--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl

do góry

p...@p...onet.pl wrote:
>
>>> On 3 Kwi, 21:12, "kenobi" <p...@p...onet.pl> wrote:
>>>> kiedys (jakis kwartal temu) wymyslilem
>>>> sentencje 'prawdziwy asemblerowiec
>>>> pisze 365 razy dluzej 365 razy szybsza
>>>> aplikacje'
>> To jest kompletny idiotyzm
>>
>> A.L.
>
>
> no nie jest to scisla regula tylko zartobliwa,
> np mozna podstawic pod asemblerowiec cos
> bardziej jak naukowiec pod pierwsze 365 X pod drugie
> 365 Y a pod szybszy inny
>

Ale to nadal jest do kitu. Bo w rzeczywistej rzeczywistości jeśli coś daje
się poprawić rzędu 365 razy (dla typowych, średnich danych) to w
znakomitej większości przypadków oznacza to, że poprawiona została
złożoność (asymptotyczna) algorytmu a nie, że kod wyrzeźbiono w czymś
niskopoziomowym. Co gorsza to nie ma w ogóle wtedy żadnego jednego X razy
bo dla jednych (mniejszych danych) będzie np. w ogóle wolniej (X<1) ale
dla danych dużych będzie np X>1000000000.

\SK
--
"Never underestimate the power of human stupidity" -- L. Lang
--
http://www.tajga.org -- (some photos from my travels)

do góry

> A wracajac jeszcze do automatycznej budowy takich
> heurystyk to zastanawiam sie jakie efekty bylyby dla
> przeszukiwania drzewa gry w szachach. Dobre programy
> szachowe sa dlatego dobre ze bez przeszukiwania
> drzewa gry z duzym prawd. przewiduja ktory ruch jest
> na tyle kiepski ze mozna po nim nie przeszukiwac. Takie
> techniki przyspieszaja programy miliony razy, tyle ze
> sa one wpisywane przez programistow-szachistow.
>
> Zastanawiam sie czy mozna wygenerowac taka heurystyke w
> pelni atomatycznie. Tez mozna zrzucic stan algorytmu do pliku i
> widac jak na dloni po ktorych ruchach przeszukiwanie nie
> mialo sensu. Ale co potem zrobic z takim plikiem?

spróbować zakodować mechanizm oceny w ogóle i uwzględniający takie
przypadki w szczególności?

do góry

p...@p...onet.pl wrote:
>
> jesli jest w miare dobrze napisana (i nie
> w jakims 'wysokopoziomowym' smietniku) to tyle
> razy nie przyspieszysz - na twoim miejscu
> na pewno rzucilbym c++ i przesiadl sie na statyczne c

g++ -static

> ze wstawkami w asmie (duzo inline itp)- moze byloby ze 3 razy
> szybciej;

g++ -flto/-fwhole-program i inline nie sa w ogóle potrzebne

pozdrawiam

--
Michał Walenciak
gmail.com kicer86
http://kicer.sileman.net.pl
gg: 3729519

do góry

> > no nie jest to scisla regula tylko zartobliwa,
> > np mozna podstawic pod asemblerowiec cos
> > bardziej jak naukowiec pod pierwsze 365 X pod drugie
> > 365 Y a pod szybszy inny
> >
>

> Ale to nadal jest do kitu. Bo w rzeczywistej rzeczywistości jeśli coś daje
> się poprawić rzędu 365 razy (dla typowych, średnich danych) to w
> znakomitej większości przypadków oznacza to, że poprawiona została
> złożoność (asymptotyczna) algorytmu a nie, że kod wyrzeźbiono w czymś
> niskopoziomowym. Co gorsza to nie ma w ogóle wtedy żadnego jednego X razy
> bo dla jednych (mniejszych danych) będzie np. w ogóle wolniej (X<1) ale
> dla danych dużych będzie np X>1000000000.
>

ye, i know,
ale yak mowilem nie jest to scisla regula tylko rodzaj anegdoty przy tym jak
wyjasnialem chodzi tez i o dlubanie w algorytmach (gdzies, na jakiejs ksiazce
chyba widzialem kiedys tekst 'warto sie uczyc asemblera bo jezyki
wysokopoziomowe oduczaja myslenia algorytmicznego') - cos w tym mz jest
- niewazne nie chce sie klocic




--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl

do góry

On 4 Kwi, 12:53, lolo <n...@n...com> wrote:
> > Zastanawiam sie czy mozna wygenerowac taka heurystyke w
> > pelni atomatycznie. Tez mozna zrzucic stan algorytmu do pliku i
> > widac jak na dloni po ktorych ruchach przeszukiwanie nie
> > mialo sensu. Ale co potem zrobic z takim plikiem?
>
> spróbować zakodować mechanizm oceny w ogóle i uwzględniający takie
> przypadki w szczególności?
Wlasnie takie kodowanie wydaje mi sie malo interesujace i
bardzo zmudne. Chcialbym jakas metode ktora sama odkryje
wiedze w danych.

Gdy program przeszukuje drzewo gry to w kazdym wezle wykonuje
wiele ruchow ktore nie wplywaja na poprawe oceny. Mozna
zapisac na dysku uklady na szachownicy wraz z ruchem i stanem
algorytmu i wraz z tym czy ruch poprawil ocene czy nie. W ten sposob
powstana wektory uczace, kazdy wektor bedzie mial wartosc true jesli
przyczynil sie do poprawy oceny, albo false jesli oceny nie porawil.

Pierwsze pytanie jakie sie nasuwa: czy da sie do takich danych
zbudowac w sensownym czasie jakis klasyfikator?

Drugie pytanie: jaka musi byc skutecznosc takieo klasyfikatora
zeby przeszukiwanie drzewa gry nie dalo blednego wyniku?
Klasyfikator moze sie mylic tylko raz na milion ruchow, czy moze
raz na tysiac? Jesli bedzie dzialal szybciej niz przeszukiwanie
drzewa gry, to na pewno raz na iles ruchow bedzie sie mylil.

Pozdrawiam

do góry

Dnia Mon, 04 Apr 2011 11:44:49 +0200, Sebastian Kaliszewski napisał(a):
> > p...@p...onet.pl wrote:
> Ale to nadal jest do kitu.

Ech, musicie go wyciągać z KF?
Gość, jeśli kiedykolwiek coś sensownego napisał, to tylko przez przypadek.
Zazwyczaj są to kolejne wizje z cyklu "ale mi niedobrze - wymyśliłem
rozszerzenie C - mam depresję".

Waldek

do góry

> Ech, musicie go wyciągać z KF?
> Gość, jeśli kiedykolwiek coś sensownego napisał, to tylko przez przypadek.
> Zazwyczaj są to kolejne wizje z cyklu "ale mi niedobrze - wymyśliłem
> rozszerzenie C - mam depresję".

smieszna wypowiedz...

c jest jezykiem nisko poziomowym i faktem
jest ze najlepiej mi sie o nim mysli gdy mam dola
to jest zarazem zartem jak i serio

ostatnio czesto mam dola bo przesladuje mni
jakies fatum - dzis np albo zgubilem albo raczej
jacys kieszonkowcy buchneli mi kase z kieszeni
- co za los :(



--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl

do góry

a na koniec to wszystko i tak przybiera
wymiar anegdotyczny (mowie o releasach
i objective-c) - co czytamy po przepilnowaniu
setek releasow i skomplikowanej hierarchi
ownershipow: "poniewaz kazdy proces zwalnia
hurtem przestrzen swoich danych z powodow
wydajnosciowych polecamy nie zwalnianie
pamieci w hierarchi przez kaskade release
tylko zalecane jest by proces sam zniszczyl to
przy skilowaniu"

--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl

do góry

> c jest jezykiem nisko poziomowym i faktem
> jest ze najlepiej mi sie o nim mysli gdy mam dola
> to jest zarazem zartem jak i serio
>
> ostatnio czesto mam dola bo przesladuje mni
> jakies fatum - dzis np albo zgubilem albo raczej
> jacys kieszonkowcy buchneli mi kase z kieszeni
> - co za los :(
>
kupilbym sobie z 5 kilo dobrych potrzebnych
mi ksiazek (np Browninga itp) a tak to musze
teraz pozyczac by dozyc do pierwszego - niech
piorun strzeli tych kieszonkowcow

co do programowania to zauwazam postepy
- np najnowsze krytyka zarowno gc jak i recznego zwalniania
pamieci czy wyklarowanie roznicy miedzy modulami
a obiektami (domena klonerow) Cieszy mnie
to bo lubie miec jasnosc; Zadnej poprawki do
c za to dawno nie wymyslilem

--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry