Re: Quicksort

On Jan 6, 5:49 am, Roman Töngi <roman.toe...@xxxxxxxxxx> wrote:
Quicksort is a typical recursive procedure.
It can, of course, also be implemented iteratively
by remembering the indices (left, right) with a stack.

So, there should be no significant gain in storage space
(compared to the systems local stack) but in speed because there
are no function calls.

Is this thinking justified?

Not imo. I've tested an iterative version of Quicksort, and it was
just slightly faster. IMO it wasn't
worth the bother of ensuring that the stack space was adequate. Also,
the recursive version is a beauty.
The iterative version is certainly not.

.

Relevant Pages

  • Re: Mint news...
    ... There's no downside. ... Storage space ... about the size of a large-ish brick. ... And a $2000.00 stack ...
    (rec.collecting.coins)
  • Re: Possible Bluetooth SerialPort Issue?
    ... IMO, Bluetooth implementations vary, even when using the same stack! ... just seems to be technology that isn't quite finished -- after all these ... I suspect that your "hack" is as reasonable as any approach. ...
    (microsoft.public.dotnet.framework.compactframework)
  • Re: Building an app for both 16bit and 32bit TCPIP stacks
    ... gcc3-CRTL applications require 32-bit stack? ... I think I used firefox with Warp3 (but can't be sure; ... That's, IMO, a broken logic. ... EMX is a well-designed system. ...
    (comp.os.os2.programmer.misc)
  • Re: realpath(3) et al
    ... >>Features such as a protected stack should, IMO, be implemented as soon as ... >>OpenBSD has implemented this already and there are many patches for Linux to ... > stack non-executable is trivial, making the system still work isn't. ... > I believe the FreeBSD signal handling still relies on a signal ...
    (FreeBSD-Security)