on 6/12/01 9:10 PM, Sivakatirswami at [EMAIL PROTECTED] wrote: >> filter <container> excluding <expression> >> >> It should be one of those things where a relatively small programming effort >> produces a considerable expansion in facility. > > This is very fast: > > repeat for each line x in dataTofilter > if x contains (expression) then > next repeat > else > put x & cr after dataOutPut > end if > end repeat > > put dataOutPut into url "file/processed/theFilteredData.txt" > > I have processed lists up to 120,000 lines with the above in under 2 secs
A tribute to the speed of MC/Rev! but to have the same effect as the proposed 'not filter', you'd have to replace the use of 'contains' with a call to 'matchChunk'. I don't know, but I'd guess the performance hit here could be more substantial; often regular expression matches have to do quite a bit of setup as they parse the expression, and in the absence of the 'not filter', using a routine like that you propose above, this setup cost would be paid 120,000 times in your example, rather than once. I agree - this isn't a case in which we can't do what we want within the current language, it's just something where what seems to be a small change could provide much increased performance. But if I had to choose, I'd rather get features that would unlock things I currently do at all in Rev/MC, like access to styled text in the clipboard, or better printing facilities. Ben Rubinstein | Email: [EMAIL PROTECTED] Cognitive Applications Ltd | Phone: +44 (0)1273-821600 http://www.cogapp.com | Fax : +44 (0)1273-728866 _______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution