[REBOL] Re: Block! v List! dilema...
costs of pick, inserting at head and this code: for offset 0 9 1 [ if (start + offset) <= (length? buglist) [ entry: pick buglist (start + offset) ; throw out a table entry to show the bug summary.. ] ] : 1) you work sequentially here? so, why picking? list! should be better in this manner: loop[do-something-with list list: next list] which should be as fast as blocks. like: ;hoping start is very near the buglist-position, otherwise blocks are better list: at buglist start for offset 0 9 1 [ if (start + offset) <= (length? buglist) [ ;not: entry: pick buglist (start + offset) ;but: entry: first list list: next list ; throw out a table entry to show the bug summary.. ] ] 2) list-positions after insertions works a bit different to blocks, you would need some 'head more. usually i find blocks everywhere more surprise-free volker >>>was: [REBOL] Block! v List! dilema... From: Chris (view other messages by this author) Date: Fri, 6 Apr 2001 12:56:55 -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with "unsubscribe" in the subject, without the quotes.
[REBOL] Re: Block! v List! dilema...
#06-Apr-01# Message from *Holger Kruse*: Hi Holger, >> Given that displays vastly outnumber moves, should I just stick with >> blocks? Or does anyone have a better suggestion? > Blocks are probably better. Ok, thanks for the help :) Chris -- New sig in the works Explorer 2260, Designer and Coder http://www.starforge.co.uk -- Good news. Ten weeks from Friday will be a pretty good day. -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with "unsubscribe" in the subject, without the quotes.
[REBOL] Re: Block! v List! dilema...
On Fri, Apr 06, 2001 at 07:09:05PM +, Chris wrote: > Using a block, I guess that pick for a block is an O(1) operation - a > simple array lookup? Yes. > Now the problem - when a user comments on a bug, or a > project admin updates the status of a bug, I want that bug to be moved to > the start of the buglist block. Remembering that this list could end up > being long (probably into the thousands), removing an element in the middle > and inserting it at the start would, I guess, be rather costly. Yes, but it should not be a problem unless you move a large number of elements around in a loop. A single remove/insert only takes a small fraction of a second, even in very large blocks. > The > alternative is to use a list of course: that makes the move very quick, > but what does it do to my display code? Is pick for list still O(1) - I > guess it isn't? No, it is O(n). > Given that displays vastly outnumber moves, should I just stick with blocks? > Or does anyone have a better suggestion? Blocks are probably better. -- Holger Kruse [EMAIL PROTECTED] -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with "unsubscribe" in the subject, without the quotes.
