Boost logo

Boost :

From: Thorsten Ottosen (tottosen_at_[hidden])
Date: 2005-12-18 08:53:31


[Fernando, I'm CC'ing you because of the numeric_cast<> discussion here...]

Paul A Bristow wrote:

> | I guess throwing is out of the question because of C compatibility?
>
> :-((
>
> | How are error handled in the new tr1 math functions?
> C style matherr, I believe, but I have yet to see examples coded. I suspect
> Dinkumware may have built in options to use exceptions?

Yeah, maybe a macro could control this behavior:

#if BOOST_MATH_STAT_FUNTIONS_THROW
...

The default could be to throw for C++ and not for C.

> | > my impression is that most of the warnings look spurious.
> | How many warnings? what type of warning?
>
> Dozens - mostly data loss on conversion, unsigned/signed, untidynesses like
> unused parameters. I don't want to alter Moshiers code at all (yet).

well, I suggest that you do a numeric_cast in debug-mode and a
static_cast in release-mode. That way you don't alter his code's
behavior, but get rid of the warnings.

We really should have something like

asserting_numeric_cast<T>( u )

in cast.hpp

> | When you write a revised paper, please enhance the "motivation" section
> | by drawing from exampes in other languages. If it has been part of
> | Visual Basic, then write it. If similar functions are used often in Java,
> | then tell something about it.
>
> OK - but there isn't much to tell except that they have them.

right, but the more languages that actually provide them, the more
presure is put on the comittee to adopt these.

> | 1. why so many functions? are they all really needed?
>
> Well of course there was some hyperbole about the number - it counts up from
> sin and cos to the highest functions - but they all link together so any one
> missing is a real pain to someone.

good point ... put that sentence in the paper.

> | 2. would it make more sense to standardize a usability layer on top
>
> IMO, higher layers are entirely a user matter. The incomplete beta is to
> statistics as sin and cos are to geometry.

another great sentence :-) get it in the paper.

> One might consider something to get the moments - mean, variance, skew and
> kurtosis - but then you get into dealing with the many containers and
> iterator solutions look attractive, but then where do you put the calculated
> moments? I'd rather not go there - yet: the functions are probably more
> than I can chew ;-)

right, seems fair.

br

Thorsten


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk