Re: filling area by color atack safety - worst memory size

From	Tim Rentsch <tr.17687@z991.linuxsc.com>
Newsgroups	comp.lang.c
Subject	Re: filling area by color atack safety - worst memory size
Date	2024-04-19 14:59 -0700
Organization	A noiseless patient Spider
Message-ID	<86a5lpxbd3.fsf@linuxsc.com> (permalink)
References	(11 earlier) <20240411152033.00007173@yahoo.com> <86bk6ez9te.fsf@linuxsc.com> <20240417004609.000010aa@yahoo.com> <86plunyj82.fsf@linuxsc.com> <20240417224126.0000727a@yahoo.com>

Show all headers | View raw

Michael S <already5chosen@yahoo.com> writes:

> On Wed, 17 Apr 2024 10:47:25 -0700
> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>
>> Michael S <already5chosen@yahoo.com> writes:
>>
>> [...]
>>
>>> Finally found the time for speed measurements.  [...]
>>
>> I got these.  Thank you.
>>
>> The format used didn't make it easy to do any automated
>> processing.  I was able to get around that, although it
>> would have been nicer if that had been easier.
>>
>> The results you got are radically different than my own,
>> to the point where I wonder if there is something else
>> going on.
>
> What are your absolute result?
> Are they much faster, much slower or similar to mine?
> Also it would help if you find out characteristics of your
> test hardware.

I think trying to look at those wouldn't tell me anything
helpful.  Too many unknowns.  And still no way to test or
measure any changes to the various algorithms.

>> Considering that, since I now have no way of doing any
>> useful measuring, it seems there is little point in any
>> further development or investigation on my part.  It's
>> been fun, even if ultimately inconclusive.
>
> I am still interested in combination of speed that does
> not suck with O(N) worst-case memory footprint.
> I already have couple of variants of the former,

Did you mean you some algorithms whose worst case memory
behavior is strictly less than O( total number of pixels )?

I think it would be helpful to adopt a standard terminology
where the pixel field is of size M x N, otherwise I'm not
sure what O(N) refers to.

> but so
> far they are all unreasonably slow - ~5 times slower than
> the best.

I'm no longer working on the problem but I'm interested to
hear what you come up with.

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Re: filling area by color atack safety Michael S <already5chosen@yahoo.com> - 2024-03-24 19:33 +0300
  Re: filling area by color atack safety Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-03-24 10:24 -0700
    Re: filling area by color atack safety Michael S <already5chosen@yahoo.com> - 2024-03-25 01:04 +0300
    Re: filling area by color atack safety - worst memory size Michael S <already5chosen@yahoo.com> - 2024-04-05 17:30 +0300
      Re: filling area by color atack safety - worst memory size Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-04-10 19:47 -0700
        Re: filling area by color atack safety - worst memory size Michael S <already5chosen@yahoo.com> - 2024-04-11 15:20 +0300
          Re: filling area by color atack safety - worst memory size Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-04-11 21:06 -0700
          Re: filling area by color atack safety - worst memory size Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-04-11 21:55 -0700
          Re: filling area by color atack safety - worst memory size Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-04-11 22:09 -0700
            Re: filling area by color atack safety - worst memory size Michael S <already5chosen@yahoo.com> - 2024-04-12 11:13 +0300
              Re: filling area by color atack safety - worst memory size Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-04-13 08:30 -0700
          Re: filling area by color atack safety - worst memory size Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-04-11 22:38 -0700
          Re: filling area by color atack safety - worst memory size Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-04-11 22:43 -0700
          Re: filling area by color atack safety - worst memory size Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-04-12 11:59 -0700
            Re: filling area by color atack safety - worst memory size Michael S <already5chosen@yahoo.com> - 2024-04-13 20:26 +0300
              Re: filling area by color atack safety - worst memory size Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-04-13 10:54 -0700
                Re: filling area by color atack safety - worst memory size Michael S <already5chosen@yahoo.com> - 2024-04-13 23:11 +0300
            Re: filling area by color atack safety - worst memory size Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-04-17 10:47 -0700
              Re: filling area by color atack safety - worst memory size Michael S <already5chosen@yahoo.com> - 2024-04-17 22:41 +0300
                Re: filling area by color atack safety - worst memory size Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-04-19 14:59 -0700
                Re: filling area by color atack safety - worst memory size Michael S <already5chosen@yahoo.com> - 2024-04-20 21:10 +0300
                Re: filling area by color atack safety - worst memory size Michael S <already5chosen@yahoo.com> - 2024-04-25 17:56 +0300
                Re: filling area by color atack safety - worst memory size Michael S <already5chosen@yahoo.com> - 2024-05-03 18:33 +0300
                Re: filling area by color atack safety - worst memory size Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-05-15 09:57 -0700

csiph-web