RE: [boost] Re: Any interest in a stats class

From: Paul A. Bristow (boost_at_[hidden])
Date: 2003-02-21 13:30:47

http://scicomp.ewha.ac.kr/netlib/cephes/

for example, but many others according to Google.

(My attempts in using F2C were less than satisfying from a style point of view.

NOT Fortran to C++, if one wanted that ...)

Paul

Dr Paul A Bristow, hetp Chromatography
Prizet Farmhouse, Kendal, Cumbria, LA8 8AB  UK
[phone]  Mobile [phone]
mailto:pbristow_at_[hidden]

> -----Original Message-----
> From: boost-bounces_at_[hidden]
> [mailto:boost-bounces_at_[hidden]]On Behalf Of Hubert Holin
> Sent: Monday, February 17, 2003 12:35 PM
> To: boost_at_[hidden]
> Subject: [boost] Re: Any interest in a stats class
>
>
> Somewhere in the E.U., le 17/02/2003
>
> In article <AHEJIHEOOOBMJPAGPLIPKEPMDKAA.boost_at_[hidden]>,
>  "Paul A. Bristow" <boost_at_[hidden]> wrote:
>
> > > -----Original Message-----
> > > From: boost-bounces_at_[hidden]
> > > [mailto:boost-bounces_at_[hidden]]On Behalf Of Hubert Holin
> > > Sent: Friday, February 14, 2003 1:25 PM
> > > To: boost_at_[hidden]
> > > Subject: [boost] Re: Any interest in a stats class
> > >
> > >
> > > Somewhere in the E.U., le 14/02/2003
> > >
> > >
> > >       There still is the question of whether similarity with NR is a
> > > problem or not (the language in which the techniques are implemented is
> > > different, but implementations of the techniques themselves are of
> > > course basically similar since they refer to the same math construction).
> >
> > I cannot see this being a serious problem unless we simply lift the
> NR in C++
> > code verbatim.  (Most of it is still in old C style for one thing, despite
> > the
> > recent reissue).
>
>       Yes, on that front we should be safe, but then IANAL...
>
> > > I am hoping that with uBlas, we can contribute more numerical
> > > stuff. I have some Gaussian Mixture Models code that I should be
> > > rewriting in the not too distant future (currently based on an old
> > > version of TNT, and most of the important pre-processing needed has to
> > > be done elsewhere, for the then lack of svd).
> >
> > This would be a most welcome developement. uBLAS seems a good
> starting point.
> >
> > >       My old files provide number_of_samples , max, min,
> > > first_max_index, first_min_index, mean, median, variance,
> > > standard_deviation, average_deviation, skewness and kurtosis for
> > > sequences (where appropriate), number_of_bins, mass, first_mode_value,
> > > first_mode, mean, median, variance, standard_deviation,
> > > average_deviation, skewness and kurtosis for deensities (where
> > > appropriate).
> >
> > Sounds a pretty good selection.
>
>       I'll uplaod my old file in a moment, for inspirational input, and
> make a note in the Wiki, if I can get that to work.
>
>
> > > > Finally, there is the unsolved matter of the math functions we still
> > > > badly
> > > > need.
> > >
> > >       Err, I kind of forgot which ones where requested...
> >
> > Well all the items in Stephen Moshier's Cephes collection say.  erf, gamma,
> > beta, imcomplete, gaussian etc etc.  However, we didn't seem to get far with
> > agreeing the format for these.  My naive assumption that double erf(double)
> > style functions would be enough was criticised by those who wanted fancier
> > solutions,
> > some far fancier.
>
>       I either forgot or missed that thread (I lost quite a bit of data
> and hence memory during my OS upgrade, thanks to a faulty ftp
> server...). Would you have a pointer handy?
>
> > In my view getting this far would be a major step forward.  There are major
> > problems in accuracy even at double, let alone long double.
> >
> > There was also talk of an NIST project but I haven't heard of any progress
> > yet.
>
>
>       I just checked the DLMf website (http://dlmf.nist.gov/), and it seems
> they are moving forward albeit slowly (book and free web document in
> 2004). At any rate, that document will not, as I understand, include
> actual implementation in a computer language of the functions & al., so
> we should just go ahead and code, perhaps using existing fortran
> implementations as guidelines (though obviously having the document
> would make the coding *MUCH* easier :-)  ).
>
> > Paul
> >
> >
> > > >
> > > > > -----Original Message-----
> > > > > From: boost-bounces_at_[hidden]
> > > > > [mailto:boost-bounces_at_[hidden]]On Behalf Of Jeff Garland
> > > > > Sent: Tuesday, February 11, 2003 4:19 PM
> > > > > To: Boost mailing list
> > > > > Subject: RE: [boost] Any interest in a stats class
> > > > >
> > > > >
> > > > > Scott K wrote:
> > > > >
> > > > > > Hi all,
> > > > > > I have a small family of statistics classes which I have used from
> > > > > > time
> > > > > > to time. The one I use most often is simply called stats.
> > > > > > Here's an example of it's use:
> > > > > > ...details snipped...
> > > > >
> > > > > I'm sure there are folks interested in statistical (and other)
> > > > > functions.  I've developed exactly this sort of class in the
> > > > > past so I understand the utility.  However, I suspect some of
> > > > > us would hope statistical algorithms to be formulated as STL
> > > > > Algorithm extensions.  Specifically concerning statistics see:
> > > > >
> > > > > http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?STLAlgo
> > > > rithmExtensions/StatisticsAlgorithms
> > > > >
> > > > > and more generally:
> > > > >
> > > > > http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?STLAlgo
> > > > rithmExtensions
> > > > >
> > > > > We definitely need volunteers to take these rough Wiki musings and
> > > > > convert them into actual documented libraries.  I'm not sure this
> > > > > is what you had in mind, but I, for one, would welcome your effort
> > > > > either way!
> > > > >
> > > > > Jeff
> > >
> > >    A Bientot
> > >
> > > HH
>
> Hubert
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>