You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Phil Steitz <ph...@steitz.com> on 2004/01/08 14:06:27 UTC

[math] Bug fixes

I would like to fix PR #25972 and tidy up a few other things.  Any 
objections to my adding myself to STATUS and committing, or shall I 
submit patches?

Phil


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Re: [math] Bug fixes

Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
I hadn't realized there were any open bugs on the bugzilla.

Go for it, just commit your work. :-)

-Mark

Phil Steitz wrote:
> I would like to fix PR #25972 and tidy up a few other things.  Any 
> objections to my adding myself to STATUS and committing, or shall I 
> submit patches?
> 
> Phil

-- 
Mark Diggory
Software Developer
Harvard MIT Data Center
http://osprey.hmdc.harvard.edu

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Re: [math] Bug fixes

Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.

Phil Steitz wrote:
> 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.
> 

sounds good.

> <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).
> 
> 

Why not use URL.openStream() and wrap it in an InputStreamReader? Then 
the stream can generically come from any resource reachable by URL (ie, 
a file in the filesystem, in a jar, or as a resource on the classpath, 
http, ftp, etc).

public void openReplayFile() throws IOException {
     filePointer = new BufferedReader(
	new java.io.InputStreamReader(
		valuesFileURL.openStream()
		)
	);
    }

Besides, URL.getFile() returns the string representation of the path 
plus the query in the URL. If the URL doesn't represent a File, this 
code will break if handed any other protocol.

-M.

-- 
Mark Diggory
Software Developer
Harvard MIT Data Center
http://osprey.hmdc.harvard.edu

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Re: [math] Bug fixes

Posted by Phil Steitz <ph...@steitz.com>.
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


Re: [math] Bug fixes

Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
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.

254     /***
255      * Opens <code>valuesFilePath</code> to use in REPLAY_MODE.
256      *
257      * @throws IOException if an error occurs opening the file
258      */
259     public void openReplayFile() throws IOException {
260         filePointer = new BufferedReader(new FileReader
261                             (new File(valuesFileURL.getFile())));
262     }
263
264     /***
265      * Closes <code>valuesFilePath</code> after use in REPLAY_MODE.
266      *
267      * @throws IOException if an error occurs closing the file
268      */
269     public void closeReplayFile() throws IOException {
270         if (filePointer != null) {
271             filePointer.close();
272             filePointer = null;
273         }
274     }

339     private double getNextReplay() throws IOException {
340         String str = null;
341         if (filePointer == null) {
342             throw new IllegalStateException("replay file not open");
343         }
344         if ((str = filePointer.readLine()) == null) {
345             closeReplayFile();
346             openReplayFile();
347             str = filePointer.readLine();
348         }
349         return new Double(str).doubleValue();
350     }


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.
> 
> 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?
> 
> -Mark
> 
> Phil Steitz wrote:
> 
>> Al Chou wrote:
>>
>>> --- Phil Steitz <ph...@steitz.com> wrote:
>>>
>>>> I would like to fix PR #25972 and tidy up a few other things.  Any 
>>>> objections to my adding myself to STATUS and committing, or shall I 
>>>> submit patches?
>>>>
>>>> Phil
>>>
>>>
>>>
>>>
>>> I don't understand why the bug report is filed against Math, but I'm 
>>> fine with
>>> you going ahead, Phil.
>>
>>
>>
>> ValueServer is a class in the o.a.c.m.random package. I agree with 
>> Bill that this class and EmpiricalDistribution should have been 
>> implemented using streams instead of File objects.
>>
>> Phil
>>
>>>
>>>
>>> Al
>>>
>>> =====
>>> Albert Davidson Chou
>>>
>>>     Get answers to Mac questions at http://www.Mac-Mgrs.org/ .
>>>
>>> __________________________________
>>> Do you Yahoo!?
>>> Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
>>> http://hotjobs.sweepstakes.yahoo.com/signingbonus
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
> 

-- 
Mark Diggory
Software Developer
Harvard MIT Data Center
http://osprey.hmdc.harvard.edu

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Re: [math] Bug fixes

Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
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.

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?

-Mark

Phil Steitz wrote:

> Al Chou wrote:
> 
>> --- Phil Steitz <ph...@steitz.com> wrote:
>>
>>> I would like to fix PR #25972 and tidy up a few other things.  Any 
>>> objections to my adding myself to STATUS and committing, or shall I 
>>> submit patches?
>>>
>>> Phil
>>
>>
>>
>> I don't understand why the bug report is filed against Math, but I'm 
>> fine with
>> you going ahead, Phil.
> 
> 
> ValueServer is a class in the o.a.c.m.random package. I agree with Bill 
> that this class and EmpiricalDistribution should have been implemented 
> using streams instead of File objects.
> 
> Phil
> 
>>
>>
>> Al
>>
>> =====
>> Albert Davidson Chou
>>
>>     Get answers to Mac questions at http://www.Mac-Mgrs.org/ .
>>
>> __________________________________
>> Do you Yahoo!?
>> Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
>> http://hotjobs.sweepstakes.yahoo.com/signingbonus
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 

-- 
Mark Diggory
Software Developer
Harvard MIT Data Center
http://osprey.hmdc.harvard.edu

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Re: [math] Bug fixes

Posted by Al Chou <ho...@yahoo.com>.
--- Phil Steitz <ph...@steitz.com> wrote:
> Al Chou wrote:
> > --- Phil Steitz <ph...@steitz.com> wrote:
> > 
> >>I would like to fix PR #25972 and tidy up a few other things.  Any 
> >>objections to my adding myself to STATUS and committing, or shall I 
> >>submit patches?
> >>
> >>Phil
> > 
> > 
> > I don't understand why the bug report is filed against Math, but I'm fine
> with
> > you going ahead, Phil.
> 
> ValueServer is a class in the o.a.c.m.random package. I agree with Bill 
> that this class and EmpiricalDistribution should have been implemented 
> using streams instead of File objects.
> 
> Phil

OK, I see now.  I just didn't recognize the class name or the functionality.


Al

__________________________________
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Re: [math] Bug fixes

Posted by Phil Steitz <ph...@steitz.com>.
Al Chou wrote:
> --- Phil Steitz <ph...@steitz.com> wrote:
> 
>>I would like to fix PR #25972 and tidy up a few other things.  Any 
>>objections to my adding myself to STATUS and committing, or shall I 
>>submit patches?
>>
>>Phil
> 
> 
> I don't understand why the bug report is filed against Math, but I'm fine with
> you going ahead, Phil.

ValueServer is a class in the o.a.c.m.random package. I agree with Bill 
that this class and EmpiricalDistribution should have been implemented 
using streams instead of File objects.

Phil

> 
> 
> Al
> 
> =====
> Albert Davidson Chou
> 
>     Get answers to Mac questions at http://www.Mac-Mgrs.org/ .
> 
> __________________________________
> Do you Yahoo!?
> Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
> http://hotjobs.sweepstakes.yahoo.com/signingbonus
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 




---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Re: [math] Bug fixes

Posted by Al Chou <ho...@yahoo.com>.
--- Phil Steitz <ph...@steitz.com> wrote:
> I would like to fix PR #25972 and tidy up a few other things.  Any 
> objections to my adding myself to STATUS and committing, or shall I 
> submit patches?
> 
> Phil

I don't understand why the bug report is filed against Math, but I'm fine with
you going ahead, Phil.


Al

=====
Albert Davidson Chou

    Get answers to Mac questions at http://www.Mac-Mgrs.org/ .

__________________________________
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org