🚀 go-pugleaf

Michał: [pl.comp.lang.c: 4 Jan 98 10:55:41 GMT]
: Piszę właśnie program korzystający z rekurencji, ale niestety po 125
: zagłębieniach wszystko pada, najprawdopodobniej z braku pamięci.
[...]

w jezykach typu c, pascal, itp. gdzie wolanie funkcji kompilowane jest na
call asemblerowy nie mozna uzywac glebokiej rekurencji, gdyz obszar
przeznaczony na stos procesora jest w wiekszosci architektur maly;
,,glebokiej'' to znaczy liniowej do rozmiaru danych wejsciowych lub
glebszej; musisz to przerobic na iteracje; pewna poprawe uzyskasz redukujac
liczbe (rozmiar laczny) zmiennych lokalnych, ale to gra niewarta swieczki

pozdrawiam,
robert
-- 
robmar@mimuw.edu.pl                  http://zls.mimuw.edu.pl/~robmar/
                                           - pragnący dziwnego -

no dobra, ale to co robię nie bardzo da się uzyskać przy pomocy iteracji. a
propos sprawdzania pamieci, moze wiesz jak to zrobic w tym wypadku ?

Michał: [pl.comp.lang.c: 5 Jan 98 00:32:22 GMT]
: no dobra, ale to co robię nie bardzo da się uzyskać przy pomocy iteracji. a
da sie na pewno :-)
powiedz co...

: propos sprawdzania pamieci, moze wiesz jak to zrobic w tym wypadku ?
nie da sie w ogolnosci...

robert
-- 
robmar@mimuw.edu.pl                  http://zls.mimuw.edu.pl/~robmar/
I am individual from Earth of average size and shape. I suppose I am
like a lot of people. I am unusual in that I am on an alien planet.

Micha³ Suski wrote:
> 
> Piszê w³a¶nie program korzystaj±cy z rekurencji, ale niestety po 125
> zag³êbieniach wszystko pada, najprawdopodobniej z braku pamiêci.
> Najprawdopodobniej, bo komputer siê wiesza, a raczej emm286 stwierdza jaki¶
> b³±d i go zawiesza. Jak sprawdzaæ ilo¶æ dostêpnej pamiêci, dodam, ¿e
> coreleft() nie pomaga, bo stwierdza, ¿e jest jej ca³a masa. Z góry
> dziêkujê.
> --

  Prawdopodobnie chodzi o pamiec alokowana na stosie.
Kazde wywolanie rekurencyjne powoduje alokowanie nowej
pamieci na stosie na adres powrotu, argumenty przekazane
w wywolaniu funkcji, zmienne lokalne. Rozwiazaniem moze
byc zwiekszenie ilosci pamieci przeznaczonej na stos
(linker) lub jesli wywolan funkcji rekurencyjnej ma byc
bardzo duzo - stworzenie w pamieci statycznej buforow
do przechowywania zmiennych lokalnych (trzeba oczywiscie
zaprojektowac mechanizm korzystania z tych buforow).
Jesli i to nie pomoze, trzeba przejsc na wersje iteracyjna
obliczen.

HTH.

Marek Kotowski

Micha³ Suski wrote:
> 
> no dobra, ale to co robiê nie bardzo da siê uzyskaæ przy pomocy iteracji. a
> propos sprawdzania pamieci, moze wiesz jak to zrobic w tym wypadku ?
Jesli chodzi o stos, moznaby sprawdzac rejestr SP.
Maly.

On 4 Jan 98 10:55:41 GMT, "Micha³ Suski" <suseu@polbox.com> wrote:

>Piszê w³a¶nie program korzystaj±cy z rekurencji, ale niestety po 125
>zag³êbieniach wszystko pada, najprawdopodobniej z braku pamiêci.
>Najprawdopodobniej, bo komputer siê wiesza, a raczej emm286 stwierdza jaki¶
>b³±d i go zawiesza. Jak sprawdzaæ ilo¶æ dostêpnej pamiêci, dodam, ¿e
>coreleft() nie pomaga, bo stwierdza, ¿e jest jej ca³a masa. Z góry
>dziêkujê.

zwieksz wielkosc stosu na ktory odkladane sa zmienne lokalne
ustaw globalna zmienna

unsigned _stklen=60000;

standardowo ustawiona jest na 4kb
zmniejsz tez ilosc zmiennych lokalnych do tych najpotrzebniejszych


Jarek Woloszyn

ysr@kki.net.pl
http://free.polbox.pl/w/woljar
UIN: 1922941

Michał Suski <suseu@polbox.com> napisal 
> Piszę właśnie program korzystający z rekurencji, ale niestety po 125
> zagłębieniach wszystko pada, najprawdopodobniej z braku pamięci.
> Najprawdopodobniej, bo komputer się wiesza, a raczej emm286 stwierdza
jakiś
> błąd i go zawiesza. Jak sprawdzać ilość dostępnej pamięci, dodam, że
> coreleft() nie pomaga, bo stwierdza, że jest jej cała masa. Z góry
> dziękuję.

Jesli piszesz w Borlandzie (a tak sadze po wykorzystaniu funkcji coreleft
()) to:
1: jako model pamieci wez przynajmniej small a najlepiej large (moze byc
huge).
2: bezposrednio przed funkcja main () ustaw duzy rozmiar stosu np:
    unsignet int _stklen = 64000;
3: wlacz w opcjach kompilatora (przynajmniej dla prob) opcje
    'check stack overflow'. Wtedy gdy przekroczysz rozmiar stosu otrzymasz
    komunikat 'Stack overflow'.
4: ogranicz maksymalnie ilosc parametrow funkcji rekurencyjnej,
    szczegolnie struktury przekazuj przez pointer (a dgy piszesz w c++
    to przez referencje) a nie przez wartosc.
5: zmienne lokalne ktore nie wplywaja na nastepne wywolanie rekurecji 
    zrob statycznymi.

Jesli i to nie pomoze to jestes skazany na sztuczki
ktore uczynia program brzydkim ale...:

6: zlikwiduj zmienne lokalne np. tak.

    zamiast 

int funkcja rekurencyjna ()
{
     int a;
     double b;
     ...
}
  
    zastosuj   

int funkcja rekurencyjna ()
{
     struct loc
     { 
     int a;
     double b;
     } * ploc = (struct loc *) malloc (sizeof (struct loc));  // dla C++
new loc;
     ...
     free (ploc);   // dla C++ delete ploc;    
}
  
7: do parametrow funkcji rekurencyjnej tez mozesz zastosowac podobny 
    sposob jak do zmiennych lokalnych z dynamicznym przydzielaniem i
    zwalnianiem (poprzez malloc i free) odpowiedniej struktury z
parametrami
    a do funkcji przekazuj tylko pointer (lub referencje) do tej struktury.
      
A gdy stwierdzisz ze dalej nic z tego, sprobuj zrobic to nierekurencyjnie
ale iteracyjnie. Wbrew pozorom nie zawsze to psuje "wyglad" algorytmu :).

Pozdrawiam

A.K.   
karpierz@intertele.pl

moze sie i da, ale to bedzie syzyfowa praca w przypadku przeszukiwania
labiryntów dla znalezienia drogi z początku na koniec. ale i tak dzięki

dzięki za wyczerpującą odpowiedź, spróbuję tych sztuczek, ale zwiększanie
stosu w linkerze absolutnie nie pomaga, a zmienną w procedurze mam tylko
jedną, a parametry trzy - niezbędne :)

Micha³ Suski wrote:
> 
> dziêki za wyczerpuj±c± odpowied¼, spróbujê tych sztuczek, ale zwiêkszanie
> stosu w linkerze absolutnie nie pomaga, 

Powinno. Jesli nie pomaga, moze blad jest gdzies indziej.

> a zmienn± w procedurze mam tylko
> jedn±, a parametry trzy - niezbêdne :)

Powtorze: mozna przekazywanie parametrow z wywolania do wywolania
przeniesc
do pamieci statycznej albo dynamicznej (to samo ze zmienna lokalna).
Wtedy stos bylby uzywany tylko do przechowywania adresu powrotu z
funkcji (1 wywolanie - 4 bajty w IBM PC). Jesli taki zabieg nie zwiekszy
liczby poprawnych wywolan funkcji rekurencyjnej, to prawie pewne
jest, ze przyczyna bledu nie lezy w przekraczaniu dostepnego miejsca
na stosie.

Marek Kotowski

Mam pytanie.
Pisze program w BC++ 4.52. Napisalem funkcje ktora wrzuca zawartosc dysku
(same katalogi) do ListBox'a na glownym okienku. Kiedy odpalam funkcje 
z BC++3.01 to funkcja dziala z kazdego dysku (C: D: itd..) ale kiedy chce
wrzucic wszystkie te katalogi jako napisy do ListBox'a to kompilator
zglasza FatalError z biblioteki BC450RTL ale tylko w przypadku dwoch
dyskow (C: i G:), katalogi z reszty dyskow sa pokazywane poprawnie.
Nie sadze aby byl to problem z pamiecia gdyz dla sprawdzenia dalem 5
ListBox'ow i uruchomilem funkcje dla dyskow dla ktorych ona dziala i
wszystko bylo OK. Czy ListBox ma okreslona pojemnosc?

Mam nadzieje ze ktos wie o co chodzi?!

Michal Mielech
michalek@infeco.pb.bialystok.pl

Michał Suski <suseu@polbox.com> napisał(a) w artykule
<01bd1a68$168cf760$08fa74c3@suseu>...
> dzięki za wyczerpującą odpowiedź, spróbuję tych sztuczek, 
> ale zwiększanie stosu w linkerze absolutnie nie pomaga, 
> a zmienną w procedurze mam tylko jedną, a parametry 
> trzy - niezbędne :)

Przy tak malej ilosci danych sztuczki zostaw w spokoju.

ustawienie _stklen powinno czesciowo pomoc:

unsigned int _stklen = 64000;

int main (void)
{
....
}

ale....
Przeczytalem w innym postingu ze chcesz rozwiazac labirynt.
Nie pisalem nigdy labiryntu ale jesli zamierzasz rekurencyjnie 
chodzic po drzewie rozwiazan to na mojego nosa nie unikniesz 
przepelnienia stosu, nawet dla malych rozmiarow labiryntu jesli
zrobisz to nieumiejetnie.  
Mysle jednak ze ten problem da sie rozwiazac elegancko
bez jawnego uzycia rekurencji, pamietajac jedynie "sciezke" 
wezlow (pokoi) rozwiazan (jako liste dwukierunkowa, albo
stos /ale nie ten procesora:)/) i gdy zastosujesz zwykly algorytm
"zachlanny" czyli sprawdzajacy wszystkie rozwiazania,
ale madrze czyli w okreslonym porzadku.
Niepedagogicznie podpowiem tylko tyle ze w tym algorytmie 
idziemy do przodu (czyli wydluzamy "sciezke") jezeli dany pokoj
ma jeszcze niesprawdzone pokoje w lewo od kierunku
z ktorego weszlismy do pokoju, w przeciwnym przypadku
skracamy sciezke (wracamy do poprzedniego pokoju) itd.. itd..
az... albo znajdziesz rozwiazanie (znajdziesz balkon :)
albo wrocisz do przedpokoju i nie bedzie juz niesprawdzonych 
pokoi (labirynt dla masochistow:). 
Stad tez zasada ze z kazdego labiryntu mozna wyjsc idac 
caly czas przy jednej scianie. 

Powodzenia :)

A.K.
karpierz@intertele.pl

PS: oczywiscie jest duzo zrodel (na sieci tez) do rozwiazywania 
      labiryntu, ale... radze sprobuj sam. Sam sposob podejscia 
      do problemu nadaje sie do roznych rzeczy i naprawde warto 
      abys go "poczul". Sam zobaczysz jakie to proste w gruncie 
      rzeczy.
      

Michał Suski <suseu@polbox.com> wrote:
: moze sie i da, ale to bedzie syzyfowa praca w przypadku przeszukiwania
: labiryntów dla znalezienia drogi z początku na koniec. ale i tak dzięki

Nieprawda! Algorytm nierekurencyjny jest bardzo prosty! Oczywiście
musi być to algorytm z powrotami, ale nie mysi być rekurencyjny.

Tworzysz sobie programowo (na stercie) strukturę typu stos, w której
przechowujesz ścieżkę, którą idziesz. Tworzysz pętlę while z warunkiem wyjścia
takim, że kończy się ona, gdy jesteś w punkcie wyjścia z labiryntu.
W każdym obiegu pętli robisz jeden krok "do przodu" (na przyległe pole,
na którym jeszcze nie byłeś i na które da się przejść) lub "do tyłu" (gdy
nie istnieje takie pole o jakim mowa w poprzednim nawiasie - wszedłeś
w ślepy zaułek - i musisz się wycofać po własnych śladach). Przy poruszaniu
się "do przodu" odkładasz aktualne współrzędne na stos i robisz krok, czyli
zmieniasz aktualne współrzędne zgodnie z kierunkiem ruchu. Przy "cofaniu się"
po prostu zdejmujesz ze stosu współrzędne pola, w którym byłeś poprzednio.
Gdy pętla skończy się, na stosie masz szukaną ścieżkę.

W ten sposób nie używasz stosu procesora, który rzeczywiście może się
przepełnić przy dużych labiryntach. Programowo możesz sobie zrobić taki stos
na ile masz pamięci w kompie.

-- 
Piotr Auksztulewicz                 piotras@zeus.polsl.gliwice.pl
Centrum Komputerowe Politechniki Śląskiej, Gliwice, Akademicka 16

Witam

Misiu wrote:
> 
> wszystko bylo OK. Czy ListBox ma okreslona pojemnosc?
> 

Tak, przynajmniej ten 16-bitowy. Mozna zaladowac do niego ok 7-8 tys.
elementow i wlasciwie nie wiadomo dlaczego akurat tyle.

Pozdrawiam
Darek
D.Michalek@bsb.com.pl

Michał: [pl.comp.lang.c: 6 Jan 98 05:56:21 GMT]
: moze sie i da, ale to bedzie syzyfowa praca w przypadku przeszukiwania
: labiryntów dla znalezienia drogi z początku na koniec. ale i tak dzięki

dlaczego???
robisz stos w tablicy lub wskaznikami, algorytm wyglada tak:

while (not stos pusty) do
  {
    pop miejsce;
    if not (miejsce odwiedzone lub niedostepne) then
      { odwiedz miejsce; push otoczenie miejsca }
  }

i ten algorytm dziala kiepsko :-)
ale jesli stos zastapisz kolejką, to bedzie bardzo zuzywal bardzo malo
pamieci

robert
-- 
robmar@mimuw.edu.pl                  http://zls.mimuw.edu.pl/~robmar/
Last night there was an eclipse. I had planned to go out and see it but fall
asleep over a book and missed the thing. Not that it matters. The ship's
cameras recored it automatically and I'll catch it on replay.

Dariusz Michalek wrote:
> Misiu wrote:
> > wszystko bylo OK. Czy ListBox ma okreslona pojemnosc?
> Tak, przynajmniej ten 16-bitowy. Mozna zaladowac do niego ok 7-8 tys.
> elementow i wlasciwie nie wiadomo dlaczego akurat tyle.

Do 16-bitowego kontenera mozesz zaladowac
dokladnie 16383 elementow = 65535 DIV 4
(wektor adresow). Prawdopodobnie ListBox
trzyma dwie takie listy na jednym wektorze
i stad masz tylko polowe, czyli 8191 elementow.

Pozdrawiam,

Jacek Pietraszek

On 6 Jan 1998 12:02:10 GMT, in pl.comp.lang.c Piotr Auksztulewicz
<piotras@zeus.polsl.gliwice.pl> wrote:

>Michał Suski <suseu@polbox.com> wrote:
>: moze sie i da, ale to bedzie syzyfowa praca w przypadku przeszukiwania
>: labiryntów dla znalezienia drogi z początku na koniec. ale i tak dzięki
>
>Nieprawda! Algorytm nierekurencyjny jest bardzo prosty! Oczywiście
>musi być to algorytm z powrotami, ale nie mysi być rekurencyjny.
Nie musi, niezbyt oszczędny pamięciowo i czasowo algorytm rozwiązywania
labiryntu, określany mianem "wypalania stepu" polega na stworzeniu tablicy
opisującej labirynt, i przejrzeniu jej "n" razy, a przy każdym przejściu
jeżeli wartość w komórce jest "x" to sprawdzamy sąsiadujące komórki i jeśli
sa puste to wpisujemy do nich wartość "x+1" jeżeli jesteśmy w sąsiedztwie
wyjścia to już koniec (chyba ze szukamy wszystkich dróg a nie najkrótszej).
Teraz można wrócic po "sladach" czyli malejące liczby doprowadzą nas od
wyjscia do wejscia. Warunek stopu to oczywiście brak wartości której
szukamy, wtedy nie ma przejscia.
Mozna to oczywiście jeszcze optymalizować (np dodajac dwie listy punktow w
labiryncie), ale powyższe jest najprostszą wersja.
Oczywiście tablice-labirynt trzeba odpowiednio spreparowac czyli ustalić
niezbedna ilość bajtów do reprezentacji, wartosci zastrzezone na
wejscie,wyjscie(a) i sciany.
Np.: dla labiryntu ekranowego(80x25), wystarczą 2bajty na komórkę i np
0xFFFD na wejscie, 0xFFFE na wyjscie oraz 0xFFFF na ścianę.

Poza tym ten algorytm ma tą zaletę że się ładnie wizualizuje :-).

Hobbit
PS. Nie do końca jestem pewien czy kolejne przejścia określic mianem powrotu
czy iteracji, ale poza tym jest OK :-).

--
-------------------------------------|
Krzysztof Swiatkowski - Lodz, Poland | replying cut bezspam from my address
e-Mail:  hobbit@dom.vr.pl.bezspam    | odpowiadajac usun bezspam z adresu

"Kto sie pozno polozy, wczesnie z lozka wyskoczy
ten od tego glupieje i nie widzi na oczy"
>Gra Endera< O.S.Card

On Tue, 6 Jan 1998 10:51:57 +0100, in pl.comp.lang.c Misiu
<michalek@infeco.pb.bialystok.pl> wrote:

>Mam pytanie.
>Pisze program w BC++ 4.52. 
>Czy ListBox ma okreslona pojemnosc?
16-bitowy czyli Win3.1x i Win95 tak maxymalny rozmiar jest wyznaczany przez
wielkość segmentu ->64kb rozmiar elementu to AFAIR 4b co daje max około
16384 elementów. obejśc to można chyba jedynie implementując własną obsługe
listbox'a. Jest na sieci strona poświęcona OWL (chyba
www.pfdpf.state.oh.us/???) i tam bodajże był listbox obsługujący b. duzo
elementów, link do tej strony jest na stronie Piotrka Trzcionkowskiego
(poszukaj gdzieś na pewno wisi jego list z adresem :-) )

HTH
Hobbit

--
-------------------------------------|
Krzysztof Swiatkowski - Lodz, Poland | replying cut bezspam from my address
e-Mail:  hobbit@dom.vr.pl.bezspam    | odpowiadajac usun bezspam z adresu

"Kto sie pozno polozy, wczesnie z lozka wyskoczy
ten od tego glupieje i nie widzi na oczy"
>Gra Endera< O.S.Card

Krzysztof: [pl.comp.lang.c: Wed, 07 Jan 1998 22:23:56 +0100]
:>Nieprawda! Algorytm nierekurencyjny jest bardzo prosty! Oczywiście
:>musi być to algorytm z powrotami, ale nie mysi być rekurencyjny.
: Nie musi, niezbyt oszczędny pamięciowo i czasowo algorytm rozwiązywania
: labiryntu, określany mianem "wypalania stepu" polega na stworzeniu tablicy

no wlasnie, ten algorytm jest bardzo kosztowny...

czas ma tragiczny (kwadrat zamiast liniowego - do powierzchni labiryntu);
jesli labirynt jest np. 100x100 to zamiast 10tys krokow (pare sekund) masz
100mln krokow (pare dni...)

niech on zrobi ten wariant z kolejka... max rozmiar kolejki to obwod
planszy;

pozdrawiam :-)
robert
-- 
robmar@mimuw.edu.pl                  http://zls.mimuw.edu.pl/~robmar/
,,Człowiek bowiem, który posiada oswojonego smoka, 
                 cieszy sie z natury rzeczy powszechnym szacunkiem.''

On 8 Jan 1998 15:51:38 GMT, in pl.comp.lang.c Robert Maron
<robmar@domek.slodki.domek> wrote:

>Krzysztof: [pl.comp.lang.c: Wed, 07 Jan 1998 22:23:56 +0100]
>:>Nieprawda! Algorytm nierekurencyjny jest bardzo prosty! Oczywiście
>:>musi być to algorytm z powrotami, ale nie mysi być rekurencyjny.
>: Nie musi, niezbyt oszczędny pamięciowo i czasowo algorytm rozwiązywania
>: labiryntu, określany mianem "wypalania stepu" polega na stworzeniu tablicy
>
>no wlasnie, ten algorytm jest bardzo kosztowny...
>
>czas ma tragiczny (kwadrat zamiast liniowego - do powierzchni labiryntu);
>jesli labirynt jest np. 100x100 to zamiast 10tys krokow (pare sekund) masz
>100mln krokow (pare dni...)
 :-))). Można go bardzo drastycznie zoptymalizować tworząc dwie listy,
pierwsza w której będą właśnie sprawdzane pozycje na labiryncie, i druga do
której są zapisywane pozycje do sprawdzenia w następnym kroku. Rozmiar
żadnej z list nie przekroczy max ilości ścieżek. Algorytm zaczniemy
wpisaniem położenia wejścia do pierwszej listy i dalej lecimy tak jak
poprzednio opisałem, sądze że byłoby to szybsze od algorytmu z powrotami.
Choć nadal jest to kwestia tablicy, ale dla niedużych labiryntów
(powierzchnia poniżej 65530 :-) ) to i tak jest tylko troszkę więcej niż
potrzeba na przechowanie opisu labiryntu.

Przy tej wersji labiryntu warto przyjąc wejscie jako 0x0001.


Hobbit
>
>niech on zrobi ten wariant z kolejka... max rozmiar kolejki to obwod
>planszy;
A może lepiej nie :-)

Hobbit

--
-------------------------------------|
Krzysztof Swiatkowski - Lodz, Poland | replying cut bezspam from my address
e-Mail:  hobbit@dom.vr.pl.bezspam    | odpowiadajac usun bezspam z adresu

"Rzeczywistosc jest dla tych biedakow, ktorzy nie radza sobie z fikcja"

On Wed, 7 Jan 1998, Jacek Pietraszek wrote:

> Dariusz Michalek wrote:
> > Misiu wrote:
> > > wszystko bylo OK. Czy ListBox ma okreslona pojemnosc?
> > Tak, przynajmniej ten 16-bitowy. Mozna zaladowac do niego ok 7-8 tys.
> > elementow i wlasciwie nie wiadomo dlaczego akurat tyle.
> 
> Do 16-bitowego kontenera mozesz zaladowac
> dokladnie 16383 elementow = 65535 DIV 4
> (wektor adresow). Prawdopodobnie ListBox
> trzyma dwie takie listy na jednym wektorze
> i stad masz tylko polowe, czyli 8191 elementow.
> 
> Pozdrawiam,
> 
> Jacek Pietraszek
> 
>

Serdeczne dzieki wszystkim za cenna wiadomosc, choc mimo iz nie
sprawdzilem ile tak naprawde elementow pakuje do ListBox'a to nie
sadze ze na jakimkolwiek moim dysku znajduje sie chocby 5000 katalogow.
Jestem prawie pewien ze nie ma tylu wkladanych przez mnie elementow.
Czy jest jeszcze inne wytlumaczenie na takie zachowanie LB?
Nie wiem ile jest w tym prawdy ale ktos mi podpowiadal ze w kompilatorze
Borlanda podczas szukania katalogow (FindFirst i FN) kiedy napotkany
zostanie katalog "dziwny" czyli na przyklad
NAZWAKATALOGU.JEGOROZSZERZENIE lub inna dziwna jego postac to kompilator 
wariuje. Moze i tym razem tak jest, no bo jezeli w BC++3.01 funkcja
dziala jak trzeba a kladzie moj program w BC++4.52 i do tego tylko 
dla pewnych dyskow....?

Z gory dziekuje za wszelka pomoc.

Michal Mielech
michalek@infeco.pb.bialystok.pl

Krzysztof Swiatkowski <hobbit@dom.vr.pl.bezspam> wrote:
:  :-))). Można go bardzo drastycznie zoptymalizować tworząc dwie listy,
: pierwsza w której będą właśnie sprawdzane pozycje na labiryncie, i druga do
: której są zapisywane pozycje do sprawdzenia w następnym kroku. Rozmiar
: żadnej z list nie przekroczy max ilości ścieżek. Algorytm zaczniemy
: wpisaniem położenia wejścia do pierwszej listy i dalej lecimy tak jak
: poprzednio opisałem, sądze że byłoby to szybsze od algorytmu z powrotami.
: Choć nadal jest to kwestia tablicy, ale dla niedużych labiryntów
: (powierzchnia poniżej 65530 :-) ) to i tak jest tylko troszkę więcej niż
: potrzeba na przechowanie opisu labiryntu.

:>niech on zrobi ten wariant z kolejka... max rozmiar kolejki to obwod
:>planszy;
: A może lepiej nie :-)

wlasnie opisales troche udziwniony algorytm z kolejka, tylko zamiast kolejki
uzywasz stosu (bo pewnie jego nazywasz ,,listą'')

pozdrawiam :-)
robert
-- 
robmar@mimuw.edu.pl                    http://zls.mimuw.edu.pl/~robmar/

On 9 Jan 1998 12:06:42 GMT, in pl.comp.lang.c Robert Maron
<robmar@mimuw.edu.pl> wrote:

>wlasnie opisales troche udziwniony algorytm z kolejka, tylko zamiast kolejki
>uzywasz stosu (bo pewnie jego nazywasz ,,listą'')
To chyba musiało mi zeżreć ten list po drodze bo nie mam tu nigdzie takiego
opisu.

Hobbit

--
-------------------------------------|
Krzysztof Swiatkowski - Lodz, Poland | replying cut bezspam from my address
e-Mail:  hobbit@dom.vr.pl.bezspam    | odpowiadajac usun bezspam z adresu

"Seks pomiedzy mezczyzna i kobieta moze byc czyms wspanialym
pod warunkiem, ze znajdziesz sie pomiedzy odpowiednia kobieta
i odpowiednim mezczyzna" - Woody Allen