Phil Steitz wrote:
[Yoav] You probably want strictfp:
http://www.jguru.com/faq/view.jsp?EID=17544.
[Phil] I am not sure that we want this, but I am by no means a JVM expert. From what
I understand, the decision comes down to strict consistency of results on different
platforms (mostly involving NaN and other boundary conditions) vs. performance. In
most practical applications, I would personally be more interested in performance. It
would be a major PITA (given the way things have to be declared); but I suppose that
in theory we could support both. I am open to discussion on this, but my vote at this
point would be to release without strictfp support for 1.0.
Its tough that its a modifier and not some sort of JVM option, seems it
would make libraries alot more flexible if you controlled it in the
behavior of the JVM and not something you have to compile into your
code. To provide this functionality such that it could be enabled or
disabled we'ed need to have twin libraries or some sort of "wrapper
methods", one with it in place and the other with it removed.
public strictfp double getStrictMean(...)
public double getMean(...)
Not very elegant.
[Yoav] Out of curiosity, why read each url/file twice?
[Phil] Because the implementation is primitive ;-) The load method of EmpiricalDistribution
needs to 1) compute basic univariate statistics for the whole file and 2) divide the range of
values in the file into a predetermined number of "bins" and compute univariate
statistics for the values in each bin. The simplest way to do this is to pass the data once to
do 1), then use the min and max discovered in 1) to set up the bins and compute the bin stats
in the second pass. Since the files may be large, it is not a good idea to try to load the data
into memory during the first pass. A single pass algorithm would have to either dynamically
adjust the bins (and bin stats) as new extreme values are discovered or take extrema as
arguments. I would prefer not to require the extrema to be specified in advance. The dynamic
bin adjustment would be hard to do efficiently (at least is seems hard to me -- bright ideas /
patches welcome :-)
Phil
Definitly sounds like a great adventure for the next version...
cheers,
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
