commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From (O'brien, Tim)
Subject Re: [math][PATCH] was Re: [math] exceptions or NaN from Univariate
Date Wed, 14 May 2003 16:49:38 GMT
On Wed, 2003-05-14 at 10:31, Mark R. Diggory wrote:
> > 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.  

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

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.

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

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message