profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/boostorg/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.
Boost.org boostorg Interstellar Space http://boost.org Boost provides free peer-reviewed portable C++ source libraries.

boostorg/boost 4372

Super-project for modularized Boost

boostorg/beast 3149

HTTP and WebSocket built on Boost.Asio in C++11

boostorg/compute 1231

A C++ GPU Computing Library for OpenCL

boostorg/asio 678

Boost.org asio module

boostorg/build 190

B2 makes it easy to build C++ projects, everywhere.

boostorg/callable_traits 118

modern C++ type traits and metafunctions for callable types

boostorg/algorithm 87

Boost.org algorithm module

boostorg/atomic 40

Boost.Atomic

boostorg/circular_buffer 39

Boost.org circular_buffer module

boostorg/any 21

Boost.org any module

push eventboostorg/math

Matt Borland

commit sha 392a1c016d3056dbb6b858b1fc2b73b2f198e42f

constexpr round (#697)

view details

push time in 14 minutes

PR merged boostorg/math

constexpr round

Implements: round, roundf, roundl, lround, lroundf, lroundl, llround, llroundf, and llroundl.

+307 -0

1 comment

6 changed files

mborland

pr closed time in 14 minutes

pull request commentboostorg/math

constexpr round

@jzmaddock and @NAThompson this is clean pending review.

mborland

comment created time in an hour

issue commentboostorg/unordered

scoped_allocator with unordered_map on macos

Awesome, then I'll work on fixing the msvc compilation failures (so hey, at least we found one failure in the test matrix) and then we'll get this bad boy merged!

kleunen

comment created time in 2 hours

startedboostorg/hana

started time in 2 hours

issue commentboostorg/config

Clang-CUDA is not being distinguished from NVCC

@jzmaddock thank you! We have something similar in our code now. Unfortunately, the problem persists and now moved to Boost.Format. See: #406.

psalz

comment created time in 3 hours

issue openedboostorg/config

Boost.Format fails with clang + CUDA

This is a spin-off from #297, which @jzmaddock tried to fix in 2fdfd43. With the implemented fix, I can now successfully use Boost.Optional and Boost.Metaparse.

But now I fail to compile Boost.Format with Boost 1.74 (+ the fix in 2fdfd43) when I use clang in CUDA mode. Without 2fdfd43, Boost.Format compiles fine. I could reduce the problem to:

main.cu:

#include <boost/format.hpp>

compile with:

clang++ -nocudalib --no-cuda-version-check -std=c++17 main.cu

gives:

clang: warning: Unknown CUDA version. cuda.h: CUDA_VERSION=11040. Assuming the latest supported version 10.1 [-Wunknown-cuda-version]
In file included from boost_bug.cu:3:
In file included from /usr/include/boost/format.hpp:38:
In file included from /usr/include/boost/format/internals.hpp:21:
In file included from /usr/include/boost/optional.hpp:15:
In file included from /usr/include/boost/optional/optional.hpp:43:
In file included from /usr/include/boost/type_traits/is_base_of.hpp:12:
/usr/include/boost/type_traits/is_base_and_derived.hpp:142:25: error: invalid application of 'sizeof' to an incomplete type 'boost::in_place_factory_base'
    BOOST_STATIC_ASSERT(sizeof(B) != 0);
                        ^~~~~~~~~
/usr/include/boost/static_assert.hpp:70:55: note: expanded from macro 'BOOST_STATIC_ASSERT'
#     define BOOST_STATIC_ASSERT( ... ) static_assert(__VA_ARGS__, #__VA_ARGS__)
                                                      ^~~~~~~~~~~
/usr/include/boost/type_traits/is_base_and_derived.hpp:217:41: note: in instantiation of template class 'boost::detail::is_base_and_derived_impl2<boost::in_place_factory_base, std::locale>' requested here
    BOOST_STATIC_CONSTANT(bool, value = bound_type::value);
                                        ^
/usr/include/boost/type_traits/is_base_of.hpp:25:31: note: in instantiation of template class 'boost::detail::is_base_and_derived_impl<boost::in_place_factory_base, std::locale>' requested here
            (::boost::detail::is_base_and_derived_impl<ncvB,ncvD>::value) ||
                              ^
/usr/include/boost/type_traits/is_base_of.hpp:31:58: note: in instantiation of template class 'boost::detail::is_base_of_imp<boost::in_place_factory_base, std::locale>' requested here
      : public integral_constant<bool, (::boost::detail::is_base_of_imp<Base, Derived>::value)> {};
                                                         ^
/usr/include/boost/optional/optional.hpp:794:32: note: in instantiation of template class 'boost::is_base_of<boost::in_place_factory_base, std::locale>' requested here
  : boost::conditional< boost::is_base_of<boost::in_place_factory_base, BOOST_DEDUCED_TYPENAME boost::decay<U>::type>::value
                               ^
/usr/include/boost/optional/optional.hpp:823:25: note: in instantiation of template class 'boost::optional_detail::is_convertible_to_T_or_factory<std::locale, const std::locale &>' requested here
  : boost::conditional< is_convertible_to_T_or_factory<T, U>::value
                        ^
/usr/include/boost/core/enable_if.hpp:41:41: note: in instantiation of template class 'boost::optional_detail::is_optional_val_init_candidate<std::locale, const std::locale &, false>' requested here
  struct enable_if : public enable_if_c<Cond::value, T> {};
                                        ^
/usr/include/boost/optional/optional.hpp:951:53: note: in instantiation of template class 'boost::enable_if<boost::optional_detail::is_optional_val_init_candidate<std::locale, const std::locale &, false>, bool>' requested here
                      BOOST_DEDUCED_TYPENAME boost::enable_if< optional_detail::is_optional_val_init_candidate<T, Expr>, bool>::type = true
                                                    ^
/usr/include/boost/format/format_implementation.hpp:40:44: note: while substituting deduced template arguments into function template 'optional' [with Expr = const std::locale &]
          exceptions_(io::all_error_bits), loc_(loc)
                                           ^
/usr/include/boost/optional/detail/optional_factory_support.hpp:32:9: note: forward declaration of 'boost::in_place_factory_base'
  class in_place_factory_base ;
        ^
In file included from boost_bug.cu:3:
In file included from /usr/include/boost/format.hpp:38:
In file included from /usr/include/boost/format/internals.hpp:21:
In file included from /usr/include/boost/optional.hpp:15:
In file included from /usr/include/boost/optional/optional.hpp:43:
In file included from /usr/include/boost/type_traits/is_base_of.hpp:12:
/usr/include/boost/type_traits/is_base_and_derived.hpp:142:25: error: invalid application of 'sizeof' to an incomplete type 'boost::typed_in_place_factory_base'
    BOOST_STATIC_ASSERT(sizeof(B) != 0);
                        ^~~~~~~~~
/usr/include/boost/static_assert.hpp:70:55: note: expanded from macro 'BOOST_STATIC_ASSERT'
#     define BOOST_STATIC_ASSERT( ... ) static_assert(__VA_ARGS__, #__VA_ARGS__)
                                                      ^~~~~~~~~~~
/usr/include/boost/type_traits/is_base_and_derived.hpp:217:41: note: in instantiation of template class 'boost::detail::is_base_and_derived_impl2<boost::typed_in_place_factory_base, std::locale>' requested here
    BOOST_STATIC_CONSTANT(bool, value = bound_type::value);
                                        ^
/usr/include/boost/type_traits/is_base_of.hpp:25:31: note: in instantiation of template class 'boost::detail::is_base_and_derived_impl<boost::typed_in_place_factory_base, std::locale>' requested here
            (::boost::detail::is_base_and_derived_impl<ncvB,ncvD>::value) ||
                              ^
/usr/include/boost/type_traits/is_base_of.hpp:31:58: note: in instantiation of template class 'boost::detail::is_base_of_imp<boost::typed_in_place_factory_base, std::locale>' requested here
      : public integral_constant<bool, (::boost::detail::is_base_of_imp<Base, Derived>::value)> {};
                                                         ^
/usr/include/boost/optional/optional.hpp:795:32: note: in instantiation of template class 'boost::is_base_of<boost::typed_in_place_factory_base, std::locale>' requested here
                     || boost::is_base_of<boost::typed_in_place_factory_base, BOOST_DEDUCED_TYPENAME boost::decay<U>::type>::value
                               ^
/usr/include/boost/optional/optional.hpp:823:25: note: in instantiation of template class 'boost::optional_detail::is_convertible_to_T_or_factory<std::locale, const std::locale &>' requested here
  : boost::conditional< is_convertible_to_T_or_factory<T, U>::value
                        ^
/usr/include/boost/core/enable_if.hpp:41:41: note: in instantiation of template class 'boost::optional_detail::is_optional_val_init_candidate<std::locale, const std::locale &, false>' requested here
  struct enable_if : public enable_if_c<Cond::value, T> {};
                                        ^
/usr/include/boost/optional/optional.hpp:951:53: note: in instantiation of template class 'boost::enable_if<boost::optional_detail::is_optional_val_init_candidate<std::locale, const std::locale &, false>, bool>' requested here
                      BOOST_DEDUCED_TYPENAME boost::enable_if< optional_detail::is_optional_val_init_candidate<T, Expr>, bool>::type = true
                                                    ^
/usr/include/boost/format/format_implementation.hpp:40:44: note: while substituting deduced template arguments into function template 'optional' [with Expr = const std::locale &]
          exceptions_(io::all_error_bits), loc_(loc)
                                           ^
/usr/include/boost/optional/detail/optional_factory_support.hpp:33:9: note: forward declaration of 'boost::typed_in_place_factory_base'
  class typed_in_place_factory_base ;
        ^
2 errors generated when compiling for sm_20.

So I guess my issue is now to get this program working with clang + CUDA:

#include <boost/optional.hpp>
#include <boost/metaparse.hpp>
#include <boost/format.hpp>

using T = BOOST_METAPARSE_STRING("asfd");

Could you please have another look? Thank you!

created time in 3 hours

issue openedboostorg/algorithm

algorithm/string -- find_all_regex() gives a compiler error when the result container is vector<iterator_range<string::iterator>>

The doc says that the container we should pass to this function can be std::vector<boost::iterator_rangestd::string::iterator>. But when I run the program it gives a compile error. But when the result container passed, is a std::vectorstd::string, everything works fine.

First code snippet is using std::vector<boost::iterator_rangestd::string::iterator> as the result. `#include "boost/algorithm/string/split.hpp" #include "boost/range/iterator_range_core.hpp" #include <iostream> #include <boost/algorithm/string.hpp> #include <boost/algorithm/string/regex.hpp> #include <vector>

int main(int, char**) {

std::string s("Hello world");
boost::regex regex("\\w");

std::vector<boost::iterator_range<std::string::iterator>> result;
boost::find_all_regex(result, s, regex);

}`

Following is the last 3 lines of the compiler error. The whole error is too long.

c:\mingw\include\c++\9.2.0\bits\stl_iterator.h:787:11: note: no known conversion for argument 1 from '__gnu_cxx::__normal_iterator<const char*, std::__cxx11::basic_string<char> >' to 'const __gnu_cxx::__normal_iterator<char*, std::__cxx11::basic_string<char> >&'

c:\mingw\include\c++\9.2.0\bits\stl_iterator.h:787:11: note: candidate: 'constexpr __gnu_cxx::__normal_iterator<char*, std::__cxx11::basic_string<char> >::__normal_iterator(__gnu_cxx::__normal_iterator<char*, std::__cxx11::basic_string<char> >&&)'

c:\mingw\include\c++\9.2.0\bits\stl_iterator.h:787:11: note: no known conversion for argument 1 from '__gnu_cxx::__normal_iterator<const char*, std::__cxx11::basic_string<char> >' to '__gnu_cxx::__normal_iterator<char*, std::__cxx11::basic_string<char> >&&'

Also I ran the same program in Clang compiler too. Still the same result.

But when I run the following program with the container as std::vectorstd::string everything works without a hitch.

`#include "boost/algorithm/string/split.hpp" #include "boost/range/iterator_range_core.hpp" #include <iostream> #include <boost/algorithm/string.hpp> #include <boost/algorithm/string/regex.hpp> #include <string> #include <vector>

int main(int, char**) {

std::string s("Hello world");
boost::regex regex("\\w");

std::vector<std::string> result;
boost::find_all_regex(result, s, regex);

} `

created time in 4 hours

startedboostorg/ptr_container

started time in 4 hours

issue commentboostorg/beast

websocket and prioritised handlers

I've tried to replicate my problem in a simple test and it doesn't show up in this tests. I will go deeper in my code look for error of my own. Luckily I can replicate error with just two of concurrent sessions.

shuras109

comment created time in 4 hours

issue commentboostorg/histogram

How to bin integral vs floating point correctly (precision issue and general question)

Once again thinking more about it and reading your original message again, is it correct that you only have an issue with the very last bin edge? Because then your need may be resolved if we implement #319

emmenlau

comment created time in 4 hours

create barnchboostorg/histogram

branch : improve_cpp17_support

created branch time in 4 hours

startedboostorg/hana

started time in 4 hours

startedboostorg/gil

started time in 4 hours

issue commentboostorg/histogram

How to bin integral vs floating point correctly (precision issue and general question)

Thanks a million for this fast and very helpful reply. I need to digest this new input a bit. Support for boost::rational sounds awesome, but your input has triggered new thoughts that require a bit more discussion on our side...

emmenlau

comment created time in 5 hours

issue commentboostorg/histogram

How to bin integral vs floating point correctly (precision issue and general question)

Also the suggestion to add half a bin width would seem feasible and possibly a good idea! But then I guess we could not use the range-based fill() anymore which gives a very noticeable speedup?

If you make your own axis which implements this hack, it will work with range-based fill().

Support for boost::rational sounds awesome, but would it introduce a significant slow-down?

I don't know, I don't think the speed penalty would be terrible.

Yet another option that I forgot is to use the axis::variable, which you can construct in such a way that the bin edges are exactly where you want them to be. axis::variable is considerably slower than axis::regular, though.

emmenlau

comment created time in 5 hours

issue commentboostorg/histogram

How to bin integral vs floating point correctly (precision issue and general question)

Can I also ask a related question, in case you know: from a completely different point of view, is it sensible or common to shift the bin bounds by half a bin width down? We where considering this idea that for example bin 0 would have bounds [-0.5, 0.5) (for the example bins of size one). We see some potential benefits that (a) the integer or floating value falls in the center of the bin rather than the border, and (b) it compensates for aforementioned rounding issues. But we do not feel confident about this route if it is a very uncommon thing to do...

emmenlau

comment created time in 5 hours

issue commentboostorg/histogram

Best way to change the bounds of the histogram

The issue comes with under/overflow bins, correct? In our current use case, we wrap our own 1d histogram around boost::histogram and we would still like to extend our class with this functionality for 1d case, throwing if the under/overflow bins are present. Could you point to some methods (maybe in namespace detail) that would help us do it?

vakokako

comment created time in 5 hours

issue commentboostorg/histogram

Support `boost::rational` as value type for `axis::regular`

Related #336

HDembinski

comment created time in 5 hours

startedboostorg/property_map

started time in 5 hours

issue openedboostorg/histogram

Support `boost::rational` as value type for `axis::regular`

#include <boost/histogram.hpp>
#include <boost/rational.hpp>

namespace bh = boost::histogram;

int main() {
    using R = bh::axis::regular<boost::rational<int>>;

    auto h = bh::make_histogram(R(10, 0, 1));
}

This currently triggers a static_assert, but should be supported.

created time in 5 hours

issue commentboostorg/histogram

How to bin integral vs floating point correctly (precision issue and general question)

Thanks a lot @HDembinski for the help!

What you say makes sense. We just looked at the integer axis, and it most likely would help. But I understand it can not be used with arbitrary bin counts, correct? This is not a huge impediment but it would be a bit sad.

Also the suggestion to add half a bin width would seem feasible and possibly a good idea! But then I guess we could not use the range-based fill() anymore which gives a very noticeable speedup?

Support for boost::rational sounds awesome, but would it introduce a significant slow-down?

emmenlau

comment created time in 5 hours

issue commentboostorg/histogram

How to bin integral vs floating point correctly (precision issue and general question)

The correct solution for this is for us to support boost::rational as the value type of the regular axis, see https://www.boost.org/doc/libs/1_77_0/libs/rational/rational.html, which would enable exact rational arithmetic. This does not work currently, but I can look into it.

emmenlau

comment created time in 5 hours

startedboostorg/property_tree

started time in 5 hours

issue commentboostorg/histogram

How to bin integral vs floating point correctly (precision issue and general question)

Come to think of it, you could also override the index method with something that rounds to the nearest integer.

emmenlau

comment created time in 5 hours

issue commentboostorg/histogram

How to bin integral vs floating point correctly (precision issue and general question)

Thanks for the kind praise!

This is a recurring question and the standard answer is to use an integer axis for images. The regular axis is intended for real-valued input values from a continuous distribution, not for integer values.

So would using boost::histogram::axis::integer work for you? The integer axis uses exact integer arithmetic, and it is a bit faster than the regular axis, too.

If for some reason your input values are really floating point, you could add half the bin width to avoid the rounding errors. This is not an elegant solution, but it works.

This is also not an elegant solution, but you can even make your own axis class that does this step automatically. See https://www.boost.org/doc/libs/develop/libs/histogram/doc/html/histogram/guide.html#histogram.guide.expert.user_defined_axes for examples.

Basically, you would override theindex method of the regular axis, just like in the first example and add half the bin width to the input.

emmenlau

comment created time in 5 hours

startedboostorg/beast

started time in 7 hours

startedboostorg/boost

started time in 7 hours

issue commentboostorg/histogram

Bin count is limited by `unsigned`

It's true, the number of bins is probably enough. It's mostly for consistency with most other containers, where the size_t is used for size.

vakokako

comment created time in 7 hours

push eventboostorg/boost

Automated Commit

commit sha 968e449ee1ef98658c30fd6ebc5756a5dc25f95c

Update histogram from develop

view details

push time in 7 hours