commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark R. Diggory" <mdigg...@latte.harvard.edu>
Subject Re: [math][PATCH] was Re: [math] exceptions or NaN from Univariate
Date Wed, 14 May 2003 17:31:14 GMT


O'brien, Tim wrote:
> On Wed, 2003-05-14 at 10:31, Mark R. Diggory wrote:
> <snip/> 
> 
>>>I do see that if window == Integer.MAX_VALUE no storage is used, but I'm
>>>wondering if we might want to put this into another implementation -
>>>this implementation should also provide Mode.
>>>
>>
>>Possibly even higher order moments like kurtosis and skew.
> 
> 
> I guess my suggestion is that (if my reasoning is right) there are
> pieces of information such as Mode which demand knowledge of each
> element. If we are going to implement something with storage, it might
> make more sense to keep it separate from the existing implementation. 
> Also, one implementation should delegate to an existing Array or List.  
> 
> Think about someone maintaining a JMX MBean which maintains a List of
> one usage statistic.  I could image that a Univariate that takes a
> reference to an existing List or array could come in handy.  Someone
> makes some changes to the a List or array, and calculations are
> performed every time a Median, Mode, etc. is needed.  Someone who has
> this requirement clearly has different performance and storage needs
> than someone building a system with very limited memory limitations.  
> 

True...

> 
>>>I'd like to get a sense from [math] of whether we should modify
>>>Univariate in place or make Univariate an interface and provide multiple
>>>implementations. 
>>>
>>
>>In my opinion, I'm not sure there would be enough other implmentations 
>>to warrant this.
> 
> 
> There are many ways to skin a cat. (such a horrible image)

What a terrible thing to say ;-)

> Having a
> Univariate interface and corresponding implementations would leave the
> door open to people who might have different approaches or ideas.  It
> would also adhere to principle of "Maximizing abstractions to maximize
> stability".
> 
> Also, let's think about a utility that would calculate the covariance of
> two sets of numbers.  I'd rather have that operate on Two
> StoredUnivariate interfaces than have to worry about operating on
> concrete classes.
> 

Again, very legitamate.

> 
>>>Also, using Integer.MAX_VALUE makes practical sense, but <snip/>
>>
>>Theres a limitation here on the size of the array itself we're dealing 
>>with. whats the largest int[] you can have in Java? This is a cap on 
>>"int" and array capabilities, having a Window of 
>>"Double.POSITIVE_INFINITY - 1" is impossible from an array size 
>>standpoint, even having a Window of Integer.MAX_VALUE + 1 is impossible, 
>>an array "Integer.MAX_VALUE - 1" is theoretically possible. 
>>Integer.MAX_VALUE is the cap (although difficult to achieve with todays 
>>memory constraints).
>>
> 
> 
> I understand that array size limitations may get in the way, but today's
> exabyte is tomorrow's kilobyte.  My point was conceptual, but I do think
> it important to shy away from choosing constants that could conceivably
> attain real meaning - even if that meaning is currently impractical.

Point taken. I've actually eliminated the constant in my implementation 
in favor of testing the "null" state of values array.
> 
> 
> ---------------------------------------------------------------------
> 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


Mime
View raw message