I wrote:

By the way, I name that delay the LLLIBGBINIOIKV, and represent myself as the founder of it. You have no control over it.
Bwahahahahahahahahaha

I wrote:

Well, that's too bad.

define letters (start) to (finish) of (word) // pretend this is a reporter
if <(start) = (finish)> then
  report (letter (start) of (word))
else
  report (letters ((start)+(1)) to (finish) of (word))

define letters (start) to (finish) of (word) 
set [result v] to []
set [i v] to (start)
repeat ((finish) - (start))
  set [result v] to (join (result) (letter (i) of (word)))
end

ErnieParke wrote:

Why is everyone using George Street Shuffle in their projects?

scimonster wrote:

define letters (start) to (finish) of (word) 
set [result v] to []
set [i v] to (start)
repeat until <(i) > (finish)>  //Better
  set [result v] to (join (result) (letter (i) of (word)))
  change [i v] by (1) //You forgot this
end

TPAL125 wrote:

ErnieParke wrote:

Why is everyone using George Street Shuffle in their projects?

I… Don't…. Know…


Kevin Macleod is forcing me to do it… I think…



I still don't know.

ErnieParke wrote:

_____________________________________________________________________________________________________
Anyway, just to say, earlier today I had implemented recursion in my project and it actually seems to be going slower because of it (which is why I removed it). From what I've seen, it looks like recursion is faster then a repeat block if Scratch isn't facing any big CPU loads, but if Scratch is lagging, recursion isn't such a good idea anymore.

With regards,

ErnieParke

ProdigyZeta7 wrote:

[…scimonster's script, fixed…]

Now I need to figure out a way of recursion for string calculation…

define letters (start) to (finish) of (word) 
set [result v] to [] // note this is blank, not a space!
set [i v] to (start)
repeat ( ( (finish)-(start) ) + (1) ) // needs an extra one added
  set [result v] to (join (result) (letter (i) of (word)))
  change [i v] by (1)
end

ProdigyZeta7 wrote:

scimonster wrote:

define letters (start) to (finish) of (word) 
set [result v] to []
set [i v] to (start)
repeat until <(i) > (finish)>  //Better
  set [result v] to (join (result) (letter (i) of (word)))
  change [i v] by (1) //You forgot this
end

Fixed.

Now I need to figure out a way of recursion for string calculation…

turkey3 wrote:

ProdigyZeta7 wrote:

scimonster wrote:

define letters (start) to (finish) of (word) 
set [result v] to []
set [i v] to (start)
repeat until <(i) > (finish)>  //Better
  set [result v] to (join (result) (letter (i) of (word)))
  change [i v] by (1) //You forgot this
end

Fixed.

Now I need to figure out a way of recursion for string calculation…

What type of string calculation?

ask [Enter an expression to calculate] and wait
Calculate (answer)
ask (result) and wait

define Calculate (string)
separate into two (string)
???  //Um...
if <(op) = [+]>
  set [result v] to ((num1) + (num2))
end
//and so on...

define separate into two (string)
something to separate into two strings from the "pivot" operation
??? //Absolutely clueless here

TPAL125 wrote:

ErnieParke wrote:

_____________________________________________________________________________________________________
Anyway, just to say, earlier today I had implemented recursion in my project and it actually seems to be going slower because of it (which is why I removed it). From what I've seen, it looks like recursion is faster then a repeat block if Scratch isn't facing any big CPU loads, but if Scratch is lagging, recursion isn't such a good idea anymore.

With regards,

ErnieParke

But how do you know that recursion is slower than looping? - in the lagging part I mean.


Have you already tested it?

DadOfMrLog wrote:

Regarding recursion, it's something I would normally avoid if something can be done reasonably simply without it. Since it has to store some kind of current ‘environment’ and ‘return’ information each time it enters a new level so it knows how to ‘jump back’ up to the previous level, it's eventually got to have some degree of negative impact - your memory is limited, so too many will of course cause a crash.
______________________________________________________________________________
Also due to this extra overhead, I doubt recursion would normally be quicker than a loop. Note too, for recursion you need a condition test to stop it (otherwise infinite -> crash, as above). But a repeat loop can (often) be a known number of times (repeat N), which is significantly quicker than interpreting the condition script every time at the next recursion level.
______________________________________________________________________________

ErnieParke wrote:

TPAL125 wrote:

ErnieParke wrote:

_____________________________________________________________________________________________________
Anyway, just to say, earlier today I had implemented recursion in my project and it actually seems to be going slower because of it (which is why I removed it). From what I've seen, it looks like recursion is faster then a repeat block if Scratch isn't facing any big CPU loads, but if Scratch is lagging, recursion isn't such a good idea anymore.

With regards,

ErnieParke

But how do you know that recursion is slower than looping? - in the lagging part I mean.


Have you already tested it?

Yes, I have tested it. From what I saw, without recursion, I got a rendering time of 15- seconds. With the recursion, I got 17+ seconds. That might not seem like much, but in some projects, it can mean quite a bit. And because of it, I was able to improve the iteration depth of the Mandelbrot set from 20 to 30. (my main goal is speed, though I like some quality)

With regards,

ErnieParke

TPAL125 wrote:

ErnieParke wrote:

TPAL125 wrote:

ErnieParke wrote:

_____________________________________________________________________________________________________
Anyway, just to say, earlier today I had implemented recursion in my project and it actually seems to be going slower because of it (which is why I removed it). From what I've seen, it looks like recursion is faster then a repeat block if Scratch isn't facing any big CPU loads, but if Scratch is lagging, recursion isn't such a good idea anymore.

With regards,

ErnieParke

But how do you know that recursion is slower than looping? - in the lagging part I mean.


Have you already tested it?

Yes, I have tested it. From what I saw, without recursion, I got a rendering time of 15- seconds. With the recursion, I got 17+ seconds. That might not seem like much, but in some projects, it can mean quite a bit. And because of it, I was able to improve the iteration depth of the Mandelbrot set from 20 to 30. (my main goal is speed, though I like some quality)

With regards,

ErnieParke

Have you tested both on making a list? If you have, show the list, and hopefully that's enough to make the recursion faster.

TPAL125 wrote:

First up, what is recursion?

This.


Basically, it's where the define block goes inside itself, wrapping it up in many layers of blocks, without having to



… Do that.

jgatcomb wrote:

TPAL125 wrote:

First up, what is recursion?

This.


Basically, it's where the define block goes inside itself, wrapping it up in many layers of blocks, without having to



… Do that.

Recursion is an extremely powerful tool to have. With that said, I disagree with the conclusions you are making about it being faster than an iterative solution.

I would not have written that long if/else chain. Instead I would have written:

repeat until <not recursion> = 3000 {
next costume
change recursion by 1
}

This points out another issue. Your iterative version and your recursive version aren't doing the same unit of work (the iterative version changes costumes every time recursion changes by 1 but your recursive version doesn't change until it reaches 3000).

I am not saying there aren't situations where recursion is faster. There are programming languages (functional languages like Haskell) where there aren't any loops (you have to use recursion). These languages have been optimized to make recursion fast.

In most imperative languages (like Scratch), there is a lot of overhead to set up recursion so I suspect more often then not, when you find it faster it is because the iterative and recursive implementations aren't equivalent.

There are some problems that it is easier to write a recursive version than an iterative version (Towers of Hanoi, Depth First Search, etc) but the iterative versions are almost always faster.

Cheers,
Joshua

Some Guy wrote:

Replace the define blocks with broadcast.