Findbugs was big on this being done, but when I tested I found that
new Xxx was generally faster than Xxx.valueOf (outside of the cache
range) which went against FindBugs and "For values outside the
constant range the performance of both styles is the same. ". My
laptop, JDK 1.5, OS X so hardly a c
+1
I would be happy to fix any issues I find as a user where the inverse
generator isn't good enough. In the meantime, I will at least get some
samples.
On Mon, Oct 26, 2009 at 7:01 PM, Mikkel Meyer Andersen wrote:
>
> And the nextSample() can be implemented in an abstract class providing
> in
There is only one issue left open against DBCP 1.3 and I should be
able to resolve it RSN, so it would be great if others could start
reviewing/cleaning up the code in trunk in prep for the release.
Thanks in advance.
Phil
-
To u
As already stated, I agree with Ted. I think we should have a
nextSample() on the distributions. I'm also concerned that this
creates a need for another part of the library (RNG), but it _is_
already in the library, just like using erf- og gamma-functions. What
about making the RNGImp a thread-safe
Are you against adding any nextSample() method to distributions at all
(regardless of the quality of the implementation)?
Or just unhappy about adding nextSample() hooked to a bad implementation?
The first opinion, I just don't understand. The second can be dealt with by
putting in good implemen
Donald Woods wrote:
>
The only complication, is that we would need to
> offer committership to Roman from Agimatec as soon as the Incubator IP
> clearance is finished, as he would need to be the one to remove the
> existing Agimatec copyright statements. Thoughts?
I am not familiar enough wi
Ted Dunning wrote:
> It is similar to what RandomDataImpl does, but the current type hierarchy is
> a problem because it over-uses that interface/factory/implementation
> pattern.
Explain what you mean. There is one interface and one
implementation for RandomData.
The result is confusing as ca
sebb wrote:
+ * This method is thread-safe, as a volatile
I think it's misleading to call the method thread-safe.
Adding volatile/synch. merely ensures that the new value is published correctly.
The use of a mutable static variable means that the method cannot
really be considered thread-
Mikkel Meyer Andersen wrote:
> Ted: No, I mean with the discrete inverse cdf. But anyway. Thanks for
> clarifying the points.
>
> Phil, if you're not convinced, I'll be happy to provide a
> patch-draft/prototype of code so you can see exactly what I mean?
>
> If we were to put a generator in the
I think that the implementations with specialized generators should just
over-ride the generic generator and do the specialized operation.
I have seen cases where _developers_ think there should be multiple
implementations of random number generators, but I don't think I have ever
seen a case wher
Ted: No, I mean with the discrete inverse cdf. But anyway. Thanks for
clarifying the points.
Phil, if you're not convinced, I'll be happy to provide a
patch-draft/prototype of code so you can see exactly what I mean?
If we were to put a generator in the distributions (for supporting the
specialis
On 26/10/2009, scolebou...@apache.org wrote:
> Author: scolebourne
> Date: Mon Oct 26 21:56:46 2009
> New Revision: 829991
>
> URL: http://svn.apache.org/viewvc?rev=829991&view=rev
> Log:
> LANG-487 - Make default style thread-safe
>
> Modified:
>
> commons/proper/lang/trunk/src/java/or
That was Phil. (not that it matters)
+1 for the idea of a default generator for all distributions that define a
cumulative density.
+1 as well for specialized implementations where possible that over-ride the
default generator even if it exists.
I can't imagine much dispute on either of these po
It is similar to what RandomDataImpl does, but the current type hierarchy is
a problem because it over-uses that interface/factory/implementation
pattern. The result is confusing as can be, especially since virtually all
of the distributions have just one implementation and the factories aren't
po
Ted, sorry hadn't seen your e-mail before sending mine.
Yes, I agree in you point of having specialised good algorithms. But
in lack of such methods, I'd prefer being able to have a general
method, although it might be bad compared to a specialised one.
2009/10/27 Phil Steitz :
> Ted Dunning wrot
Ted Dunning wrote:
> Inverse CDF methods work for discrete distributions as well as continuous
> ones.
Thanks. That's what I was missing. I would still rather see the
implementations in the random package and for common distributions,
e.g. Poisson, pick a method that is well-suited for the distri
Hi Phil.
Yes, I have seen RandomDataImpl and the next{Int, Poisson, ...}, but
as you mention not that many distributions are supported. What I
talked about is kind of the nextInversionDeviate-idea.
I must admit, that I find it a bit weird that the distributions are
separated from the random gener
Inverse CDF methods work for discrete distributions as well as continuous
ones.
On Mon, Oct 26, 2009 at 4:50 PM, Phil Steitz wrote:
> > If not, I would create a public interface
> > DistributionWithInverseCumulativeProbability (who has a better name?)
> > with the method inverseCumulativeProbabi
Mikkel Meyer Andersen wrote:
> Dear community.
>
> I've just started using the Apache Commons Math library. In regards to
> generating random data from probability distributions, the library
> doesn't support generating random data using the inverse cdf method
> although a lot of the distributions
The way you are doing it is exactly the way it works. And if you keep it
up, you will wind up a committer. Then they introduce you to the societies
for helping open source contributors recover from the effects of spending
all their time posting new software.
On Mon, Oct 26, 2009 at 4:13 PM, Mik
Suggestions are happily received! And thanks for all the suggestions.
I haven't really done any open source, so I don't know how this stuff
works :-).
2009/10/27 Ted Dunning :
> Just a suggestion. You are the one doing the patch and should get the final
> word on what you implement.
>
> (and than
Just a suggestion. You are the one doing the patch and should get the final
word on what you implement.
(and thanks from everybody)
On Mon, Oct 26, 2009 at 4:08 PM, Mikkel Meyer Andersen wrote:
> Yes, but I would like to avoid reflection if possible. I'll try to
> have a go, and send the patch
Yes, that was exactly one of the planned "side-effects" :-). If some
distributions prefer to generate random data in another way, explicit
classes in the random-part must be made.
Yes, but I would like to avoid reflection if possible. I'll try to
have a go, and send the patch proposal to the list.
That sounds nice. It also means that more distributions are likely to
benefit "by accident" even if they don't know to advertise what they can do.
It is also plausible to use reflection at class construction time to
determine whether the method is available. That would let
AbstractDistribution u
Hi Ted.
Thanks or your answer.
I like the idea about an abstract class named
DistributionWithInverseCumulativeProbability. But I have to look
closer where in the chain it should be. Because both
AbstractIntegerDistribution and AbstractContinuousDistribution have
the inverse cd method. And both ex
If you define this new interface, can't you just put the correct
implementation of the generator into some abstract class somewhere and make
sure that all of the distributions implement this. That implementation can
check if this extends DistributionWithInverseCumulativeProbability. If it
does, t
Dear community.
I've just started using the Apache Commons Math library. In regards to
generating random data from probability distributions, the library
doesn't support generating random data using the inverse cdf method
although a lot of the distributions gives the possibility to calculate
the i
Hi folks,
I would like to call a vote for releasing commons-email-1.2 based on RC3.
This release candidate has the following changes compared to RC2
+) using an "RC" tag for the M2 release plugin
+) removed commons-logging testing dependency since it is already provided
+) clirr report compares
The amount of time to start over seems like a waste, given we have an
existing ASL 2.0 licensed codebase which is 75-80% done and wanting to
come over to the ASF
-Donald
Mohammad Nour El-Din wrote:
Hi Donald...
If moving the code of Agimatic into ASF going to be problematic why
not
Hi Donald...
If moving the code of Agimatic into ASF going to be problematic why
not to start a clean room implementation as Niall suggested ?
On Mon, Oct 26, 2009 at 4:06 PM, Donald Woods wrote:
> Hi Nail. I'm the one who created that copy of 1.4, so it's fine if we
> repurpose it, see VALI
Hi Nail. I'm the one who created that copy of 1.4, so it's fine if we
repurpose it, see VALIDATOR-279.
As far as the API, we already have a clean room copy of the 1.0 GA API
created over in the Apache Geronimo Specs subproject [1], with the other
Java EE spec APIs we ship, so I'd be -1 on cre
Dear wiki user,
You have subscribed to a wiki page "Commons Wiki" for change notification.
The page Pool has been reverted to revision 14 by sebbapache.
The comment on this change is: DeSpam.
http://wiki.apache.org/commons/Pool?action=diff&rev1=15&rev2=16
On 25/10/2009, Henri Yandell wrote:
> On Sun, Oct 25, 2009 at 4:02 AM, sebb wrote:
> > On 25/10/2009, Henri Yandell wrote:
> >> On Sat, Oct 24, 2009 at 4:05 AM, Stephen Colebourne
> >> wrote:
> >> > bay...@apache.org wrote:
> >> >>
> >> >> URL: http://svn.apache.org/viewvc?rev=826960&
Hi
There is no svn tag for 1.8.1 release. Create one, please.
Greetings
Grzegorz Slowikowski
Niall Pemberton wrote:
The Commons team is pleased to announce the release of Commons
BeanUtils 1.8.1.
This release contains a number of bug fixes for the 1.8.0 release -
full details of which can
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at gene...@gump.apache.org.
Project commons-email has an issue affecting its community integration.
This issue
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at gene...@gump.apache.org.
Project commons-configuration-test has an issue affecting its community
integrati
Dear Wiki user,
You have subscribed to a wiki page or wiki category on "Commons Wiki" for
change notification.
The "Pool" page has been changed by WilliamNorton.
http://wiki.apache.org/commons/Pool?action=diff&rev1=14&rev2=15
--
= External Reso
Oliver Heger wrote:
Do you think that a generic implementation of the lazy initialization
pattern has such an impact on performance?
In a typical implementation you would add the initializer as a final
member field to a class:
public class MyClass {
private final MyConcreteLazyInitialize
38 matches
Mail list logo
