These are chat archives for bluescarni/piranha

30th
Jan 2018
Andrew Corrigan
@andrewcorrigan
Jan 30 12:37
I'm currently implementing custom printing (streaming via operator<<) using Piranha, is there a high-level way available to override the default printing behavior? I'm digging deep into the internals, and I am wondering if there might be a more convenient way to do this
Francesco Biscani
@bluescarni
Jan 30 12:57
there is not at the moment unfortunately. Any chance you could write down somewhere (e.g., in a github issue report) what type of API/features you would like in order to customize printing?
people have asked occasionally about such a feature in the past, and I am willing to spend time implementing it. But I never had the need to do custom printing myself, so I have not a clear idea about how such an API would look like
... so I never got around working on it, on the basis that to have a shitty version of it is worse than having no version of it at all :)
Andrew Corrigan
@andrewcorrigan
Jan 30 13:03
honestly, that's a good point, probably there is very arbitrary customization possible
Actually, the ability to do: for(auto [coefficient, monomial] : polynomial) is already 90% of the way there
The difficulty I am facing is traversing monomial
Francesco Biscani
@bluescarni
Jan 30 13:04
yes you can access directly the polynomial term container via the _container() method of polynomial
maybe this is a bit confusing, there are 2 ways of iterating over the terms of a monomial
sorry I mean terms of a polynomial
if you use directly the begin()/end() functions of a polynomial, you get "fat" iterators
these are iterators that transform on the fly the low-level representation of each term in a coefficient-monomial pair, in which the monomial is a polynomial itself
that is, begin()->first gets you the coefficient
begin()->second gives you the monomial represented as a polynomial with only 1 term, and unitary coefficient
if it makes any sense...
Andrew Corrigan
@andrewcorrigan
Jan 30 13:08
yup, that's what I am using currently
Francesco Biscani
@bluescarni
Jan 30 13:09
ok... the idea was that the internal term/cf/monomial representation is to be used for low-level algorithms, as it has a more cumbersome interface
Andrew Corrigan
@andrewcorrigan
Jan 30 13:10
so basically what I am currently struggling with is instead of printing monomial (begin()->second) as x*2y instead as pow2(x)*y
x**2
so I am trying to figure out how to traverse the terms within the monomial
Francesco Biscani
@bluescarni
Jan 30 13:11
so what you can do in your case is to try to iterate over the low-level representation of the terms, something like:
for (const auto &t: polynomial._container()) {

}
if you do this, t is not any more a pair. It's a structure containing 2 members, one called m_cf (the coefficient) and the other m_key (the monomial)
Andrew Corrigan
@andrewcorrigan
Jan 30 13:12
do I need polynomial.get_symbol_set() as well?
Francesco Biscani
@bluescarni
Jan 30 13:12
yes, that gives you the list of symbols in the polynomial (that is, the polynomial's variables)
if you use the m_key member, you don't see the variables' names, only the exponent values
m_key is basically just a vector of integers essentially, the exponents of each monomial
what kind of monomial type are you using?
Andrew Corrigan
@andrewcorrigan
Jan 30 13:14
using Monomial = piranha::monomial<int>;
Francesco Biscani
@bluescarni
Jan 30 13:15
ok that's good... then for instance you can do:
for (const auto &t: polynomial._container()) {
   std::cout << "the exponent of the first variable for this term is: " << t.m_key[0] << '\n';
}
Andrew Corrigan
@andrewcorrigan
Jan 30 13:16
when you do: it->m_key.print(oss_key, args); what is m_key's actual type?
where is that print function coming from?
Francesco Biscani
@bluescarni
Jan 30 13:17
m_key is a piranha::monomial<int>. The print() function is a method of the piranha::monomial<int> class
Andrew Corrigan
@andrewcorrigan
Jan 30 13:17
oh ok
so does every monomial in a polynomial store exponents for every single variable ?
it looks like each monomial is printed using the full polynomial.get_symbol_set()
Francesco Biscani
@bluescarni
Jan 30 13:20
yes. monomials are essentially just dense vectors of exponents
Andrew Corrigan
@andrewcorrigan
Jan 30 13:21
I think it's making sense :smile:
Francesco Biscani
@bluescarni
Jan 30 13:21
in order to "know" the name of the variable to which an exponent correponds, the print() function needs to also the symbol set to be passed to it
Andrew Corrigan
@andrewcorrigan
Jan 30 13:22
I see that now, thank you
Francesco Biscani
@bluescarni
Jan 30 13:22
otherwise, from the monomial's point of view it's just a sequence of numerical exponents
sure np
if you have good ideas for a customisable printing API, please share :)
Andrew Corrigan
@andrewcorrigan
Jan 30 13:23
come to think of it, I think it's easier to just traverse the polynomial
not just for printing
Francesco Biscani
@bluescarni
Jan 30 13:25
yeah probably... btw, the terms are unordered in the polynomial, so if you need to print the lowest degree terms first (for instance), you'll have to sort the terms. One possible way is to traverse the polynomial storing pointers to the terms in a vector, and then sort that vector according to whatever sorting order you need
Andrew Corrigan
@andrewcorrigan
Jan 30 13:25
oh ok, I'm not too worried about that
but thanks for explaining that
before I forget, is this: https://arxiv.org/abs/0907.2076 the paper to cite?
Francesco Biscani
@bluescarni
Jan 30 13:29
there's no paper (yet) for the modern version of piranha unfortunately. I have registered a DOI with zenodo, so for the time being this should be used for citation https://zenodo.org/record/246239
there's a bibtex export thingie on the bottom right of the page
Andrew Corrigan
@andrewcorrigan
Jan 30 13:30
got it
Francesco Biscani
@bluescarni
Jan 30 13:30
cheers
Andrew Corrigan
@andrewcorrigan
Jan 30 14:46
sorry, one more question
I noticed that the print method in monomial changed
I think the newer version loops over with: for (decltype(args.size()) i = 0; std::get<1>(sbe) != std::get<2>(sbe); ++i, ++std::get<1>(sbe), ++it_args) { vs. the older version which loops over with for (typename base::size_type i = 0u; i < this->size(); ++i) {
When I print out the dereference of it_args using the older code, it prints out like: name = '_dx(1)'
instead of just _dx(1)
which approach is preferable?
Francesco Biscani
@bluescarni
Jan 30 14:49
the symbol name is just _dx(1) right? (without the quotes)
ah right I see now. In the curren git version of piranha, symbols have become just plain strings, so when you print them you just print the plain content of the string representing that symbol
in earlier versions the symbol was a separate class, and its overloaded operator would place '' quotes around the symbol name when printed to screeen
Andrew Corrigan
@andrewcorrigan
Jan 30 15:29
which would you recommend I use?
I'd prefer to stick with the newer version
Francesco Biscani
@bluescarni
Jan 30 15:30
I think that's better yes.
Andrew Corrigan
@andrewcorrigan
Jan 30 17:04

I tried the newer version, but hit some errors trying to build: ```CMake Error at CMakeLists.txt:89 (find_package):
By not providing "Findmp++.cmake" in CMAKE_MODULE_PATH this project has
asked CMake to find a package configuration file provided by "mp++", but
CMake did not find one.

Could not find a package configuration file provided by "mp++" (requested
version 0.8) with any of the following names:

mp++Config.cmake
mp++-config.cmake

```

Francesco Biscani
@bluescarni
Jan 30 20:05
The most recent version of piranha now depends on the mp++ library, which is available here https://github.com/bluescarni/mppp
Francesco Biscani
@bluescarni
Jan 30 21:12
let me know if you need help with that