On Mon, 12 May 2003, O'brien, Tim wrote:
> Date: 12 May 2003 15:41:47 0500
> From: "O'brien, Tim" <tobrien@transolutions.net>
> ReplyTo: Jakarta Commons Developers List <commonsdev@jakarta.apache.org>
> To: Jakarta Commons Developers List <commonsdev@jakarta.apache.org>
> Subject: Re: [math] Re: [PROPOSAL] Commonsmath  organization of
> initial code base
>
> On Mon, 20030512 at 15:17, robert burrell donkin wrote:
> > that's fine by. (i'd say that) the issue is whether we have an optional
> > maven build or whether the maven build is the primary and we generate the
> > ant build file.
>
> How about this as a proposal. If it is decided to build the project
> site via Maven, then Maven will be required to build the site. Ant and
> Maven will always be available to build identical releases. In other
> words, our contract should be that running "ant dist" or "maven
> dist:build" should produce the same output.
>
> It may be premature to switch to Maven as a primary build tool. It is
> still in Beta, and there are many developers who don't have the time to
> drop everything and install a new build tool.
>
A correctly functioning build.xml is a prequisite for my script that
creates nightly builds of all the Commons packages. Since "math" has one,
nighly builds will commence this evening:
http://jakarta.apache.org/builds/jakartacommons/nightly/commonsmath/
Craig
>
>
> >
> > BTW remember to add yourself to the STATUS.html and the PROPOSAL.html
> > files.
> >
> >  robert
> >
> > On Monday, May 12, 2003, at 08:39 PM, O'brien, Tim wrote:
> >
> > > Robert, Phil,
> > >
> > > I added a basic project.xml stolen from the codec sandbox. Running
> > > "maven dist:build" will compile/test/package binary and source releases
> > > for commonsmath version 1.0dev. I didn't mean to jump start the
> > > mavenization discussion, I don't think we need to commit to a maven
> > > generated site, but the fact that I don't have to maintain a separate
> > > build.properties to point to JUnit is convenient.
> > >
> > > Tim
> > >
> > >
> > > On Mon, 20030512 at 14:09, robert burrell donkin wrote:
> > >> hi phil
> > >>
> > >> could you remember to prefix all posts about math with [math] (most
> > >> people
> > >> use filters on the subject).
> > >>
> > >> i think i like the idea of breaking down into relatively selfcontained
> > >> subpackages. it seems that there might be later a need to be able to
> > >> break down into smaller, self contained libraries and if we're
> > >> disciplined
> > >> from the start that's got to help.
> > >>
> > >> i've committed some initial code submitted by phil so there's now
> > >> something to start arguing about :)
> > >>
> > >>  robert
> > >>
> > >> On Monday, May 12, 2003, at 03:28 PM, Phil Steitz wrote:
> > >>
> > >>> I am thinking along the following lines re organization of the initial
> > >>> codebase for commonsmath(assuming we decide to move forward). Since
I
> > >>> am trying to refactor the various odds and ends that I have to
> > >>> contribute
> > >>> along these lines, I would appreciate some feedback on the structure.
> > >>> Obviously,this is a very preliminary "straw man." Any and all ideas
are
> > >>> welcome.
> > >>>
> > >>> Highlevel organization
> > >>> 
> > >>>
> > >>> commonsmath
> > >>> analysis
> > >>> complex
> > >>> discrete
> > >>> linear
> > >>> simulation
> > >>> stat
> > >>>
> > >>> Contents of the subpackages
> > >>> 
> > >>> Everything could probably initially be placed in one package, but I
> > >>> would
> > >>> like to at least settle on a conceptual model for how things are
> > >>> organized. It might also make sense in some cases to separate out an
> > >>> "Impl" package for different implementation strategies.
> > >>>
> > >>> analysis
> > >>> 
> > >>> Commonlyused univariate numerical analysis techniques and useful
> > >>> formulas extending java.Math
> > >>>
> > >>> Target for initial release:
> > >>>
> > >>> * root finding
> > >>> * polynomial interpolation
> > >>> * error bounds estimation
> > >>> * exponential growth and decay computations (set up for financial
> > >>> applications)
> > >>>
> > >>>
> > >>> complex
> > >>> 
> > >>> Representation and algebraic operations on complex numbers
> > >>>
> > >>> Target for initial release:
> > >>>
> > >>> * basic complex number class with algebraic operations
> > >>>
> > >>>
> > >>> discrete
> > >>> 
> > >>> Basic methods and models from discrete math
> > >>>
> > >>> Target for initial release:
> > >>>
> > >>> * binomial coefficients
> > >>>
> > >>>
> > >>> linear
> > >>> 
> > >>> Most commonly used numerical linear algebra techniques
> > >>>
> > >>> Target for the initial release:
> > >>>
> > >>> * basic real matrix class including algebraic operations and
> > >>> support for solving linear systems
> > >>>
> > >>>
> > >>> simulation
> > >>> 
> > >>> Mathematical tools to support simulation
> > >>>
> > >>> Target for the initial release:
> > >>>
> > >>> * Data generation class capable of generating random numbers
> > >>> from uniform, gaussian, poisson, or exponential distributions; by
> > >>> replaying data from an input file; by resampling from a vector; or
by
> > >>> generating random values from an empirical distribution
> > >>> based on an input file.
> > >>>
> > >>> stat
> > >>> 
> > >>> Commonlyused statistical techniques
> > >>>
> > >>> Target for the initial release:
> > >>>
> > >>> * Univariate  simple runningsums based univariate stats and
> > >>> confidence intervals not requiring all data values to be stored in
> > >>> memory and supporting a "rolling" capability (capability to base
> > >>> statistics on most recently observed values)
> > >>> * Frequencies  simple frequency counts/distribution.
> > >>> * Regression  simple linear regression and bivariate corellation
> > >>> * Tests  ttest, chisquare test
> > >>> * Sampling  select random samples with/without replacement from
> > >>> Collections
> > >>> * Resampling  boostrap confidence intervals
> > >>>
> > >>>
> > >>> Phil
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> 
> > >>> To unsubscribe, email: commonsdevunsubscribe@jakarta.apache.org
> > >>> For additional commands, email: commonsdevhelp@jakarta.apache.org
> > >>>
> > >>
> > >>
> > >> 
> > >> To unsubscribe, email: commonsdevunsubscribe@jakarta.apache.org
> > >> For additional commands, email: commonsdevhelp@jakarta.apache.org
> > >>
> > >
> > >
> > >
> > > 
> > > To unsubscribe, email: commonsdevunsubscribe@jakarta.apache.org
> > > For additional commands, email: commonsdevhelp@jakarta.apache.org
> > >
> >
> >
> > 
> > To unsubscribe, email: commonsdevunsubscribe@jakarta.apache.org
> > For additional commands, email: commonsdevhelp@jakarta.apache.org
> >
>
>
>
> 
> To unsubscribe, email: commonsdevunsubscribe@jakarta.apache.org
> For additional commands, email: commonsdevhelp@jakarta.apache.org
>
>

To unsubscribe, email: commonsdevunsubscribe@jakarta.apache.org
For additional commands, email: commonsdevhelp@jakarta.apache.org
