Re^4: Strategy for randomizing large files via sysseek

The main benefit of course is that there is less code to test/maintain,...

I was kind of pleased with how simple the code was.

On a lesser note I am not convinced that your solution will fairly shuffle the lines, even after a second pass...

Indeed, you are correct, it does not produce a fair shuffle. It is capable (with a minor correction to the untested code) of producing every possible combination--which I equated in my mind with "fair".

Thanks for calling me to book and making me think about it harder.

However, given the OP's info of at least 1GB of data, of maximum length around 50 chars, then there are at least 20 million records. To produce all possible permutations of shuffle is 20000000!. With factorial( 1000 ) looking something like:

4023872600770937735437024339230039857193748642107146325437999104299385
+123986290205920442084869694048004799886101971960586316668729948085589
+013238296699445909974245040870737599188236277271887325197795059509952
+761208749754624970436014182780946464962910563938874378864873371191810
+458257836478499770124766328898359557354325131853239584630755574091142
+624174743493475534286465766116677973966688202912073791438537195882498
+081268678383745597317461360853795345242215865932019280908782973084313
+928444032812315586110369768013573042161687476096758713483120254785893
+207671691324484262361314125087802080002616831510273418279777047846358
+681701643650241536913982812648102130927612448963599287051149649754199
+093422215668325720808213331861168115536158365469840467089756029009505
+376164758477284218896796462449451607653534081989013854424879849599533
+191017233555566021394503997362807501378376153071277619268490343526252
+000158885351473316117021039681759215109077880193931781141945452572238
+655414610628921879602238389714760885062768629671466746975629112340824
+392081601537808898939645182632436716167621791689097799119037540312746
+222899880051954444142820121873617459926429565817466283029555702990243
+241531816172104658320367869061172601587835207515162842255402651704833
+042261439742869330616908979684825901254583271682264580665267699586526
+822728070757813918581788896522081643483448259932660433676601769996128
+318607883861502794659551311565520360939881806121385586003014356945272
+242063446317974605946825731037900840244324384656572450144028218852524
+709351906209290231364932734975655139587205596542287497740114133469627
+154228458623773875382304838656889764619273838149001407673104466402598
+994902222217659043399018860185665264850617997023561938970178600408118
+897299183110211712298459016419210688843871218556461249607987229085192
+968193723886426148396573822911231250241866493531439701374285319266498
+753372189406942814341185201580141233448280150513996942901534830776445
+690990731524332782882698646027898643211390835062170950025973898635542
+771967428222487575867657523442202075736305694988250879689281627538488
+633969099598262809561214509948717012445164612603790293091208890869420
+285106401821543994571568059418727489980942547421735824010636774045957
+417851608292301353580818400969963725242305608559037006242712434169090
+041536901059339838357779394109700277534720000000000000000000000000000
+000000000000000000000000000000000000000000000000000000000000000000000
+000000000000000000000000000000000000000000000000000000000000000000000
+000000000000000000000000000000000000000000000000000000000000000000000
+00000000000000
[download]

And the processing taking around 15 minutes/GB, is unlikely that the lack of fairness is going to be a factor :).

That said, the OP's requirement to remove duplicates (rather than just not produce them) means a sort is required anyway, so it all becomes moot.

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

Comment on Re^4: Strategy for randomizing large files via sysseek Download Code

Replies are listed 'Best First'.
Re^5: Strategy for randomizing large files via sysseek by bluto (Curate) on Sep 13, 2004 at 19:12 UTC
I was kind of pleased with how simple the code was. FWIW, I agree. So while I had ++'d it, I wanted to offer another solution to the OP. As I get older, and probably more cynical, I worry about writing code solutions to problems that can be solved with trivial to implement unix solutions (i.e. I see unix tools as old CPAN modules that still work well). I'm not saying that new code is bad, but just that in these types of cases there needs to be a significant advantage in writing code by hand since there is additional brainpower invested (esp. over time) into the solution. Perhaps your solution will significantly outperform the shell script solution for really large files, in that case the extra maintenance cost might be worth it for some. Update:Minor format fix.	[reply]

Replies are listed 'Best First'.

Re^5: Strategy for randomizing large files via sysseek
by bluto (Curate) on Sep 13, 2004 at 19:12 UTC

I was kind of pleased with how simple the code was.

FWIW, I agree. So while I had ++'d it, I wanted to offer another solution to the OP. As I get older, and probably more cynical, I worry about writing code solutions to problems that can be solved with trivial to implement unix solutions (i.e. I see unix tools as old CPAN modules that still work well).

I'm not saying that new code is bad, but just that in these types of cases there needs to be a significant advantage in writing code by hand since there is additional brainpower invested (esp. over time) into the solution. Perhaps your solution will significantly outperform the shell script solution for really large files, in that case the extra maintenance cost might be worth it for some.

Update:Minor format fix.

[reply]