Reply to thread

Message: [QUOTE="Uri Guttman, post: 4863144"] JE> $h{$a} and $h{$b} exist ===> length($h{$a}) <=> length($h{$a}) JE> $h{$a} exists but $h{$b} doesn't ===> -1 JE> $h{$a} does't exist but $h{$b} does ===> 1 JE> Neither $h{$a} nor $h{$b} exists ===> 0 JE> Different approaches do the same problem. JE> You are favouring reducing/adjusting the data domain such that you can JE> use standard Perl operators while I favour adding a new comparison JE> operator to my data algebra, i.e. I have a given data domain and create JE> the proper comparison operator for that given domain. JE> To me my approach is much cleaner and simpler because I don't have to JE> tweak the data set just to make the comparison work. Also, I am not JE> convinced that your speed argument is correct, but it's really not JE> important enough to write a big benchmark test. JE> To everyone his own, I guess. the prefilter design simplifies the logic no matter how you slice it. one common bug in multi-key sorts is getting the extraction right for each key and also keeping the proper order of comparisons. prefiltering reduces bugs because the extraction is coded one time and not twice with $a and $b. and it keeps the actual comparison code shorter as well so it is easier to manage the key order issues (sort up/down, etc.). as for speed, sort::maker comes with a benchmark script and the ability to generate a typical sort block like you have been doing as well as faster versions. it is easy to find where the breakeven point is for speed. the prefilter design is well known to be much faster for larger data sets and especially so for multi-key and complex sorts. nuff said here, i don't need to defend my point as it has been proven many times. uri [/QUOTE]

Verification