From: Nathan Baker on

"Daniel T." <daniel_t(a)earthlink.net> wrote in message
news:daniel_t-5C8D00.12442509052010(a)70-3-168-216.pools.spcsdns.net...
>
> But in any case, no more can be said unless a real use-case is
> presented. All I'm saying is that the assumption that three loops are
> necessary to express an O(n) algorithm is inappropriate.

Perhaps the two nested 'for' loops could be justified if their indexes (yInd
and zInd) were to actually "come in to play" within the algo? Otherwise,
they represent wasted (not used for any task that can't be accomplished via
other means) resource allocation.

Maybe if we are doing some sort of gradient-fill where we incredmentally
increase the RGB values of pixels? xInd, yInd, zInd represent the R, G, B
values that we set for each pass of the loop? We stop when we get to a
certain color already present on the screen?

Nathan.


From: Phil Carmody on
"Nathan Baker" <nathancbaker(a)gmail.com> writes:
> "Dave Harris" <brangdon(a)cix.co.uk> wrote in message
> news:memo.20100509163449.5892C(a)brangdon.cix.compulink.co.uk...
>>
>> Yes. It led to simple code, but that was partly because all the
>> complexity was hidden behind an iterator. Nathan Baker's version exposes
>> some of that complexity, and I think illustrates how hard it is to get it
>> right.
>>
>
> Perhaps the words "simple" and "complexity" have different meanings to
> different people because of their different training and the goals they've
> been conditioned to target??
>
> Juha's code uses 3 loop constructs, 4 conditionals, and 2 exit points.
>
> Mine uses 1 loop construct, 2 conditionals, and 1 exit point.

Heading up-thread, the most recent code from you I see is:

"""
while ( data[xInd][yInd][zInd] != value && result != 0)
{
++zInd;
if (( zInd < data[xInd][yInd].size() ) != true ) { zInd = 0; +
+yInd};
if (( yInd < data[xInd].size() ) != true ) { yInd = 0; ++xInd};
if (( xInd < data.size() ) != true ) { result = 0 };
}
"""

Which may have one loop construct, but 9 logical tests - at least 8
of which are performed on every iteration of the loop. Where you get
"2 conditionals" from, I don't know.

Phil

--
I find the easiest thing to do is to k/f myself and just troll away
-- David Melville on r.a.s.f1
From: Nick Keighley on
On 9 May, 09:52, Tim Streater <timstrea...(a)waitrose.com> wrote:
> In article
> <967ab68e-ce6a-4767-8435-6810e10a6...(a)p2g2000yqh.googlegroups.com>,
>  Nick Keighley <nick_keighley_nos...(a)hotmail.com> wrote:
> > On 8 May, 17:46, Tim Streater <timstrea...(a)waitrose.com> wrote:
> > > In article
> > > <5dd9bdc8-4dc4-4537-84a0-885c4c92f...(a)l28g2000yqd.googlegroups.com>,
> > >  Nick Keighley <nick_keighley_nos...(a)hotmail.com> wrote:
> > > > On 8 May, 01:41, Lie Ryan <lie.1...(a)gmail.com> wrote:


> > > > > > I've never heard of any programming languages that doesn't support
> > > > > > recursion.
> >
> > > > FORTRAN (in its original form), Coral-66 you had to use a special
> > > > keyword to indicate a function was recursive. Some BASICs probably
> > > > didn't alow recursion. But these all qualify as "ancient" (and maybe
> > > > jocular!)
>
> > > What FORTRAN are you referring to. I never saw it in any FORTRAN up to
> > > 1978 (the last time I used FORTRAN).
>
> > lost me. So far as I remember FORTRAN didn't have recursion. Am I
> > wrong? Or are you saying even modern Fortran doesn't have recursion?
>
> I'm saying that no FORTRAN that I used (up to 1978, last time I used
> FORTRAN) had recursion or any hint of it. This was on a variety of
> platforms - CDC (6000 series), IBM (7094, 360/370), SIGMA7, ...

so you are agreeeing with me?


From: gwowen on
On May 10, 9:26 am, Tim Streater <timstrea...(a)waitrose.com> wrote:

> Hard to say. Does modern FORTRAN have recursion? No good asking me!

Yes, since Fortran 90.
From: Nathan on
On May 10, 3:38 am, Phil Carmody <thefatphil_demun...(a)yahoo.co.uk>
wrote:
> "Nathan Baker" <nathancba...(a)gmail.com> writes:
> > "Dave Harris" <brang...(a)cix.co.uk> wrote in message
> >news:memo.20100509163449.5892C(a)brangdon.cix.compulink.co.uk...
>
> >> Yes. It led to simple code, but that was partly because all the
> >> complexity was hidden behind an iterator. Nathan Baker's version exposes
> >> some of that complexity, and I think illustrates how hard it is to get it
> >> right.
>
> > Perhaps the words "simple" and "complexity" have different meanings to
> > different people because of their different training and the goals they've
> > been conditioned to target??
>
> > Juha's code uses 3 loop constructs, 4 conditionals, and 2 exit points.
>
> > Mine uses 1 loop construct, 2 conditionals, and 1 exit point.
>
> Heading up-thread, the most recent code from you I see is:
>
> """
> while ( data[xInd][yInd][zInd] != value && result != 0)
> {
>     ++zInd;
>     if (( zInd < data[xInd][yInd].size() ) != true ) { zInd = 0; +
> +yInd};
>     if (( yInd < data[xInd].size() ) != true ) { yInd = 0; ++xInd};
>     if (( xInd < data.size() ) != true ) { result = 0 };}
>
> """
>
> Which may have one loop construct, but 9 logical tests - at least 8
> of which are performed on every iteration of the loop. Where you get
> "2 conditionals" from, I don't know.
>

Oh Fat, I was talking about what I posted on May 6th in reply to Keith
Thompson:

,---
xyzMax = data[xInd][yInd].size() + data[xInd].size() + data.size();
result = 0;
i = -1;
while ( i < xyzMax )
{
++i;
if ( data[i] = value );
{
result = &data[i];
i = xyzMax;
}
}

return result;
`---

Perhaps it did not propagate to all servers?? Anyway, it is buggy and
Dave is correct about it exposing some of the complexity hidden within
Daniel's iterator.

Nathan.