Re^3: 'ls -C' column style (sideways)

I didn't write it this way for performance reasons. But this technique should have good performance when sorting items across instead of down.

You can also make it faster with a bit of complication by teaching it to consider about 2N^.5 column counts rather than about N/2 of them.

- tye

Comment on Re^3: 'ls -C' column style (sideways)

Replies are listed 'Best First'.
Re^4: 'ls -C' column style (sideways) by BrowserUk (Patriarch) on Nov 05, 2004 at 02:33 UTC
Neither did I, I was just curious about your "This one loops over the list of items once (at most)." claim. Knowing mine makes several passes, I wondered how they compared. I (think) I see that you actually do make 2 passes: 1 to determine the no. of columns; 1 to do the formatting. I'm not sure what you mean by the 2N^.5 bit? No matter how I bracket that, it always comes out to 74 compared to 37/2 = 18 or 19. The problem with limiting the columns in that way is that you miss the edge case where the entire list will format into 1 row--and split it across 2. The reason mine arrives at the answer quicker in all but the smallest widths case, is that I come at from the other end. I iterate the rows 1 .. N, and calculate the columns. I noticed that in the general case increasing the number of rows until it fit arrived more quickly than increasing the number of columns as it considered less duplicate cases. For best performance, you could probably determine some formula that would indicate which end to start from, but my math ain't that strong. Examine what is said, not who speaks. "Efficiency is intelligent laziness." -David Dunham "Think for yourself!" - Abigail "Memory, processor, disk in that order on the hardware side. Algorithm, algorithm, algorithm on the code side." - tachyon	[reply]

Replies are listed 'Best First'.

Re^4: 'ls -C' column style (sideways)
by BrowserUk (Patriarch) on Nov 05, 2004 at 02:33 UTC

Neither did I, I was just curious about your "This one loops over the list of items once (at most)." claim. Knowing mine makes several passes, I wondered how they compared. I (think) I see that you actually do make 2 passes: 1 to determine the no. of columns; 1 to do the formatting.

I'm not sure what you mean by the 2N^.5 bit? No matter how I bracket that, it always comes out to 74 compared to 37/2 = 18 or 19.

The problem with limiting the columns in that way is that you miss the edge case where the entire list will format into 1 row--and split it across 2.

The reason mine arrives at the answer quicker in all but the smallest widths case, is that I come at from the other end. I iterate the rows 1 .. N, and calculate the columns.

I noticed that in the general case increasing the number of rows until it fit arrived more quickly than increasing the number of columns as it considered less duplicate cases. For best performance, you could probably determine some formula that would indicate which end to start from, but my math ain't that strong.

Examine what is said, not who speaks.

"Efficiency is intelligent laziness." -David Dunham
"Think for yourself!" - Abigail
"Memory, processor, disk in that order on the hardware side. Algorithm, algorithm, algorithm on the code side." - tachyon

[reply]