These are offshoots of ICSIM.

Please send any questions to gomes@icsi.berkeley.edu.

get_opt.sa:


Designed for parsing command line options of the form
[- option value]*
and translates them into calls on registered bound routines.

The general way to use it is
opt_parser ::= #GET_OPT;
opt_parser.add_option("optionname",#ROUT(foo(_)));
opt_parser.add_option("optionname2",#ROUT(bar(_)));
To read in the options:
opt_parser.read_from_file("filename");
or
opt_parser.read("-optionname ption for the string -optionname2 etc");
This calls the bound routine associated with each option with the value of the option (cast to one of the known types).

It recognizes bound routines of the following types
ROUT{BOOL}, ROUT{INT}, ROUT{FLT} and ROUT{STR}

params.sa

Very similar to get_opt.sa, but expects parameters with the syntax paramname=paramvalue;

Different syntaxes can be defined for the same tast by similarly including GET_OPT and redefining the routine read_option (which will call call_function with a and string).

graph.sa

First cut at some graph classes.

Interesting features

If anybody does use this class, I'd love to get feedback. I think there is nothing particularly controversial about the implementation, just routine naming. Also, if anyone else has written graph classes that are more extensive or have different functionality, I would be very interested in using/incorporating them.

One issue is how much the node index stuff should be exposed and what the naming convention should be. It is essential to expose some of it so that algorithms that use the graph class may be efficient.

I've used the convention that all the features with "obvious" names (incoming outgoing etc.) take and return node arguments. Features names with either _index and _indices as their suffix take node index arguments.

No point in doing the $GRAPH classes until we have dispatched iters.

DIGRAPH{N}
Directed graph with nodes of type N DIGRAPH{N,E}
Edges also have additional information of type E. Includes from DIGRAPH{N}