Path: csiph.com!news.swapon.de!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Tim Rentsch
Newsgroups: comp.lang.c
Subject: Re: filling area by color atack safety
Date: Sun, 24 Mar 2024 10:24:45 -0700
Organization: A noiseless patient Spider
Lines: 67
Message-ID: <86jzlrk0f6.fsf@linuxsc.com>
References: <86h6h3nvyz.fsf@linuxsc.com> <865xxiok09.fsf@linuxsc.com> <20240319131842.00002138@yahoo.com> <86o7b9ms7d.fsf@linuxsc.com> <20240320115416.00001ab5@yahoo.com> <86zfusltwp.fsf@linuxsc.com> <20240324193352.000062e9@yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Info: dont-email.me; posting-host="ba786330f332cc3d5ff45a8f861eda2e"; logging-data="527788"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/x/uQzdxH8vHKpG1A1cvglrlZIzuPwJGA="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:pgLq89Hyh8D6GOqoW5kVgTj2VdQ= sha1:3v5697zL3d0xUIz2Md/cCYOlGCA=
Xref: csiph.com comp.lang.c:383962
Michael S writes:
> On Wed, 20 Mar 2024 10:01:10 -0700
> Tim Rentsch wrote:
>
>> Michael S writes:
[...]
>>> Generally, I like your algorithm.
>>> It was surprising for me that queue can work better than stack, my
>>> intuition suggested otherwise, but facts are facts.
>>
>> Using a stack is like a depth-first search, and a queue is like a
>> breadth-first search. For a pixel field of size N x N, doing a
>> depth-first search can lead to memory usage of order N**2,
>> whereas a breadth-first search has a "frontier" at most O(N).
>> Another way to think of it is that breadth-first gets rid of
>> visited nodes as fast as it can, but depth-first keeps them
>> around for a long time when everything is reachable from anywhere
>> (as will be the case in large simple reasons).
>
> For my test cases the FIFO depth of your algorithm never exceeds
> min(width,height)*2+2. I wonder if existence of this or similar
> limit can be proven theoretically.
I believe it is possible to prove the strict FIFO algorithm is
O(N) for an N x N pixel field, but I haven't tried to do so in
any rigorous way, nor do I know what the constant is. It does
seem to be larger than 2.
As for finding a worst case, try this (expressed in pseudo code):
let pc = { width/2, height/2 }
// assume pixel field 'field' starts out as all zeroes
color 8 "legs" with the value '1' as follows:
leg from { 1, pc.y-1 } to { pc.x -1, pc.y-1 }
leg from { 1, pc.y+1 } to { pc.x -1, pc.y+1 }
leg from { px.x + 1, pc.y-1 } to { width-2, pc.y-1 }
leg from { px.x + 1, pc.y+1 } to { width-2, pc.y+1 }
leg from { px.x - 1, 1 } to { px.x -1, pc.y-1 }
leg from { px.x + 1, 1 } to { px.x +1, pc.y-1 }
leg from { px.x - 1, pc.y+1 } to { px.x -1, height/2 }
leg from { px.x + 1, pc.y+1 } to { px.x +1, height/2 }
So the pixel field should look like this (with longer legs for a
bigger pixel field), with '-' being 0 and '*' being 1:
+-----------------------+
| - - - - - - - - - - - |
| - - - - * - * - - - - |
| - - - - * - * - - - - |
| - - - - * - * - - - - |
| - * * * * - * * * * - |
| - - - - - - - - - - - |
| - * * * * - * * * * - |
| - - - - * - * - - - - |
| - - - - * - * - - - - |
| - - - - * - * - - - - |
| - - - - - - - - - - - |
+-----------------------+
Now start coloring at the center point with a new value
of 2.