Christopher Kormanyos wrote:
In my opinion, Boost.Multiprecision does the following:
1. Provide a uniform template abstraction for extended numeric types. 2. Provide default implementations of integer, rational and float. 3. Allow for a future default implementation of fixed- point. 4. Allow for use with a future extended complex class.
Reasonable goals.
Although the proposed Boost.Multiprecision provides default implementations of int, rational and float, its main goal is not to compete with the world's best performing implementations thereof.
Of course it needn't compete with the world-class implementations, at least not initially. However, it must be fast enough to be usable in enough use cases to get sufficient experience to determine whether the interface is right and whether the customization points are appropriate, in order to have a solid foundation for a standard proposal.
I would prefer spending review time working on the long-game of boost and C++.
Yes, given the minimal performance caveat noted above.
How will boost or C++ potentially specify extended number types?
template<typename back_end_numeric_type, typename numeric_traits, typename allocator_type, typename expression_method> mp_number { };
That looks ugly, for a numeric type, but typedefs and template aliases will be very useful in making nice, user-defined types and class templates.
I would prefer to work on the interface, not the performance of the default classes that John and I have provided. If we bicker about these, we will never get to the real matter at hand which is specifying the abstraction for non-built-in types.
While I agree with your sentiment, note that Phil's concern about being able to create a fast, slightly-larger-than-built-in type is important. Showing how such a type can be created is an important exercise because it will show whether the abstraction and points of customization have been properly conceived to permit creating such types. Indeed, given the likelihood of folks wanting to do what Phil did, the library could provide a template-based backend implementation that does most of the heavy lifting.
John's concept takes the first step toward establishing an architecture for extended numeric types.
It is reasonable to view this as "the first step" and leave the fulfillment of some of these other requirements for later. However, if there is no proof of concept for the various use cases, then you can't be sure the abstraction and points of customizations are correct.
In this way, the previous discussions about default styles of template expression and the proposed name of the abstraction (mp_number or simply number) are more relevant than
"number" is better. The namespace can always be used, including with a namespace alias, to make for a more specific name. If "mp_" is in the name, it cannot be removed.
However it still suffers some of the same problems: if I want an int128_t that is just 128 bits of data, it doesn't help me.
The proposed Boost.Multiprecision says, "You have to write it yourself!" Just like a compiler supplier would. That's the concept of the proposed Boost.Multiprecision.
That's fine for esoteric things, but not for something that would be extremely common.
I do, however, have UINT128 and INT128. I wrote them sometime around 2002. If you *really* would like, I could approach John and ask how we could make these boost.ready. I also have UINT24 for embedded systems.
One of those might be an excellent tutorial for defining a backend, though actually including the code, in some form, with the library would be ideal.
In the xint reviews, we suggested that the algorithms should be decoupled from the data structures and the same applies here.
(Please interpret this as my opinion. Others will have different opinion.)
This goes without saying since you aren't quoting anyone else. OTOH, if you wish to be clear that you are not speaking for John, you can say that explicitly.
In my opinion, the suggestion was not correct, but understandable. Just because the proposed Boost.Multiprecision provides a template abstraction for arithmetic operations and C99 elementary transcendental functions, does not mean we would like the template itself to be modifiable.
If the operations are broken down to calls to specific algorithms, why not permit customizing those algorithms? If your concern is that doing so exposes implementation details that would thwart future improvements, I can certainly understand your reticence. Furthermore, it may be reasonable to see some of what was being requested for xint is what your library provides in its backend.
Similarly, this implementation doesn't provide hooks that would allow me to substitute e.g. assembler implementations of the algorithms.
This is correct for Boost.Multiprecision, and it is as it should be. Please don't expect to put hand-written assembler optimizations in the template. If you can do it better than GMP and MPFR, then you must do it in the back-end---an entire back-end.
Perhaps the documentation needs to be clearer about the role of the frontend and backend parts of the library. Specifically, there should be information that notes that performance optimizations are, mostly, applied to the backend. _____ Rob Stewart robert.stewart@sig.com Software Engineer using std::disclaimer; Dev Tools & Components Susquehanna International Group, LLP http://www.sig.com ________________________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.