Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
Francesco Biscani
@bluescarni
I am not really up to speed with CMake subprojects. The build systems of mp++ and obake are made with installation into a prefix in mind, a-la classical Unix way or even conda. Is the problem here that finding mp++ fails?
Andrew Corrigan
@andrewcorrigan
yes. That's fine, since this is not your intended usage, the answer is probably that I should just comment out the find_package lines. No big deal
Francesco Biscani
@bluescarni
Well I was thinking... what find_package() ultimately does is to create an mp++::mp++ imported target. Perhaps you can try to write:
if(NOT TARGET mp++::mp++)
  set (_OBAKE_MIN_MPPP_VERSION 0.17)
  find_package(mp++ REQUIRED)
  if(${mp++_VERSION} VERSION_LESS ${_OBAKE_MIN_MPPP_VERSION})
      message(FATAL_ERROR "The minimum mp++ version required by obake is ${_OBAKE_MIN_MPPP_VERSION}, but version ${mp++_VERSION} was found instead.")
  endif()
endif()
and see what happens?
this assumes that you have already found mp++ somewhere before...
I don't really know how this sort of inclusion of subprojects is properly done in CMake
Andrew Corrigan
@andrewcorrigan
nice
I'll play around with it and see if I can come up with something that supports both approaches
Francesco Biscani
@bluescarni
ok, sounds good
how does it work with the install targets in a subproject though? You just don't use them I presume?
Andrew Corrigan
@andrewcorrigan
I think I commented those out as well
Andrew Corrigan
@andrewcorrigan
would it make sense to support automatic conversion from std::map<std::string, Value> to obake::symbol_map<Value>?
Francesco Biscani
@bluescarni
I try to avoid automatic conversions unless absolutely necessary. You should be able to construct a map from a symbol_set (and vice-versa) using the constructors from ranges though?
Andrew Corrigan
@andrewcorrigan
fyi, on my system the default setting of -Werror for debug builds triggers errors from included TBB headers.
Francesco Biscani
@bluescarni
Can you report the compiler output? I am assuming this is clang on OSX?
Andrew Corrigan
@andrewcorrigan
correct
Andrew Corrigan
@andrewcorrigan
I still owe you the compiler output. To be clear, these are warnings from TBB, not Obake.
Francesco Biscani
@bluescarni
@andrewcorrigan thanks for the report! Today it's a holiday over here, so I won't be able to reply until the evening.
Regarding the compiler output, it might be possible to suppress the tbb warnings with some pragmas
Andrew Corrigan
@andrewcorrigan
I spent some time trying to reproduce the warnings, but haven't been able to. I'm sorry, I'll report back as soon as it happens again. Also, thanks for any help with the issue I raised.
Francesco Biscani
@bluescarni
@andrewcorrigan I managed to squeeze in some debug time in the afternoon. I think the issue you reported is a bug in the polynomial integration function, I have opened a PR with a tentative solution.
Andrew Corrigan
@andrewcorrigan
thanks! looks good
I'm testing my application and a lot of things are working the same as Piranha, however for certain cases, I see errors like the below. Would you have any hints on what to do about this?
# 2 | :0 | decltype(series_default_in_place_addsub_algorithm<true, obake::series<obake::polynomials::packed_monomial<unsigned long long, void>, mppp::rational<1ul>, obake::polynomials::tag, void>&&&, obake::series<obake::polynomials::packed_monomial<unsigned long long, void>, mppp::rational<1ul>, obake::polynomials::tag, void>&&>.second)::type obake::detail::series_default_in_place_addsub_impl<true, obake::series<obake::polynomials::packed_monomial<unsigned long long, void>, mppp::rational<1ul>, obake::polynomials::tag, void>&, obake::series<obake::polynomials::packed_monomial<unsigned long long, void>, mppp::rational<1ul>, obake::polynomials::tag, void> >(obake::series<obake::polynomials::packed_monomial<unsigned long long, void>, mppp::rational<1ul>, obake::polynomials::tag, void>&&&, obake::series<obake::polynomials::packed_monomial<unsigned long long, void>, mppp::rational<1ul>, obake::polynomials::tag, void>&&)
# 1 | :0 | void obake::detail::series_sym_extender<obake::series<obake::polynomials::packed_monomial<unsigned long long, void>, mppp::rational<1ul>, obake::polynomials::tag, void>, obake::series<obake::polynomials::packed_monomial<unsigned long long, void>, mppp::rational<1ul>, obake::polynomials::tag, void>&>(obake::series<obake::polynomials::packed_monomial<unsigned long long, void>, mppp::rational<1ul>, obake::polynomials::tag, void>&, obake::series<obake::polynomials::packed_monomial<unsigned long long, void>, mppp::rational<1ul>, obake::polynomials::tag, void>&&&, boost::container::flat_map<unsigned long, boost::container::flat_set<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::less<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, void>, std::__1::less<unsigned long>, void> const&)
# 0 | :0 | obake::polynomials::packed_monomial<unsigned long long, std::__1::enable_if<is_k_packable_v<unsigned long long>, void>::type> obake::polynomials::key_merge_symbols<unsigned long long>(obake::polynomials::packed_monomial<unsigned long long, std::__1::enable_if<is_k_packable_v<unsigned long long>, void>::type> const&, boost::container::flat_map<unsigned long, boost::container::flat_set<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::less<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, void>, std::__1::less<unsigned long>, void> const&, boost::container::flat_set<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::less<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, void> const&)

Exception type   : std::overflow_error
Exception message: Invalid size specified in the constructor of a Kronecker packer for the type 'unsigned long long': the maximum possible size is 21, but a size of 22 was specified instead
Andrew Corrigan
@andrewcorrigan
Would I need d_packed_monomial instead? I'm not clear from the examples what reasonable template arguments would be. If this is the more appropriate data structure, how would I adapt the unpacking code above? Hope you're enjoying the holiday. Any help is appreciated.
Francesco Biscani
@bluescarni
Yes a d_packed_monomial does not have limits in the number of variables it can represent. The first template parameter, T, is the same as in packed_monomial. The second template parameter is the (approximate) number of bits you want to devote to each exponent. So for instance if you use NBits==8 and T an unsigned integral type, then each exponent will have a range of circa [0, 256] (it will be less than that in reality, but same order of magnitude).
A d_packed_monomial is kind of like a vector of packed_monomials
so the packing/unpacking is a bit more complicated
brb
Francesco Biscani
@bluescarni
From a d_packed_monomial, you can access the underlying vector of Ts via the _container() function. You can then proceed to unpack each T value as if it was the value in a packed_monomial. For instance:
using d_type = d_packed_monomial<unsigned long, 8>;
// This is the number of exponents packed in each unsigned long stored in a d_type.
// This is a compile-time constant.
constexpr auto psize = d_type::psize;

// Create a monomial.
d_type d{....};

// Print out all exponents.
for (const auto &n : d._container()) {
  k_unpacker<unsigned long> ku(n, psize);

  unsigned long tmp;
  for (auto j = 0u; j < psize; ++j) {
    ku >> tmp;
    std::cout << tmp << '\n';
  }
}
Note that like this it will print a number of exponents multiple of psize. That is, if psize is 8, then the code above will print either 8, 16, 24, 32, etc... exponents.
Even if in reality the actual number of exponents is not necessarily a multiple of 8.
So in actual code you need a bit more book-keeping on how to stop the inner for loop, but hopefully you get the gist.
Andrew Corrigan
@andrewcorrigan
thank you
where would I get the actual number of exponents from? would the polynomial containing the monomial give me the right size, as was the case with packed_monomial?
Francesco Biscani
@bluescarni
yes exactly. you can see an example of this in the function that computes the degree of a d_packed_monomial:
https://github.com/bluescarni/obake/blob/master/include/obake/polynomials/d_packed_monomial.hpp#L902
Andrew Corrigan
@andrewcorrigan
got it, thanks!
Francesco Biscani
@bluescarni
no problem! when you have time, I'd be interested to hear how obake is working for you wrt piranha, both in terms of API and in terms of performance.
Andrew Corrigan
@andrewcorrigan
so far with packed_monomial, without overflow, I saw an immediate 2x speed-up
Francesco Biscani
@bluescarni
that's great to hear
let me know if you find weak spots wrt piranha. obake was built to be faster but there could always be instances where it ends up being slower for some reason.
are you normally using polynomials over the rationals?
Andrew Corrigan
@andrewcorrigan
In terms of API, overall it's great and it's wonderful to have such a high-quality, open-source library available. You've helped me with my main struggles switching over. A few minor differences I noticed:
  1. in Piranha, I could divide polynomials as long as the denominator was actually just a rational number. In Obake, it seems to require an explicit conversion to a rational number to compile. Maybe that's better than a run-time error, but it was a difference that I noticed.
  2. In Piranha, I could pass a string into the constructor, like Polynomial{"x"}, Polynomial{"y"}. In Obake, I think that compiles, but didn't work. Instead, I had to change those to make_polynomials<Polynomial>("x", "y"); I like the make_polynomials function, but would prefer the string-constructor fail to compile rather than working in an unexpected way.
  3. I like that in Obake the range-based for-loop to iterate over the monomials and coefficients of a polynomial returns monomial as a monomial type, whereas in Piranha the monomial was still a polynomial type (I thought that was confusing).
Once I get d_packed_monomial I can measure performance for less trivial cases
yes, always over rationals
Francesco Biscani
@bluescarni
Regarding 2, the fact that the string constructor is still there but it does not operate as before is an unfortunate consequence of the fact that you can construct rationals from string. In piranha the poly ctor from string had a special meaning, while in obake the poly ctors other than copy/move simply forward the construction to the coefficient type.
Regarding the use of rationals as polynomial coefficients, obake does not implement yet an optimization that piranha had. piranha used to convert all rational coefficients in a poly multiplication to a common denominator, thus transforming a rational poly multiplication into an integer poly multiplication. This essentially means avoiding a lot of GCD computations which are not needed. obake will also have this optimisation, but it does not at the moment.
Andrew Corrigan
@andrewcorrigan
wow, so it can get even faster?
Francesco Biscani
@bluescarni
it should, but only if the polys are long enough I believe. In my tests I always used rather large polynomials and there the difference was very visible.
it might be possible that for shorter polynomials the difference is not that great, but it's something that needs to be studied/tuned.
Andrew Corrigan
@andrewcorrigan
large is important for me too