Re: binomial distribution setter function

From: pbristow_at_[hidden]
Date: 2020-01-20 10:13:15

> -----Original Message-----
> From: Boost <boost-bounces_at_[hidden]> On Behalf Of Alexander Grund via
> Boost
> Sent: 20 January 2020 08:35
> To: boost_at_[hidden]
> Cc: Alexander Grund <alexander.grund_at_[hidden]>
> Subject: Re: [boost] binomial distribution setter function
> 
> Am 18.01.20 um 07:57 schrieb Kemin Zhou via Boost:
> > I am looking at the binomial.hpp file.
> > I need to use the binomial object in a loop which requires to have
> > high performance.
> > I am thinking constructing the binomial object each time in the loop
> > would be less efficient than if I construct a single object, the each
> > time reset the p parameter and use the object.
> >
> > I am not sure why the setter method was not provided.
> >
> > 296       RealType success_fraction() const
> > 297       { // Probability.
> > 298         return m_p;
> > 299       }
> > 300       void set_success_fraction(RealType p) {
> > 301          m_p=p;
> > 302       }
> > Line 296 is the getter method, I added the setter method at line 300.
> 
> As usual: Did you measure before making assumptions about performance?
> Next: Did you check what the ctor does? What is your reasoning for your
> statement?
> 
> This is not meant to sound harsh but rather spark usual scientific work practices.
> 
> You'll see that the constructor does nothing but check invariants. Your setter does
> not do so and hence is wrong (for some definition of wrong as usual) So the only
> overhead can be due to check of valid parameters. Depending on how you pass in
> the arguments this can even be removed, so try it first and measure where your
> performance suffers or use e.g. godbolt to check the assembly to verify
> assumptions.
> 
> Then the better solution would be to provide a ctor that does not do verification,
> probably the policy system can be used if it isn't already. Again it needs to be
> argued why this would be required and how much benefit it brings.

I concur with this assessment.

I suspect that you presume that construction is expensive, when it is really very cheap, only carrying out some quick sanity checks, and a few assignments.

You need to be quite certain that these handful of instructions are on your critical path before doing something that will expose you to risks from passing a bad parameter.

Paul A. Bristow

PS Reminder, it you don't put your stuff inside try'n'catch blocks, you won't get any error messages helping you see what went wrong 😊

But of course that will slow things down a bit.  But useful to have the checks until you are certain that your code is correct?