To Rev or not to Rev

[Marielle Lange]

Hi Dennis,

There is a trade-off, there. As a researcher, it matters more that something
takes me 1 day rather 5 to progam. It does not matter that much that it takes 1
minute rather than 3 to run (I can always use it as an excuse for a coffee
break). What I frequently need to do is create word frequency tables for a 20MB
corpus by using frequency[tword] (with each word as a string). I have tried
different programming and scripting language and the one I sticked with was
gawk, a non GUI efficient text processor (like Perl, without the unlegible code
syntax). Not to be able to use a string as array index did put me off of Visual
Basic (I found solutions to bypass that but then the program needed 5 hours to
do what gawk could do in less than 20 min.). To be forced to declare the
dimension of the array beforehand put me off of C/C++/Java. One of the reason I
adopted Revolution is that I can construct a GUI (which awk cannot) and still
index my array with a string and don't have to know, in advance, the
approximate number of index values I will need (I was turning to Python and
wxPython just before I learned about Revolution).

I had been poundering on that question before... why not merge Revolution with
Awk? Awk/Gawk is very small (200KB) and is the best program I know to rapidly
handle text (with rapid processing of string-indexed arrays of huge size and
fully fledge regular expression syntax). Revolution is the best program I know
to rapidly handle interface design and internet protocols.

Marielle

>This BZ on arrays would be a welcome enhancement, but it would not
>improve the speed of processing arrays.  I was thinking along the
>lines of a high speed array processing instruction subset.  They
>would be less flexible than what we have now --the nice flexible data
>types, dynamic memory allocation, and flexible key names are what
>costs the operators so much time to execute.  Just let me define the
>dimensions and data size for a fixed memory allocation and provide
>operators that work on fixed data types.  It should fly through the
>array calculations at least ten times faster.  I just entered a BZ
>request for it.  If you agree, vote.

BZ# 2813