Hi!
Is there a faster and less memory eating way to do things than recursion?
Ohmu
Is there a faster and less memory eating way to do things than recursion?
Ohmu
-
-
Re: Faster than recursion
On 30 Aug 2003 15:21:38 -0700, ohmar@hot.ee (Ohmu) wrote:
[color=blue]
>Is there a faster and less memory eating way to do things than recursion?[/color]
What's the C++ question?
-
Re: Faster than recursion
> Is there a faster and less memory eating way to do things than recursion?
Yes
Stephen Howe
Comment
-
Re: Faster than recursion
"Ohmu" <ohmar@hot.ee > wrote in message
news:37c0fd9c.0 308301421.ae93b 5d@posting.goog le.com...[color=blue]
> Hi!
>
> Is there a faster and less memory eating way to do things than recursion?
>
> Ohmu[/color]
It depends on what you are trying to do.
john
Comment
-
Re: Faster than recursion
Ivan Vecerina wrote:
[color=blue]
> Typically yes, in C/C++ as in other procedural languages.
> but it depends on the specific algorithm you want to derecursify.
> Sometimes a recursive call can be replaced by a simple loop.
> Sometimes you need some type of cache/buffer/queue, which
> makes the implementation more complicated.
>
> Maybe you'll want to post a specific example...
>
>
> hth[/color]
Well.. the code I have is tooo messy... I just try to explain what it
does...
There are some squares for example 6x7 and the recursion tryes to find
every possible combination of "x" that can be there without being on
each other way(only one in one column and one row and one in
diagonals)... so the function calls itself where it finds a spot where
the "x" can be put, and so every time until the size of the squares
are reached... but for this 6x7 squares the function calls it self
about 300-600 times.. it eats lot of memory and when the squares are
bigger it takes huge amount of time and loads(in MB) of memory...
Hope you understood :)
Ohmu
Comment
-
Re: Faster than recursion
Ohmu wrote:
[color=blue]
> Is there a faster and less memory eating way to do things than recursion?[/color]
No.
A *good* optimizing C++ compiler will "flatten"
a recursive [inline] function call automatically
if it really can realize an advantage by doing so.
Comment
-
Re: Faster than recursion
Bruce wrote:
[color=blue]
> Sounds a lot like the 8 queens problem. Is that what it is? If so, just
> say so instead of being evasive. Or are you wanting homework done for you?[/color]
eight queen problem?? what's that? no homework that kind...
Comment
-
Re: Faster than recursion
Ohmu wrote:[color=blue]
>
>
> Well.. the code I have is tooo messy... I just try to explain what it
> does...
> There are some squares for example 6x7 and the recursion tryes to find
> every possible combination of "x" that can be there without being on
> each other way(only one in one column and one row and one in
> diagonals)... so the function calls itself where it finds a spot where
> the "x" can be put, and so every time until the size of the squares
> are reached... but for this 6x7 squares the function calls it self
> about 300-600 times.. it eats lot of memory and when the squares are
> bigger it takes huge amount of time and loads(in MB) of memory...[/color]
8 queens problem modified?
This should not take lots of Megabytes and time. Not with
your problem domain.
Sounds more like you have a bug in your function.
--
Karl Heinz Buchegger
kbuchegg@gascad .at
Comment
-
Re: Faster than recursion
"E. Robert Tisdale" <E.Robert.Tisda le@jpl.nasa.gov > wrote in message news:<3F52353B. 8050104@jpl.nas a.gov>...[color=blue]
> Ohmu wrote:
>[color=green]
> > Is there a faster and less memory eating way to do things than recursion?[/color]
>
> No.
>
> A *good* optimizing C++ compiler will "flatten"
> a recursive [inline] function call automatically
> if it really can realize an advantage by doing so.[/color]
Most compilers won't guess at the input parameters, and usually
the decision critically depends on the parameters. Even worse,
once parameters are passed by value, copy ctors may be needed that
can't be elided trivially.
This would be the case if the TS passed his array inside a class
and by value; copying that 42-element array probably stops many
optimizers.
Regards,
--
Michiel Salters
Comment
Comment