The float function attempts to convert the value of obj into a floating point number. The type of obj can be int or any other type that can be converted to float.

The int function attempts to convert the value of obj into an integer number. The type of obj can be float or any other type that can be converted to int.

	int n2 = int(3.5/2)   // OK; n2 is equal to 1
	int n1 = 3.5/2;       // Error: type mismatch

Schedule is for phases as use() is for agents. Schedule iterates through the argument list and appends each phase to a global ``schedule''. Polyclt and polysrv will follow that schedule and will stop execution when all phases are completed.

	#include "phases.pg"  // import some useful phases
	Phase phMeas = { ... };
	schedule(phWait, phMeas, phCool); // build a schedule

If you call schedule() with an array instead of an individual phase, the array gets interpolated as if all its items were explicitly listed as actual parameters.

The schedule() procedure can be called more than once.

Use iterates through the argument list and marks each agent or pipe as being ``in use''. The polyclt, polysrv, and piper tools will ignore objects without the ``in use'' mark.

	Server S = { .... };
	Server S2 = { .... };
	Robot R = { ... };
	NetPipe pipe;
	use(S, R);
	use(pipe); 
	// Server S2 will be ignored

If you call use() with an array instead of an individual objects, the array gets interpolated as if all its items were explicitly listed as actual parameters.

	Server[] servers = place(S, srv_ips);
	Robot[] robots = place(R, rbt_ips);
	use(servers, robots);

The use() procedure allows you to create a library of robots, servers, and pipes but use only some subset of those objects.

The use() procedure can be called more than once.

Use working_set_length() call to limit the size of URL space (a.k.a. ``working set'' size). Polygraph constantly introduces new objects into the working set to simulate cachable misses. By default, the working set will grow indefinitely. In other words, more and more URLs will have a non-zero probability of being re-visited. This unlimited growth may eventually decrease memory hit ratio and even disk hit ratio (both due to finite cache sizes).

It is often convenient and desirable to limit the size of the working set. We specify that limit in terms of time (rather than number of objects or their total size) because that makes the limit independent from cache capacity or request rate. In other words, when two very different caches are subjected to the same time-based limit, the workload is ``fair''.

The working_set_length() call essentially specifies for how long a cache needs to store fill stream to achieve optimal hit ratio during the entire experiment. If a cache cannot hold all traffic generated during working_set_length time, then it is almost guaranteed to have sub-optimal hit ratio later, because some of the re-visited objects will not be in the cache.

	time len = 4hour;
	working_set_length(len);

Specifying working_set_length larger than experiment duration does not have any effect (the set will grow during the entire run then). One can think of the first working_set_length minutes of the experiment as of a ``warm-up'' phase. Experiment enters its ``steady state'' only after the working set size is frozen.