[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: how to print all 3 char length string made whitespace {0..9} {a..z}

From: Marco Ippolito
Subject: Re: how to print all 3 char length string made whitespace {0..9} {a..z}
Date: Fri, 7 Aug 2020 01:06:28 -0300
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.11.0

On 06/08/2020 06:05, Mike Jonkmans wrote:
On Thu, Aug 06, 2020 at 12:46:08AM -0300, Marco Ippolito wrote:
On 02/08/2020 18:10, Mike Jonkmans wrote:

Are you lookiung for this?
        echo {{a..z},\ ,{0..9}}{{a..z},\ ,{0..9}}{{a..z},\ ,{0..9}}

I was going to recommend this:

e=({a..z} ' ' {0..9}); l=${#e[@]}; for ((i=0; i<l; i++)); do for ((j=0; j<l;
j++)); do for ((y=0; y<l; y++)); do printf "${e[i]}${e[j]}${e[y]} "; done;
done; done

to make the space complexity, or memory footprint, of it depend linearly
rather than exponentially (even if just to the 3rd power), on the input,
allowing more characters in the set to be permuted (e.g. Chinese characters)
without segfaulting on malloc.

Marco Ippolito

Hmm, my echo should have been be a printf "%s\n".

Both solutions seem to work.

The for-solution does take 4x longer to run though (when piped to wc -c).
When printed to the terminal, the difference in runtime is rather large.
At my desktop it is running 10 minutes (versus 0.2 seconds).
Calling printf repeatedly - 50653 times - makes the difference.

Kind of a memory-time tradeoff.

Regards, Mike Jonkmans

Rather than a memory <-> execution-time tradeoff I thought of it in terms of "which input does the approach allow?". As a slower algorithm returns "too late to be useful" and an eager memory allocator segfaults after consuming all swap, both extremes become impractical. I preferred the growth rate of the loop Vs that of the expansion-in-memory as I imagined the application to be "try to do <something> with a string of length N assembled from M characters, considering all permutations", which - as he said "generate" rather than _print_, didn't make me worry about calling printf, otherwise I'd have used an accumulation buffer flushed to the output stream multiple times as it fills, sized to be under memory constraints, reducing the overhead of the calls you highlighted. Probably a recursive function to allow K nested iterations and produce a string of length K, as it was repetitive to write the "for" keyword 3 times.

I think the original poster's requirements lend themselves to interpretation as to their actual use case though.

Marco Ippolito

reply via email to

[Prev in Thread] Current Thread [Next in Thread]