commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Phil Steitz" <p...@steitz.com>
Subject Re: [math] Bug fixes
Date Fri, 09 Jan 2004 02:29:21 GMT
Mark R. Diggory wrote:
> 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message