[ANN] Uncommons Maths 1.0.2 (Random number generators and other utilities)

D

Daniel Dyer

For anyone who may find them useful, I've created a standalone Open Source
project out of the Java random number generators (and a few other
mathematical utility classes) that I've written/ported. These were
originally part of my evolutionary computation library, but I think they
are more widely applicable than that project, so I've separated them out..

Project announcement:
http://blog.uncommons.org/?p=43

API Documentation:
https://uncommons-maths.dev.java.net/nonav/api/index.html

Thanks,

Dan.
 
H

Hendrik Maryns

Daniel Dyer schreef:
For anyone who may find them useful, I've created a standalone Open
Source project out of the Java random number generators (and a few other
mathematical utility classes) that I've written/ported. These were
originally part of my evolutionary computation library, but I think they
are more widely applicable than that project, so I've separated them out.

Project announcement:
http://blog.uncommons.org/?p=43

API Documentation:
https://uncommons-maths.dev.java.net/nonav/api/index.html

Hi Daniel,

I have some combinatorics classes that partly overlap with your
o.u.maths package. You might be interested in including the ones you
don’t have, however. I do not really care about the license, you can
change it at will (the header says GPL now).

They can be found at
http://tcl.sfs.uni-tuebingen.de/~hendrik/Java/Combinatorics/Combinatorics.jar,
Javadoc at
http://tcl.sfs.uni-tuebingen.de/~hendrik/Java/Combinatorics/doc/index.html

Cheers, H.
--
Hendrik Maryns
http://tcl.sfs.uni-tuebingen.de/~hendrik/
==================
http://aouw.org
Ask smart questions, get good answers:
http://www.catb.org/~esr/faqs/smart-questions.html


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4-svn0 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFHRf0Je+7xMGD3itQRAvTHAJ4kxNEHvdpsyXbeHMQ6ggbf1BMQHwCfbu6G
MgFWK8FNiZrkCUw2oqe9Xcs=
=KKrE
-----END PGP SIGNATURE-----
 
R

Roedy Green


Having a look over that, it looks like a significant contribution to
the Java community. On behalf of everyone, thanks for doing that.

Writing a random number generators for various distributions has been
on my todo list for years, too far down to have any hope of
implementation.

I have added links to it from a number of points in the Java glossary.
 
D

Daniel Dyer

I have some combinatorics classes that partly overlap with your
o.u.maths package. You might be interested in including the ones you
don’t have, however. I do not really care about the license, you can
change it at will (the header says GPL now).

They can be found at
http://tcl.sfs.uni-tuebingen.de/~hendrik/Java/Combinatorics/Combinatorics.jar,
Javadoc at
http://tcl.sfs.uni-tuebingen.de/~hendrik/Java/Combinatorics/doc/index.html

Hendrik, thanks for this. I took a look at your Javadocs. One thing that
immediately occurred to me is that I should have made my permutations and
combinations classes Iterable like yours. I will make this change and as
soon as I get the chance I will also see if I can integrate your Cartesian
Product and variator classes.

Thanks again,

Dan.
 
A

Andrew Thompson

Daniel said:
For anyone who may find them useful, I've created a standalone Open Source
project out of the Java random number generators (and a few other
mathematical utility classes) that I've written/ported.

Sounds interesting. Have you considered offering a JWS
based demo. of the classes*? I'd be happy to help with any
JWS specific questions.

* One in particular that occurs to me, is seeing a 'Gaussian'
distribution plot filled with ..well a Gaussian distribution of
random results from the relevant class.

--
Andrew Thompson
http://www.physci.org/

Message posted via JavaKB.com
http://www.javakb.com/Uwe/Forums.aspx/java-general/200711/1
 
H

Hendrik Maryns

Daniel Dyer schreef:
Hendrik, thanks for this. I took a look at your Javadocs. One thing
that immediately occurred to me is that I should have made my
permutations and combinations classes Iterable like yours.

Well, the not so nice part is that my classes implement both Iterable
and Iterator.

This makes it possible to do

for (State[] stateArr : new VariatiorWithRepetition(inputArray, length)){
// process stateArr
}

but semantically, it is a bit strange. There was a discussion on this
group about this when I asked some questions about it:
http://groups.google.com/group/comp...cf35d59e29c0?hl=en&lnk=st&q=#b73dcf35d59e29c0.
Chris Uppal made some good points there. (With a light blush I have to
admit I didn’t do the rewrite yet, as you can see in the jar.)

That is the risk of publishing a library like this: people get to expect
stuff from you…

I will make
this change and as soon as I get the chance I will also see if I can
integrate your Cartesian Product and variator classes.

What I like much is that the Combinator, Permuter and Variator classes
all derive from the CombinatoricOperator class, implementing/overriding
only two or three methods (there definitely is a name for this design
pattern, I just don’t know which one). Unfortunately, it is not obvious
how to make the Cartesian class derive from this. It might be worth it
to make the base class more general to be able to do this, if one wants
more classes that return moredimensional arrays.

H.
--
Hendrik Maryns
http://tcl.sfs.uni-tuebingen.de/~hendrik/
==================
http://aouw.org
Ask smart questions, get good answers:
http://www.catb.org/~esr/faqs/smart-questions.html


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4-svn0 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFHRwT9e+7xMGD3itQRAvmLAJ9TwvXC4SCqCzaX0C5XYkewx0VMewCeOA/P
IN86BgzMjFj+3T/VWCCfC/M=
=+EuR
-----END PGP SIGNATURE-----
 
D

Daniel Dyer

Sounds interesting. Have you considered offering a JWS
based demo. of the classes*? I'd be happy to help with any
JWS specific questions.

No, I hadn't considered it. I guess it would be fairly straightforward
using JFreeChart. I've used WebStart a couple of times so I'm OK with the
basics. But are you sure you wouldn't prefer an applet? ;)
* One in particular that occurs to me, is seeing a 'Gaussian'
distribution plot filled with ..well a Gaussian distribution of
random results from the relevant class.

It shouldn't take much more effort to allow the user to select any of the
available distributions and specify a number of iterations, and then plot
the generated values.

I'll add it to my TODO list. Of course, if an interested user were to
contribute some code, it may happen sooner... :)

Dan.
 
D

Daniel Dyer

Daniel Dyer schreef:
Hendrik, thanks for this. I took a look at your Javadocs. One thing
that immediately occurred to me is that I should have made my
permutations and combinations classes Iterable like yours.

Well, the not so nice part is that my classes implement both Iterable
and Iterator.

This makes it possible to do

for (State[] stateArr : new VariatiorWithRepetition(inputArray, length)){
// process stateArr
}

but semantically, it is a bit strange. There was a discussion on this
group about this when I asked some questions about it:
http://groups.google.com/group/comp...cf35d59e29c0?hl=en&lnk=st&q=#b73dcf35d59e29c0.
Chris Uppal made some good points there. (With a light blush I have to
admit I didn’t do the rewrite yet, as you can see in the jar.)

I've added Iterable to my implementations. I pretty much agree with the
conclusions of that thread. I don't need to implement Iterator directly
and if I did it would confuse matters because I named my methods
differently from those in the Iterator interface (I went overboard on the
nextXXXX() methods). Instead the iterator() method just returns an
instance of an anonymous inner class that delegates to my
differently-named methods. One other advantage of not implementing
Iterator in the outer class is that you don't end up with a useless
remove() method in the API.
What I like much is that the Combinator, Permuter and Variator classes
all derive from the CombinatoricOperator class, implementing/overriding
only two or three methods (there definitely is a name for this design
pattern, I just don’t know which one).

Sounds like Template Method
(http://en.wikipedia.org/wiki/Template_method_pattern).
Unfortunately, it is not obvious
how to make the Cartesian class derive from this. It might be worth it
to make the base class more general to be able to do this, if one wants
more classes that return moredimensional arrays.

Are there use cases in which it is useful to be able to refer to these
classes as CombinatoricOperators rather than their concrete types? For
example, are there algorithms where the outline doesn't change but you
want to be able to plug-in either a Combinator or a Permuter? If that is
the case, I could see why the common base class is useful (other than for
avoiding duplication of common aspects of the implementations). However,
it might be possible simply to use Iterable (or Iterator) as the more
general type in those situations (unless you need the reset() method).

BTW, what generates the pre- and post-conditions in your Javadocs? Do you
have a custom Taglet or Doclet that you use?

Dan.
 
A

Andrew Thompson

Daniel Dyer wrote:
...
...But are you sure you wouldn't prefer an applet? ;)

No 'stirring' now! ;-)

...
I'll add it to my TODO list. Of course, if an interested user were to
contribute some code, it may happen sooner... :)

I hear ya', and am mildly inerested (been meaning to look into
JFreeChart for a *long* time), but I also have a very 'full plate'
of projects before me..

--
Andrew Thompson
http://www.physci.org/

Message posted via JavaKB.com
http://www.javakb.com/Uwe/Forums.aspx/java-general/200711/1
 
A

Andrew Thompson

Daniel Dyer wrote:

(Java Web Start demo)
I decided to give it a go and I've just uploaded a first version. There's
a few small things that still need to be tweaked, but it's basically
working.

https://uncommons-maths.dev.java.net/demo/demo.jnlp

Now *that* is what I'm talkin' about. Way Cool.

A picture paints a thousand words - and 100,000
iterations paints a very nice Gaussian distribution
curve. :)

It's interesting to see how 'outliers' cause a different
scaling in different iterations.

The GUI is pretty clear and useable, though some
oddities occur if I shrink it to ridiculously thin. It
might pay to set a minimum size.

BTW - do us a favor and add this property to the
resources section of the JNLP, if you will.

<property
name='java.awt.Window.locationByPlatform'
value='true' />

--
Andrew Thompson
http://www.physci.org/

Message posted via JavaKB.com
http://www.javakb.com/Uwe/Forums.aspx/java-general/200711/1
 
A

Andrew Thompson

Andrew said:
(Java Web Start demo) ..
...
The GUI is pretty clear and useable, though some
oddities occur if I shrink it to ridiculously thin.

Most of which can probably be fixed by by dropping the
widgets in the NORTH of a JPanel in a (floatable) JToolBar.
You might even consider arranging them in a column and
puttting the JToolBar in EAST/WEST of the main GUI.

And while I have you attention, an 'RFE'. An option to lock
the plotwidth to the minimum required for *either* side of the
mean value - so it is locked in the center, despite the
overall plotting width becoming thinner or wider.

--
Andrew Thompson
http://www.physci.org/

Message posted via JavaKB.com
http://www.javakb.com/Uwe/Forums.aspx/java-general/200711/1
 
D

Daniel Dyer

Most of which can probably be fixed by by dropping the
widgets in the NORTH of a JPanel in a (floatable) JToolBar.
You might even consider arranging them in a column and
puttting the JToolBar in EAST/WEST of the main GUI.

Yeah, there are a few things to tidy up. I just started with FlowLayouts
for the controls because it was easy to get things roughly right.
And while I have you attention, an 'RFE'. An option to lock
the plotwidth to the minimum required for *either* side of the
mean value - so it is locked in the center, despite the
overall plotting width becoming thinner or wider.

I'll have to check the JFreeChart API docs, but I'm pretty sure that is
reasonably straightforward. I also want to constrain the X-axis labels to
integers for the discrete distributions and to label the graphs with the
expected and observed means and standard deviations.

I also have a problem with the way I plotted the Exponential
distribution. The red line doesn't start in the right place, which is an
artifact of the quantization that I employed.

Dan.
 
H

Hendrik Maryns

Daniel Dyer schreef:
Daniel Dyer schreef:
Hendrik, thanks for this. I took a look at your Javadocs. One thing
that immediately occurred to me is that I should have made my
permutations and combinations classes Iterable like yours.

Well, the not so nice part is that my classes implement both Iterable
and Iterator.

This makes it possible to do

for (State[] stateArr : new VariatiorWithRepetition(inputArray, length)){
// process stateArr
}

but semantically, it is a bit strange. There was a discussion on this
group about this when I asked some questions about it:
http://groups.google.com/group/comp...cf35d59e29c0?hl=en&lnk=st&q=#b73dcf35d59e29c0.

Chris Uppal made some good points there. (With a light blush I have to
admit I didn’t do the rewrite yet, as you can see in the jar.)

I've added Iterable to my implementations. I pretty much agree with the
conclusions of that thread. I don't need to implement Iterator directly
and if I did it would confuse matters because I named my methods
differently from those in the Iterator interface (I went overboard on
the nextXXXX() methods). Instead the iterator() method just returns an
instance of an anonymous inner class that delegates to my
differently-named methods. One other advantage of not implementing
Iterator in the outer class is that you don't end up with a useless
remove() method in the API.

Good solution, I’ll have to take that over some time.
Are there use cases in which it is useful to be able to refer to these
classes as CombinatoricOperators rather than their concrete types? For
example, are there algorithms where the outline doesn't change but you
want to be able to plug-in either a Combinator or a Permuter? If that
is the case, I could see why the common base class is useful (other than
for avoiding duplication of common aspects of the implementations).
However, it might be possible simply to use Iterable (or Iterator) as
the more general type in those situations (unless you need the reset()
method).

I was only thinking about code duplication, no use cases of that sort
pop up.
BTW, what generates the pre- and post-conditions in your Javadocs? Do
you have a custom Taglet or Doclet that you use?

Yes. It was provided to us in a course about OO programming at
university. It overrides @return such that you can have multiple ones,
and defines the pre- and postconditions, and renders that pseudocode a
bit differently. Inspired by Eiffel, which was sort of the ideal
language, according to the professor, but he had to do the course in
Java, for economical reasons…

I sent him an e-mail asking whether those can be downloaded somewhere,
or whether I can send you the files I still have, thought these are
probably a bit old by now.

Cheers, H.
--
Hendrik Maryns
http://tcl.sfs.uni-tuebingen.de/~hendrik/
==================
http://aouw.org
Ask smart questions, get good answers:
http://www.catb.org/~esr/faqs/smart-questions.html


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4-svn0 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFHSuTCe+7xMGD3itQRAlESAJwNitakJMvVno4VlbVAXupm6+UL+wCdFLV+
MWhSJRhlCMkWOP179VA1oLQ=
=8yJi
-----END PGP SIGNATURE-----
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,755
Messages
2,569,535
Members
45,007
Latest member
obedient dusk

Latest Threads

Top