RE: [boost] Re: dlw_int/dlw_gcd review summary

From: scleary_at_[hidden]
Date: 2001-10-10 08:45:13

From: "Moore, Paul" <paul.moore_at_[hidden]>
> From: "David Abrahams" <david.abrahams_at_[hidden]>
> > From: "Daryle Walker" <darylew_at_[hidden]>
> > > Since I don't use Windows (or an IBM-style PC), it's
> > > very hard for me to play "guess the MSVC6 fix." However,
> > > I want to support all the platforms that the rational
> > > and pool libraries did, since I'm trying to replace the
> > > specialty GCD/LCM routines they had. So if someone could
> > > provide a fix that's close to my style, that's OK.

I didn't actually write my fix -- Peter Dimov did some time ago, and someone
else (I forget who, sorry!) offered another fix that was essentially the
same.  It's not too confusing: the code I had depended on template partial
specialization, and it was rewritten using nested full specializations --
there was some talk on this list about this workaround some time ago.  Both
solutions are in <boost/pool/ct_gcd_lcm.hpp> right now, so you can compare
them if you wish.

> > If you are replacing functionality that used to work with
> > this platform, I would not feel right about incorporating
> > the change until there was a fix in place. Somebody did
> > the work to make sure the appropriate workarounds were in
> > place. Undoing that work would not only be bad for users;
> > it would display disrespect for the original author. I
> > would be very reluctant to follow that course.
> 
> Speaking as the author of the rational library, I guess should express my
> view here.

Me too (as author of the pool library, I mean :).

Even though Boost.Pool does not currently support MSVC, I intend to support
it in the near future.  Even though I don't even have access to the
compiler, I've already made several changes that are basically just for MSVC
compatibility (with help from many others -- thanks, Boosters!), and I think
I'm almost there.  So, for me, MSVC compatibility is also important.

> Given all of the above, I have some serious reservations about using the
GCD
> library in rational.hpp. First of all, if there is a MSVC compatibility
> problem, I definitely won't be using it. Sorry, but that's absolute.

I would also not use it if it wouldn't work on MSVC.  By no means do I
*like* the compiler, but it just has too large of a user base to ignore.

> Secondly, all the talk I've seen of Euclidean rings and the like, is
> worrying. Goal (1) "simplicity" means that rational.hpp will stay
resolutely
> targeted at integers - not rings, or any other mathematical construct.
(I'm
> a mathematician by training, so I do know the terms, btw - I'm just
glossing
> over details here to avoid obscuring the point).

I worry about it, too, even though I don't have as much math (I stopped
after groups, argh!).  I think that if someone wanted to go through the
trouble to define a Ring concept, or ring_traits or whatever, and if they
extended gcd/lcm to accept rings, I would have no problem with it (as long
as it wasn't less efficient for integers).  But for the initial release, I
would just provide it for integers, and look at rings in the future.

> BTW, I should point out that I haven't looked at the GCD library
> implementation. I haven't had the time. I've done my best to follow the
> discussions, but it's hard to do so, as the list traffic has been pretty
> high (mostly on the thread library, which I've not been following)

I also have not had time to look at the implementation (and unlike Paul, I'm
not going to do it now :).  I do have other "replacement" work to do on Pool
first -- such as the new thread library, a better singleton, etc.

> I worked hard to reduce requirements on integers - both in terms of what
is
> implemented, and what is fast - because people requested it for
long-integer
> type compatibility. I'm not happy about having to revisit that.

Pool technically can also support user-defined integers, and will pass them
to lcm; but I don't think anyone will ever actually use this ability
(std::size_t should always be sufficient).  However, for a generic gcd/lcm
library, you do want to be careful about unnecessary requirements.

> OK, your GCD handles negative numbers - mine doesn't need to (as rational
> has always normalised to positive before calling it).

Pool doesn't need to, either, since all values concerned are sizes of
memory.

> you shouldn't force the requirement on unary +, just so the code "looks
pretty".

I didn't follow the unary+ thread, but I would agree that it seems like an
unnecessary requirement.

> And yes, I know I should have done this earlier. All I can say is that I'm
> sorry - I simply don't have much free time at the moment.

Me, too.

        -Steve