Re: [boost] [review] Multiprecision review (June 8th - 17th, 2012)

Subject: Re: [boost] [review] Multiprecision review (June 8th - 17th, 2012)
From: John Maddock (boost.regex_at_[hidden])
Date: 2012-06-18 08:21:15

> Here are my comments from reading through the tutorial.

Many thanks for the detailed comments.

> * "It's also possible to access the underlying mpz_t via the
>  data() member function of gmp_int"
>  I'm assuming from this that mpz_int ends up inheriting
>  data() from gmp_int?  Otherwise, this wouldn't be
>  terribly useful.  Anyway, (I had a similar comment
>  for cpp_int) I thing you should either specify everything
>  in terms of the appropriate specializations of mp_number
>  or say somewhere early on that mp_number inherits
>  all the behavior of the backend.  Wait... I see v.backend().data()
>  in the example.

Right, the backend type is accessible via the backend() member function.

> * "it is a rather strange beast as it's a signed type that is
>  not a 2's complement type"
>  isn't this true of GMP and cpp_int as well?
>  Why the special warning for tom_int?

Lib tommath's bitwise operations behave differently from a 2's complement 
type.  In contrast gmp and cpp_int "simulate" 2's complement behaviour when 
performing bitwise ops on negative numbers.  Note that this is an area where 
the behaviour of builtin types is undefined in the std anyway, there is 
however, a general expection that they will actually behave in a certain 
way.

> * "... just set the n'th bit in the ..."
>  Oh, come on.  I'm sure there's a way to use a proper superscript.

I'm not sure I follow, do you mean make mp_number subscriptable to access 
the individual bits?  Obviously that's possible to do, I'd be interested in 
others thoughts as to whether it's the correct interface choice.

> * On a related note, what does "standard library support"
>  mean? ... In the example, I see "log(b)."  I think
>  this terminology is imprecise.  log(b) does not
>  call a standard library function at all.

I'll try and be more specific - it means that all the functions (from cmath) 
and traits (numeric_limits) that operate on builtin floating point types, 
are also defined for these types.

> * "Narrowing conversions are truncating."
>  This is unfortunate.  I'd prefer it to round according
>  to the current rounding mode.

Chris will have to answer that one.

> Defining a Lambda Function:
>
> * The name of the section is misleading because
>  "Lambda" has a totally different meaning in
>  programming.  Maybe find a different example.

Point taken, shame, it made a nice simple example :-(

> * I'm a little concerned that if the arguments of the
>  final version, JEL5 are expression templates, they
>  would be evaluated multiple times.  Is this the
>  case?

My bad, yes that would be the case.  Will fix the example.

> * "An mp_number can be converted to any built in type,
>  via the convert_to member function"
>  In C++11, can we use an explicit conversion operator?

Not yet, but's already ben asked for and trivial to add.

> Generating Random Numbers:
>
> * boost/multiprecision/random.hpp should go away.
>  I'll try to work out the changes needed to
>  make Boost.Random work directly.

I hoped you'd say that ;-)

However, I've deliberately held off submitting patches or suggesting any 
changes until/unless the interface on this library is accepted.  No point in 
chasing a moving target.  Just consider the code in random.hpp proof of 
concept for now, I figure folks would complain about it not working if I 
didn't provide it.

Regards, John.