These are chat archives for bluescarni/pagmo_reborn

27th
Jun 2016
Dario Izzo
@darioizzo
Jun 27 2016 09:19 UTC
BOOST_AUTO_TEST_CASE(safe_cast_test)
{
    unsigned short s = std::numeric_limits<unsigned short>::max();
    unsigned long l = std::numeric_limits<unsigned long>::max();
    BOOST_CHECK_NO_THROW(safe_cast<unsigned long>(s));
    BOOST_CHECK_THROW(safe_cast<unsigned short>(l), std::overflow_error);
}
is this going to pass on all architectures?
Francesco Biscani
@bluescarni
Jun 27 2016 09:20 UTC
not the second test
Dario Izzo
@darioizzo
Jun 27 2016 09:20 UTC
thats what I thought short can be the same range as long right?
Francesco Biscani
@bluescarni
Jun 27 2016 09:20 UTC
if (l > s) {
    BOOST_CHECK_THROW(...);
}
Dario Izzo
@darioizzo
Jun 27 2016 09:21 UTC
but then the comparison between different unsinged types bothers no?
Francesco Biscani
@bluescarni
Jun 27 2016 09:21 UTC
no there's no problem in comparing unsigned quantities. the narrow one gets promoted to the wide one, and it is always safe
Dario Izzo
@darioizzo
Jun 27 2016 09:21 UTC
:) ok cool
btw... the code on the factorial ...
took me 1 hour to get it ...
Francesco Biscani
@bluescarni
Jun 27 2016 09:22 UTC
the compiler might complain that it is always true though
Dario Izzo
@darioizzo
Jun 27 2016 09:22 UTC
and I did not manage :)
Francesco Biscani
@bluescarni
Jun 27 2016 09:22 UTC
you mean that with log gamma?
Dario Izzo
@darioizzo
Jun 27 2016 09:23 UTC
no your constexpr
Francesco Biscani
@bluescarni
Jun 27 2016 09:23 UTC
ah the primes you mean
Dario Izzo
@darioizzo
Jun 27 2016 09:23 UTC
true, sorry
the primes yes
its kinda short though .... elegant
Francesco Biscani
@bluescarni
Jun 27 2016 09:23 UTC
it's not very well written, and just sparsely tested
I think it's cool to generate data at compile time
Dario Izzo
@darioizzo
Jun 27 2016 09:24 UTC
super cool
Francesco Biscani
@bluescarni
Jun 27 2016 09:25 UTC
like in video games, they often use lookup tables to compute sqrt/sin/cos for performance
Dario Izzo
@darioizzo
Jun 27 2016 09:25 UTC
But you mentioned gcc mess it up with compile time right?
Francesco Biscani
@bluescarni
Jun 27 2016 09:25 UTC
it's not too bad, I think the memory usage spike was worse... but I tested it with something like N = 10^5, so...
and I'd expect it to improve rapidly
Dario Izzo
@darioizzo
Jun 27 2016 09:26 UTC
I am inclined to insert it to generate PaGMO primes no?
A matter of elegance.
Francesco Biscani
@bluescarni
Jun 27 2016 09:26 UTC
well I am not 100% sure it works with GCC 4.9 for instance, and it needs to be cleaned up a bit
Dario Izzo
@darioizzo
Jun 27 2016 09:27 UTC
ok in case .. in the future ...
Francesco Biscani
@bluescarni
Jun 27 2016 09:27 UTC
constexpr support was kinda shaky before GCC 5
yeah
Francesco Biscani
@bluescarni
Jun 27 2016 09:45 UTC
➜  temp time g++ -std=c++14 -Wall -Wextra -pedantic erato.cpp
g++ -std=c++14 -Wall -Wextra -pedantic erato.cpp  0.94s user 0.45s system 99% cpu 1.398 total
➜  temp time  clang++ -std=c++14 -Wall -Wextra -pedantic erato.cpp
clang++ -std=c++14 -Wall -Wextra -pedantic erato.cpp  0.36s user 0.02s system 98% cpu 0.380 total
this is with N = 10^4
Dario Izzo
@darioizzo
Jun 27 2016 15:22 UTC
This message was deleted
This message was deleted
Dario Izzo
@darioizzo
Jun 27 2016 15:31 UTC
Is there a good way to do:
neigh_idxs[i].erase(neigh_idxs[i].begin() + static_cast<int>(k), neigh_idxs[i].end());
The static_cast hides the usual problem as k is of type vector_double::size_type
Francesco Biscani
@bluescarni
Jun 27 2016 20:48 UTC
well now I know why they call it "king's landing"
Francesco Biscani
@bluescarni
Jun 27 2016 20:55 UTC
neigh_idxs[i].erase(neigh_idxs[i].data() + k, neigh_idxs[i].data() + neigh_idxs[i].size());
Dario Izzo
@darioizzo
Jun 27 2016 21:54 UTC
wow just finished to watch it
wo wow wow
I tried you solution before posting, but did not work ... will do it again tomorrow maybe I did something stupid