Re: [boost] bug (I think) in interval library function tan

From: Jason McCarty (bclg_at_[hidden])
Date: 2003-07-29 16:23:25

gmelquio_at_[hidden] wrote:
> En réponse à Jason McCarty <bclg_at_[hidden]>:
> 
> > Hi,
> > 
> > I came across a likely bug in boost::numeric::tan(interval) today.
> > Calling tan on an interval with a save_state rounding policy fails to
> > compile on line 109 of transc.hpp, even though an interval with a
> > save_state_nothing policy compiles correctly. I think this is because
> > of a typo; the line
> >   R tmp = fmod((const I&)x, pi);
> > was probably meant to read
> >   R tmp = fmod((const R&)x, pi);
> > so that the call to fmod isn't ambiguous (why gcc didn't tell me it was
> > ambiguous, I can't tell). It presumably works with save_state_nothing
> > because it's equivalent to the unprotected version.
> 
> Strangely, in my own version, it is already written as
>   R tmp = fmod((const R&)x, pi);

Hmm, browsing CVS, yeah, you fixed it back in April, but there hasn't
been a release announced on boost.org since 1.30.0 in March, so that's
what I'm using (Debian's package of libboost-dev). I think I'll send
Debian a bug report to patch that until a new version arrives.

> However it is the CVS version, so maybe you are using Boost 1.30.0 and there was
> a mistake at that time (I don't have the code at hand to verify). Anyway, sorry
> for the trouble.

No trouble, although I ended up being much more familiar with the
implementation than I had intended ;-)

> > I've attached a test case, and the output produced by g++-3.3.
> > 
> > Jason McCarty
> 
> Thanks for pointing that out. Even if this typo was already corrected, it
> allowed me to detect another typo at the previous line :-). This one however
> didn't produce compilation error or runtime misbehavior, it was just a
> misoptimization.

Hey, cool. Since I've already taken the trouble to subscribe to the
boost list, and got your attention, I might as well mention another
trivial bug I discovered recently. In the file
detail/c99sub_rounding_control.hpp, "numeric" is once mistyped "nuemric".
I already reported this one to Debian, so you might get another message
about it from them.

Thanks,

Jason