- Boost - lists.boost.org

Proposal for New Multiple-Precision/ Arbitrary-Precision Numbers Library
by Reetesh Mukul 02 Aug '10

02 Aug '10

Hi, I know the purposes and necessities of a Multiple-Precision and Arbitrary Precision Numbers Library in C++ have echoed many a times in BOOST mail chain. Moreover in past and in present many such efforts have been on to address these needs( Google SoC, XINT, and many others ). I too have a long, consistent interest in this area and so is this proposal. I am putting some of the points in Q & A format. Q. What does Numbers mean here ? A. As a long standing definition, Numbers would mean a “Set”. However for most of the practical reasons, and in particular in relation to Natural Numbers/Integers, it would mean a set with Peano’s Arithmetic or Principle Ideal Domain or Finite Field ( ‘or’ here is in inclusive sense). In most of the cases these Sets will be generated out of Rings. As an example, Natural Numbers can be created by mapping Set of “unsigned int”s (which can be treated as Finite Field) to an Indexed Family of “unsigned int”. One such mapping is “radix” (a0 + a1*r + a2*r^2 + a3*r^3+ ...) based arithmetic. Clearly the library has long term intention to provide support for such mappings which has flavors of being generic. Q. What does Multiple-Precision and Arbitrary precision means here ? A. If the cardinality of indexing set (mentioned above) is finite and known at compile time then it will be the case of multiple-precision else it will be arbitrary precision. Both Arbitrary and Fixed precision have a meaning that they are multiple of a unit precision. We will use the term multiple-precision as an alias to fixed precision, however I see chances of debate over this topic. In its implementation paradigms, the current library has notions of multiple-fixed-precision and multiple-unfixed-precision. In current writing I am denoting multiple-fixed-precision as fixed/multiple precision while multiple-unfixed-precision as arbitrary-precision. That multiple-precision maps to cardinality of indexing set additionally asserts that unit of computation will be Elements of Rings of a given kind and bits/bytes will be of particular interest only. To give additional meaning to finiteness of multiple-precision arithmetic, like specifying it in terms of bits, bytes or range of values that the generated number would have, will mean creating compositions of mapping described in last question. Q.What are some basic APIs that the library will expose? A. This is yet to be finalized. However some design paradigms are settled. I already described the core Mathematics in last two questions. There will be a conception of “varch”(Virtual Architecture). This would mean providing a set of functions like mov, add, addto, or, xor, ... which underlying processor provides. Thus one can do - addto(unsigned int* dest, unsigned int* src, unsigned int n), which adds “src” to “dest” (like operator+=) assuming “unsigned int” is a “finite field” and the “pointers” and “n” means n-sized indexed family of “unsigned int”. Definitely there will be “addto”s corresponding to each of the Ring and Mappings. The “arithmetic concepts” corresponding to each “addto” will be deduced based on types involved, and in case “arithmetic concepts” thus deduced are ill-formed or wrong or void, compile time errors will be generated. These varch functions will be provide very low level interface(with respect to intended library) and internally they will be fine-tuned for underlying processor, system, compiler and algorithms. Numbers will be represented as an object via a kernel called basic_mint (which in turn will use varch’s function):- template<typename SignedType=varch::U, typename IntegerType=unsigned int, std::size_t InitialSize=0, precision::value_type P=default_precision<InitialSize>::value, typename IntegerTraits=integer_traits<IntegerType>, typename Allocator=allocator<IntegerType> > struct basic_mint; Further there will be conception of “generators” which will handle Algebra of underlying types. Q. How much is done ? A. Not much. However some of the above ideas have been implemented. One can see pieces of codes here:- http://sourceforge.net/p/spring-math/svn/. A very large portion of code is to be implemented. I thought, before I go too far, too far where design and implementation buckles, I should get “concept-check” by BOOST Gurus. Q. Will it be wrapped around GMP ? A. No, No and No. C++ has richer Algebraic content. Q. Is there any final API where user can use it the way int/char/float are used is specified. A. Not yet. But at most it will be a thin compile time wrapper around basic_mint. Q. Why I came here? A. For guidelines, help, ideas, warnings, disciplines, lectures, volunteers and inherent desire to register initials of my work :). With Regards, Reetesh Mukul

3 4

[MPL] More lazy evaluation, for ease of use?
by jcarey＠jcarey.best.vwh.net 02 Aug '10

02 Aug '10

According to Boost MPL documentation, "Every Integral Constant is also a nullary Metafunction, returning itself." Put another way: redundant evaluation of an Integral Constant is harmless. This handy guarantee encourages Metafunctions to evaluate their integral arguments upon demand. As others have pointed out before, such lazy evaluation reduces "typename ...::type" syntactic clutter, makes it easier to avoid instantiating a template with parameters it does not support, and tends to increase compilation speed. However, other Boost MPL concepts do not impose this self-return requirement, and many Boost MPL standard data types do not provide such a guarantee. In particular, I think it would be helpful if all Sequences, Iterators, and Lambda Expressions were also nullary Metafunctions returning themselves. (In particular, it would be nice if generic containers designed for lazy data could accommodate Lambda Expressions.) Furthermore, it would be helpful if more standard Metafunctions evaluated their arguments. In particular, if boost::mpl::eval_if were to evaluate its condition argument, then nested ifs would be much easier to write, because nested conditions would not have to be legal for all template parameters. Perhaps the reason for not evaluating certain arguments is backward compatibility? Personally, I think the convenience of widespread lazy evaluation would outweigh the costs of a transition to new Metafunctions and concepts. In particular, uniform lazy evaluation would reduce the burden on beginners to figure out which arguments must be evaluated, and which must *not* be evaluated. Instead, beginners could learn the simple rule to leave arguments unevaluated unless there is some good, documented reason to do otherwise. One special note: It is useful for MPL Metafunctions to be able to reason about arbitrary C++ types, even if those types do not happen to be nullary Metafunctions. For example, a canonical use of MPL is to compute the type returned by a function template. To that end, we could wrap arbitrary types just as we wrap integral values in Integral Constant types, and then unwrap them only at need. For example, we could define: template< typename X > struct box { typedef box type; typedef X content; }; template< typename B > struct open : B::type::content {}; and then compute with "box" instances instead of raw types, and apply "open" only when a raw type is actually required. What do you all think?

4 4

[ptr_container] ptr_vector transfer from C array of pointers documentation
by Number Cruncher 02 Aug '10

02 Aug '10

The documentation for ptr_vector::transfer( iterator before, T** from, size_type size, bool delete_from = true ) implies that the operation "delete [] from" is executed, but having examined the source, I don't think it is. This is actually the behaviour I need. I'm trying to convert a std::vector<T*> to a boost::ptr_vector<T*>, i.e. I have a vector of pointers which is solely responsible for "owning" the objects being pointed to, and I want to create a ptr_vector which will automatically clean up the objects when it goes out of scope. I need to do the transfer so that no memory leaks in the event of an exception. As far as I can see, this is exactly what ptr_vector::scoped_deleter is doing: it will delete any of the copied pointers, but it never actually deletes the "from" pointer; presumably because you don't know whether operator new[] was used when allocating it. Can anyone clear up/confirm that this will work: std::vector<T*> v1; v1.push_back(new T); boost::ptr_vector<T> v2; if (!v1.empty()) { v2.transfer(v2.end(), &v1[0], v1.size(), true); } // from this point, don't care about v1 and v2 will handle deletion of T objs Thanks, Simon

2 2

[RFC] Unicode and Converters/Segmenters
by Mathias Gaunard 01 Aug '10

01 Aug '10

It's been a while (about a year actually) since I had some feedback about my Unicode library, so here I am requesting for comments. The Unicode library provides facilities to convert between UTF and locale encodings in a way as nice and generic to use as possible, as well as a few Unicode character properties that can be used for normalization or segmentation into graphemes. The largest part of the library is actually a fairly intricate generic Converter and Segmenter system, that, among others, allows to define, in an easy and stateless way, a variable-width N to M conversion step. The conversion can then be applied normally on the input, or step by step by an iterator or range adaptor, essentially performing a lazy conversion. Converters can be combined, and can be used to make codecvt facets, which allows them to be transparently applied by standard file streams. Converters can also be built from codecvt facets, which is how the Unicode library provides conversion between locale encodings. I think the whole system really deserves to be a library of itself and not just part of Unicode, but I'm unsure of how to deal with this in Boost. I think it's quite cool, but I haven't really seen much interest into it. I may write a short tutorial of how to write base64 codecs with it and how to use that with iostreams just to show it off a bit more outside of a Unicode context. Anyway, the docs are here: <http://mathias.gaunard.com/unicode/doc/html/> And the code is on the sandbox: <https://svn.boost.org/svn/boost/sandbox/SOC/2009/unicode/> As I have said before, I will be submitting the full thing for formal review *soon*, i.e mid-september. The changes that will go in are mostly performance-related: I'm experiencing with things right now and doing benchmarks, considering unsafe codecs and SIMD ones (SIMD is not just an implementation detail, due to the step-by-step evaluation; using SIMD means having a much larger step -- and of course, it cannot be safe). I also need to tackle the issue of compile-time, which is quite large: I need better header separation. I also need to find a better solution, from a binary point of view, to expose composition from the shared library, as the current one doesn't give much flexibility in implementation.

1 0

[date_time] Constructing ptime object from ISO 8601 compliant strings
by Rush Manbert 31 Jul '10

31 Jul '10

A variation on this question was asked by Allen Cronce back in May, but I didn't see any answer posted. The Posix Time description begins: "Defines a non-adjusted time system..." I assume that this means it is not adjusted for time zone? I need to construct ptimes from ISO 8601 compliant strings that may contain time zone information, such as this: "2010-08-17 12:34:56-07:00" If I constructed a ptime using this string, then used to_iso_string() to convert it to a string, I would expect to see "2010-08-17T19:34:56", but I don't. Rather, what I see is "2010-08-17T12:34:56" because the time zone portion of the string was ignored. Does anyone have a suggestion for dealing with this situation? I have some ideas, but would be interested to hear what others have done. Thanks, Rush

1 0

Please, remove me from Trac and maintainers.txt
by Gennaro Prota 30 Jul '10

30 Jul '10

Hi, I received a notification for the following Trac ticket. <https://svn.boost.org/trac/boost/ticket/4495> Apparently this request <http://lists.boost.org/Archives/boost/2010/06/168338.php> got just ignored, so I'll try to be clearer: I don't want to have anything to do with Boost; can anyone put an end to this annoyance? Thanks. -- Gennaro __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

4 5

Patches for OpenVMS support for Boost (Asio mostly)
by Artyom 30 Jul '10

30 Jul '10

Hello, I want to submit patches for Boost, mostly Asio for better support of OpenVMS IA64 for 32 and 64 bit builds. The fixes come from an organization I work for that prefers to stay anonymous for security reasons. We've mostly concerned about Boost.Asio and we've managed to compile and run all Boost.Asio unit tests actually giving VMS very good Asio support. The fixes cover several independent libraries that should be fixed in order to make them compile: - Boost.Asio - mostly, configuration and 64 bit quirks - Boost.Test - 64 bit issues and compiler issues. - Boost.Config - added new vms.hpp platform config. - Boost.DateTime - 64 bit fixes. - Boost.Thread - compiler issues workarounds. - Boost.Function - 64 bit fixes as sizeof(size_t) < sizeof(void *); I understand that many library maintainers should be involved in integration of these patch. And it is **very important** for the organization I work for to submit them to upstream Boost in order to make an upgrade to future Boost versions simpler. Questions: - How should I submit so wide patch that covers many libraries? Artyom. P.S.: The patch is attached.

4 10

[context] new version
by Oliver Kowalke 30 Jul '10

30 Jul '10

I've uploaded a new version which takes care of the FLS on Windows. Oliver

2 4

[interprocess] Superfluous "volatile" in atomic_add_unless32
by Capehart, Nolan 29 Jul '10

29 Jul '10

In this: inline bool atomic_add_unless32(volatile boost::uint32_t *mem, boost::uint32_t value, volatile boost::uint32_t unless_this) I think "volatile" on the last argument has no purpose and probably reduces speed slightly. Will it not merely cause the compiler to fetch the formal argument from memory every time it's needed? And isn't that of no use since nothing is modifying the formal argument during the function execution? So: 1) Caller puts actual argument on stack. 2) Caller calls atomic_add_unless32. 3) atomic_add_unless32 treats stack variable as volatile, wasting time (not much) because variable isn't actually changing.

1 0

[gsoc] boost.heap update
by Tim Blechmann 29 Jul '10

29 Jul '10

hi all, i've uploaded a new snapshot of boost.heap. it includes some of the proposed changes and i have also added a benchmark sections. during the final time for the gsoc, i'd like to get the library ready for a review ... therefore, i uploaded a new snapshot [1] and an updated documentation [2]. feedback welcome ... cheers, tim [1] http://tim.klingt.org/code/attachments/download/31/boost_heap_280710.tar.gz [2] http://tim.klingt.org/boost_heap -- tim(a)klingt.org http://tim.klingt.org Cheat your landlord if you can and must, but do not try to shortchange the Muse. It cannot be done. You can't fake quality any more than you can fake a good meal. William S. Burroughs

3 8