Sorry, that may have be a bit naive. More specifically, I know that open/closeReplay file reloads the values file inputstream. I suspect that these are only used in one other location in the ValueServer. Maybe they should be private or consolidated into the getNExtReplay method.
Yes. Open should not be public. What would make sense is a reset() method. The file needs to remain open across calls to getNextReplay(), since REPLAY_MODE amounts to cycling through the "replay file" in sequence repeatedly. Since the file might be large, it is not loaded into memory. This creates the awkward situation of the user needing to close the file, which is why close() needs to be public.
<snip/>
Mark R. Diggory wrote:
Yes, I agree too, although it would be beneficial to maintain so convenience methods that allow one to set the source of the streams to be a File or other often used objects.
Ack. My initial thought is to add another load() to EmpiricalDistribution that takes a URI and modify internals of impls to not use URL.toFile() (which apparently does not work reliably on Windows).
What is the difference between a "replay file" and a "values file"? Do we have to have both of these or is there a way to make it more generic?
The ValueServer can generate values randomly (from various distributions), by "replaying" (cyclically) values from an input file, or from an empirical distribution estimated from the values in a file. Since the "replay file" could be large, it is read sequentially as values are needed and closed and re-opened as necessary.
The "values file" is used to estimate an empirical distribution, so is read once and digested.
Both of these classes were extracted from standalone simulation programs and both predate the distribution framework, so I am sure there are other design improvemements that could be made.
Phil
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
