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 +44 1539 561830 Mobile +44 7714 33 02 04 mailto:[EMAIL PROTECTED] > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Hubert Holin > Sent: Monday, February 17, 2003 12:35 PM > To: [EMAIL PROTECTED] > Subject: [boost] Re: Any interest in a stats class > > > Somewhere in the E.U., le 17/02/2003 > > In article <[EMAIL PROTECTED]>, > "Paul A. Bristow" <[EMAIL PROTECTED]> wrote: > > > > -----Original Message----- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED]]On Behalf Of Hubert Holin > > > Sent: Friday, February 14, 2003 1:25 PM > > > To: [EMAIL PROTECTED] > > > 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: [EMAIL PROTECTED] > > > > > [mailto:[EMAIL PROTECTED]]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 > _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
