These are chat archives for bluescarni/pagmo_reborn

24th
May 2016
Francesco Biscani
@bluescarni
May 24 2016 07:10
Dario Izzo
@darioizzo
May 24 2016 07:10
:) so you saw ....
Francesco Biscani
@bluescarni
May 24 2016 07:10
oh yeah
Dario Izzo
@darioizzo
May 24 2016 07:10
fucking A
Francesco Biscani
@bluescarni
May 24 2016 07:11
luckily didn't get that spoiled ;
:)
Dario Izzo
@darioizzo
May 24 2016 07:11
Yeah .... had to wait until the kids were sleeping, Francesca was spleeping the house was calm ..... internet was off etc ...
pretty awesome finale for the episode .... my favorite so far in the last two seasons
Francesco Biscani
@bluescarni
May 24 2016 07:13
yeah was really good
Marcus Märtens
@CoolRunning
May 24 2016 08:14
You are really a spoilery guy - but I saw it as well ^^
Dario Izzo
@darioizzo
May 24 2016 08:14
ups, sorry, did not think otherwise :)
this is from 2008!!!
Marcus Märtens
@CoolRunning
May 24 2016 08:18
I can't see it... :/
Marcus Märtens
@CoolRunning
May 24 2016 08:23
Ah yeah - there are more stories about that
Dario Izzo
@darioizzo
May 24 2016 08:34
The idea of not exposing to python the methods in the c++ problems such as fitness, has the added protection of avoiding to screw up with fevals counters.
I need the reference point to be mutable in the decompose class as to be able to adapt it at each fitness computation. I do not see a different option ....
Dario Izzo
@darioizzo
May 24 2016 08:53
Work on decompose finished. Tests passed. Shall I start to code differential evolution? (https://europeanspaceagency.gitlab.io/PaGMOreborn/docs/problems/decompose.html)
Francesco Biscani
@bluescarni
May 24 2016 09:01
Good job!
The use pagmo::decompose discards gradients and hessians so th
I think there's a type here
typo
Dario Izzo
@darioizzo
May 24 2016 09:02
the use of ....
r u ok with the mutable? did not see an alternative here ....
Francesco Biscani
@bluescarni
May 24 2016 09:02

Constructs a pagmo::problem decomposing a given input problem that can either be a pagmo::problem or any object a pagmo::problem can be constructed from (i.e. a user-defined problem)

Personally I'd avoid mentioning that you can construct a decompose from a problem. While true, I think it just confuses the user

I didn't get the bit about the mutable
Dario Izzo
@darioizzo
May 24 2016 09:03
Shall we just speak of "problem" without making the distinction between pagmo::problem and user-problem ...?
Francesco Biscani
@bluescarni
May 24 2016 09:04
I would push the idea that problem is just the final container in which you want to put your problem once you have finished defining it
Dario Izzo
@darioizzo
May 24 2016 09:04
Can you suggest a wording then?
to make sure we are on the same "page" :)
Francesco Biscani
@bluescarni
May 24 2016 09:05
in reality, if one uses the island I imagine that he would not even think about the problem and algorithm classes, for the island would have a templated ctor from whatever objects can be used to construct a problem and an algorithm
Dario Izzo
@darioizzo
May 24 2016 09:05
on the mutable: I know the rule is not to make mutable data members as that is a sign of a sick API .... but in this case I need to change the m_z (reference point) at each fitness call.
Francesco Biscani
@bluescarni
May 24 2016 09:05
Constructs a pagmo::problem decomposing a given input problem. The type T can be any type that can be used to construct a problem object.
or maybe we should really make this explicit, and code a is_problem type trait
Constructs a pagmo::problem decomposing a given input problem. The type T must satisfy the is_problem type trait
something like this anyway
Dario Izzo
@darioizzo
May 24 2016 09:07
or use the C++20 thingy .. what was its name?
Francesco Biscani
@bluescarni
May 24 2016 09:07
well is_problem is a C++20 compliant concept, the only difference here would be that we'd check it with a static assert
in C++200 you'd write:
Dario Izzo
@darioizzo
May 24 2016 09:07
advanced!!
we will be dead I guess
Francesco Biscani
@bluescarni
May 24 2016 09:08
template <Problem p>
decompose(....);
lol
Dario Izzo
@darioizzo
May 24 2016 09:18
I start de then.
Francesco Biscani
@bluescarni
May 24 2016 09:18
can we start with the pull request thingie?
Dario Izzo
@darioizzo
May 24 2016 09:18
ok ... tell me how. I make a branch?
call it de_works ... then work on it
Francesco Biscani
@bluescarni
May 24 2016 09:19
yes... git checkout -b de_works then git push -u origin de_works
Dario Izzo
@darioizzo
May 24 2016 09:19
then at the end well see?
k
Francesco Biscani
@bluescarni
May 24 2016 09:20
so regarding the mutable, I think it's fine... but I was thinking that with all this mutable stuff going on maybe we should assume that problem functions are never called concurrently
do we have a need for a fitness() to be computed on the same object multiple times concurrently?
well the init thing right? which is not in old pagmo
Dario Izzo
@darioizzo
May 24 2016 09:21
Maybe for the parallel population construction?
Francesco Biscani
@bluescarni
May 24 2016 09:21
how would you deal with this from the point of view of the decompose problem?
put a mutex and pay the iron price?
Dario Izzo
@darioizzo
May 24 2016 09:21
on m_z ?
Francesco Biscani
@bluescarni
May 24 2016 09:22
is that the mutable member?
Dario Izzo
@darioizzo
May 24 2016 09:22
yes
Francesco Biscani
@bluescarni
May 24 2016 09:22
you would need to put a mutex each time you read and write from/to it
actually
it even depends on how it is used
it looks ugly
Dario Izzo
@darioizzo
May 24 2016 09:24
the other option is to adapt the reference point outside the decompose, but then one has to construct a new decompose object at each adaptation?
Francesco Biscani
@bluescarni
May 24 2016 09:24
meh... the only sane way would be to lock the entire fitness function if the mutable member is used
it's only with one specific decompose method right?
I don't know, this parallel thing complicates things quite a bit
Dario Izzo
@darioizzo
May 24 2016 09:25
tchebycheff and bi
Lets lock it then .... whats the cost?
Francesco Biscani
@bluescarni
May 24 2016 09:26
I mean, what do you gain by parallelizing the pop init? It seems like you would get a better asymptotic complexity only for ridiculous workloads
like init a population, do 1 generation evolution, stop and don't do any more evolutions
Dario Izzo
@darioizzo
May 24 2016 09:27
Many users have requested it. Here is what happens. They are happy about pagmo parallelizing stuff. They have a prob that takes 1 min per feval. They set up their archi so that 1 gen is completed in 2 min and they like watching on screen to monitor what is going on.
When they construct the population for the firts time they have to wait 30 min - 1 hour .... they get bored, drink too much coffee, become nervous and BOOOM
locking the fitness of decompose does not seem bad as a solution
Francesco Biscani
@bluescarni
May 24 2016 09:28
but I mean, isn't it like saving 10k euros on a project with 10M euro budget? Aren't they going to spend ages anyway to evolve this thing?
Dario Izzo
@darioizzo
May 24 2016 09:29
As I said they like watching the screen and seeing things happen
Francesco Biscani
@bluescarni
May 24 2016 09:29
I agree it'd be nice, but it puts a huge constraint on the design
Dario Izzo
@darioizzo
May 24 2016 09:29
Only for decompose?
Francesco Biscani
@bluescarni
May 24 2016 09:29
I was also looking at the nlopt stuff exposition... (ok that's algo and not problem but bear with me)
it looks look like it would benefit a lot from mutable vectors in the class in which to store the nlopt data structures
but if you operate on the assumption that you neeed to be thread safe, it becomes a mess
Dario Izzo
@darioizzo
May 24 2016 09:31
but the problem is not the mutable, is that that member is actually changed between successive fitness (evolve) calls
which is only the case for decompose no?
Francesco Biscani
@bluescarni
May 24 2016 09:31
it's the assumption of certain things not happening concurrently which simplifies a lot
Dario Izzo
@darioizzo
May 24 2016 09:32
well then there is also the stochastic set seed m_seed right?
Francesco Biscani
@bluescarni
May 24 2016 09:32
yep
I guess? is it called form objfun or from the algorithm?
Dario Izzo
@darioizzo
May 24 2016 09:33
actually the m_seed is not mutable, m_e is mutable
Francesco Biscani
@bluescarni
May 24 2016 09:33
I mean, we neeed to have a clear idea on what can happen concurrently and what cannot
Dario Izzo
@darioizzo
May 24 2016 09:33
the random engine
Francesco Biscani
@bluescarni
May 24 2016 09:33
both for our sanity and for documentation for the users
Dario Izzo
@darioizzo
May 24 2016 09:33
I think I can get rid with a workaround of the mutable in decompose.
would that save the design complications?
I mean a policy to forbid mutable stuff in fitness / evolve ?
Francesco Biscani
@bluescarni
May 24 2016 09:35
we still need to decide about this concurrency thing, because if we do the parallel init for instance we need to make the user aware of the implications
Dario Izzo
@darioizzo
May 24 2016 09:35
I mean assuming that calls to fitness and evolve do not change the object state if not for the rng ?
Francesco Biscani
@bluescarni
May 24 2016 09:35
it's simple, we need to decide which methods must be safe for call from multiple threads and which methods do not
Dario Izzo
@darioizzo
May 24 2016 09:35
such as?
but the rng is safe right?
Francesco Biscani
@bluescarni
May 24 2016 09:36
what do you mean?
Dario Izzo
@darioizzo
May 24 2016 09:36
I mean that the rng is a mutable member of most classes and it is modified in fitness and evolve.
Francesco Biscani
@bluescarni
May 24 2016 09:36
mutable and thread safety are two separate things
Dario Izzo
@darioizzo
May 24 2016 09:36
But that was never a problem. SO what is the difference with m_z ?
But this discussion started with m_z being mutable right?
Francesco Biscani
@bluescarni
May 24 2016 09:37
if I do parallel init on a decompose problem, I am modifying the member of the decompose problem concurrently from multiple threads
Dario Izzo
@darioizzo
May 24 2016 09:37
as well as the rng
Francesco Biscani
@bluescarni
May 24 2016 09:37
does the rng come into play in fitness()?
I thought it was touched only in evolve()
Dario Izzo
@darioizzo
May 24 2016 09:38
        /// Fitness computation
        vector_double fitness(const vector_double &x) const
        {
            // We seed the random engine
            m_e.seed(m_seed);
            // We construct a uniform distribution from 0 to 1.
            auto drng = std::uniform_real_distribution<double>(0., 1.);
            // We may now start the computations
            const double c=1.0, b=1.5, h=0.1; // c is the cost per unit, b is the backorder penalty cost and h is the holding cost
            double retval=0;

            for (decltype(m_sample_size) i = 0; i<m_sample_size; ++i) {
                double I=0;
                for (decltype(x.size()) j = 0u; j<x.size(); ++j) {
                    double d = drng(m_e) * 100;
                    retval += c * x[j] + b * std::max<double>(d-I-x[j],0) + h * std::max<double>(I+x[j]-d,0);
                    I = std::max<double>(0, I + x[j] - d);
                }
            }
            return {retval / m_sample_size};
        }
stochastic problem example
Francesco Biscani
@bluescarni
May 24 2016 09:38
yes same problem
Dario Izzo
@darioizzo
May 24 2016 09:39
do we have a solution? or this simply makes it unfeasible to do ?
brb
Francesco Biscani
@bluescarni
May 24 2016 09:39
we can put a lock at the beginning of fitness
but this of course has a performance impact
This message was deleted
or we can create a local copy of the rng at the beginning of the method, but that needs to be synchronised as well
actually not, all the threads would be just reading from m_e to make a copy of it, so it should be fine
need to go as well, later
Dario Izzo
@darioizzo
May 24 2016 09:52
Creating a local copy would work, actually we could then remove m_e as a member of the stochastic and just rebuild it each time fitness is called. This also would have an impact on perf, but probably minor .... at least if the fitness is actually computing some stuff
        vector_double fitness(const vector_double &x) const
        {
            // We seed the random engine
           detail::random_engine_type engine(m_seed);
            // We construct a uniform distribution from 0 to 1.
            auto drng = std::uniform_real_distribution<double>(0., 1.);
            // We may now start the computations
            const double c=1.0, b=1.5, h=0.1; // c is the cost per unit, b is the backorder penalty cost and h is the holding cost
            double retval=0;

            for (decltype(m_sample_size) i = 0; i<m_sample_size; ++i) {
                double I=0;
                for (decltype(x.size()) j = 0u; j<x.size(); ++j) {
                    double d = drng(engine) * 100;
                    retval += c * x[j] + b * std::max<double>(d-I-x[j],0) + h * std::max<double>(I+x[j]-d,0);
                    I = std::max<double>(0, I + x[j] - d);
                }
            }
            return {retval / m_sample_size};
        }
same can be done in algorithms .... the engine can be inside the evolve
Francesco Biscani
@bluescarni
May 24 2016 10:02
a static thread_local class member would be the best, performance wise
or even static internal variable actually
        vector_double fitness(const vector_double &x) const
        {
            // We seed the random engine
           static thread_local detail::random_engine_type engine(m_seed);
            // We construct a uniform distribution from 0 to 1.
            auto drng = std::uniform_real_distribution<double>(0., 1.);
            // We may now start the computations
            const double c=1.0, b=1.5, h=0.1; // c is the cost per unit, b is the backorder penalty cost and h is the holding cost
            double retval=0;

            for (decltype(m_sample_size) i = 0; i<m_sample_size; ++i) {
                double I=0;
                for (decltype(x.size()) j = 0u; j<x.size(); ++j) {
                    double d = drng(engine) * 100;
                    retval += c * x[j] + b * std::max<double>(d-I-x[j],0) + h * std::max<double>(I+x[j]-d,0);
                    I = std::max<double>(0, I + x[j] - d);
                }
            }
            return {retval / m_sample_size};
        }
Dario Izzo
@darioizzo
May 24 2016 10:02
what is that?
ah ok
Francesco Biscani
@bluescarni
May 24 2016 10:03
so you don't have to initialise it at every fitness call
Dario Izzo
@darioizzo
May 24 2016 10:03
what does that do then?
Francesco Biscani
@bluescarni
May 24 2016 10:04
a static function variable means that the variable is initialised once when it's first used, and then it persists at the successive calls right?
Dario Izzo
@darioizzo
May 24 2016 10:04
ok ...then?
Francesco Biscani
@bluescarni
May 24 2016 10:04
if you make it thread_local each thread gets its own copy of that "global" variable
so if you call fitness() from different threads, the address of engine will be different from each thread
it's a persistent variable of which each thread has its own copy
Dario Izzo
@darioizzo
May 24 2016 10:05
looks like the solution for this stochastic problem thingy ... I like it
Francesco Biscani
@bluescarni
May 24 2016 10:06
too bad OSX does not support it :)
Dario Izzo
@darioizzo
May 24 2016 10:06
wtf ...
Francesco Biscani
@bluescarni
May 24 2016 10:06
We don't support the thread_local implementation from the open-source Clang because we believe we can provide a higher-performance implementation for our platforms using various features in the dynamic linker. Such an implementation would be ABI-incompatible with the implementation in the open-source Clang, so we won't support thread_local until we get an implementation we can live with for the foreseeable future.
apple crippling everything as usual
it fucking even works on MinGW windows
but
boost.thread has a portable implementation of thread local storage
so if we really want we could require boost.thread on OSX and write a wrapper that uses thread_local or boost thread local depending on the platform
Dario Izzo
@darioizzo
May 24 2016 10:08
Same in algorithm evolve right?
no longer m_e as a data member ....
Francesco Biscani
@bluescarni
May 24 2016 10:09
sounds similar yeah
Dario Izzo
@darioizzo
May 24 2016 10:09
so we would only have to think about a fix for decompose
Francesco Biscani
@bluescarni
May 24 2016 10:11
thread_local would not work there right? because you are depending on the previous state of m_z
Dario Izzo
@darioizzo
May 24 2016 10:11
yep
but a mutex to protect the if m_adpat_ideal code would right?
Francesco Biscani
@bluescarni
May 24 2016 10:12
            // We seed the random engine
           static thread_local detail::random_engine_type engine(m_seed);
            // We construct a uniform distribution from 0 to 1.
            auto drng = std::uniform_real_distribution<double>(0., 1.);
note that this is not correct btw
because the engine is constructed once
the successive calls the constructor is not called any more
        // We seed the random engine
       static thread_local detail::random_engine_type engine;
       engine.seed(m_seed);
        // We construct a uniform distribution from 0 to 1.
        auto drng = std::uniform_real_distribution<double>(0., 1.);
I think it should be like this
Dario Izzo
@darioizzo
May 24 2016 10:13
yep
so the mutex would work in decompose?
Francesco Biscani
@bluescarni
May 24 2016 10:13
the mutex would work, but I wonder how to write it to be honest...
this will not work:
if (m_adapt_ideal) {
    std::lock_guard l;
}
cause the lock is released when l goes ouf of scope
might need to do the lock/unlock manually or something else
Dario Izzo
@darioizzo
May 24 2016 10:14
but outside the loop nothing harmful happens
Francesco Biscani
@bluescarni
May 24 2016 10:15
so you would put it after the check? ok
Dario Izzo
@darioizzo
May 24 2016 10:15
        if (m_adapt_ideal) {
            std::lock_guard l;
            for (decltype(f.size()) i = 0u; i < f.size(); ++i) {
                if (f[i] < m_z[i])
                {
                    m_z[i] = f[i]; // its mutable so its ok
                }
            }
        }
Francesco Biscani
@bluescarni
May 24 2016 10:16
but how would that work? I mean, the second time you call the fitness function you don't really know what is in m_z
cause in the meantime the content of m_z could have been changed by another thread
do you care about the content of m_z or it can be anything?
Dario Izzo
@darioizzo
May 24 2016 10:17
thats what we want ... m_z is adapted as soon as someone has a better m_z
Francesco Biscani
@bluescarni
May 24 2016 10:17
alright but it takes away determinism
I guess?
Dario Izzo
@darioizzo
May 24 2016 10:17
that I have no hope to have in asynchronous stuff
lunch train ... later
Francesco Biscani
@bluescarni
May 24 2016 10:18
alright, it just seems weird that creating a population twice will give different results
later
Francesco Biscani
@bluescarni
May 24 2016 10:47
vector_double gradient(const vector_double &dv) const
A decomposed problem does not have gradients (Tchebicheff is not differentiable)
    /// A decomposed problem does not have gradients (Tchebicheff is not differentiable)
    vector_double gradient(const vector_double &dv) const = delete;
    bool has_gradient() = delete;
    /// A decomposed problem does not have hessians (Tchebicheff is not differentiable)
    std::vector<vector_double> hessians(const vector_double &dv) const = delete;
    bool has_hessians() = delete;
I would not implement it like this... I would not touch gradient() method, I'd implementhas_gradient() to always return false
same for hessians
oh well I guess this works as well... but I'd document the fact that the members are deleted, as it is not showing up in the sphinx output
and document the deleted has_ as well
Francesco Biscani
@bluescarni
May 24 2016 10:52
we should really enabled doxygen warnings for undocumented members, we are not doing any check about documentation status
and IMO we should also change the doxygen setup to display inherited members as well
it's much handier than browsing back to the problem documentation to see what the name of the inherited method was
Tchebicheff is spelled inconsistently
Francesco Biscani
@bluescarni
May 24 2016 10:59
with a tolerance of E1-8
if (m_weight[i] < 0.) {
                pagmo_throw(std::invalid_argument,"The weight vector may contain only positive values. A value of " + std::to_string(m_weight[i]) + " was detected at index " + std::to_string(i));
            }
only positive values or non-negative values?
    // Delete the inherited serialization functions from problem, so there is no ambiguity
    // over which serialization function to be used by cereal (the serialize() method
    // defined above will be the only serialization function available).
    template <typename Archive>
    void save(Archive &) const = delete;

    template <typename Archive>
    void load(Archive &) = delete;
I think we should try to see if it works to move these two into private, as they just clutter the public interface like that... it should be done in the translate meta-problem as well
Dario Izzo
@darioizzo
May 24 2016 11:11
    /// A decomposed problem does not have gradients (Tchebicheff is not differentiable)
    vector_double gradient(const vector_double &dv) const = delete;
    bool has_gradient() = delete;
    /// A decomposed problem does not have hessians (Tchebicheff is not differentiable)
    std::vector<vector_double> hessians(const vector_double &dv) const = delete;
    bool has_hessians() = delete;
what about putting all this into private?
Francesco Biscani
@bluescarni
May 24 2016 11:13
yeah I was thinking about that
but I figured I had written enough already :)
Dario Izzo
@darioizzo
May 24 2016 11:13
never enough ... love the code reviews :)
Francesco Biscani
@bluescarni
May 24 2016 11:13
you must be a masochist :)
Dario Izzo
@darioizzo
May 24 2016 11:14
on the doxygen ... ok for undocumented member warnings ... I actually thought they were already there
On it just seems weird that creating a population twice will give different results -> we still need to give the option to construct the population the old way
The parallel stuff would only be an option, documenting the "risks"
Francesco Biscani
@bluescarni
May 24 2016 11:15
yeah just need a ctor argument probably
maybe the weight vector should be checked for infs & nans on construction?
Dario Izzo
@darioizzo
May 24 2016 11:20
@darioizzo
WARN_IF_UNDOCUMENTED = YES
looks like it is active right?
k
on nans and inf, they are indirectly checked by the condions >0 and sum==1 ... want to add an explicit check?
Francesco Biscani
@bluescarni
May 24 2016 11:22
ah ok missed that one
should be good then
m_weight[i] < 0. should this be a leq?
Dario Izzo
@darioizzo
May 24 2016 11:23
zeros are allowed.
Francesco Biscani
@bluescarni
May 24 2016 11:23
ok then the error message needs change :)
Dario Izzo
@darioizzo
May 24 2016 11:23
The problem is that if a weight is zero, then an horrid trick is used to decompose ... :
(m_weight[i] == 0.) ? (weight = 1e-4) : (weight = m_weight[i]); //fixes the numerical problem of 0 weights
Yes I changed that already ....
Francesco Biscani
@bluescarni
May 24 2016 11:25
# If the INHERIT_DOCS tag is set to YES then an undocumented member inherits the
# documentation from any documented member that it re-implements.
# The default value is: YES.

INHERIT_DOCS           = YES
ok
mhm maybe not useful
Dario Izzo
@darioizzo
May 24 2016 11:26
its only for virtuals ... I guess. I would deactivate
Francesco Biscani
@bluescarni
May 24 2016 11:27
right ok
I am going through piranha's doxygen to parse various options
Dario Izzo
@darioizzo
May 24 2016 11:45
is the CI in electra?
Francesco Biscani
@bluescarni
May 24 2016 11:46
no, eamma
emma
Dario Izzo
@darioizzo
May 24 2016 11:51
emme is full of stuff, but why the CI does not start?
did you put it in low priority?
Francesco Biscani
@bluescarni
May 24 2016 11:51
no I did not set any priority
Dario Izzo
@darioizzo
May 24 2016 11:52
can you check quickly what is going on?
Francesco Biscani
@bluescarni
May 24 2016 11:52
I uploaded a new version of the doxyfile, which gives some warnings now... if you want to check it out
Dario Izzo
@darioizzo
May 24 2016 11:52
k
Francesco Biscani
@bluescarni
May 24 2016 11:53
what's the tunnel to get to emma?
Dario Izzo
@darioizzo
May 24 2016 11:53
boh 9999 ? 8000? 8001 ?
Francesco Biscani
@bluescarni
May 24 2016 11:53
but where? electra os sophia?
Dario Izzo
@darioizzo
May 24 2016 11:54
boh sophia?
maybe electra?
Francesco Biscani
@bluescarni
May 24 2016 11:54
ok I am in
Dario Izzo
@darioizzo
May 24 2016 11:54
I never use it I am inside :)
Francesco Biscani
@bluescarni
May 24 2016 11:58
well there's an update for the runner, I am gonna install it and try to restart
ok it seems like it hanged... gitlab-ci-multi-runner stop would hang as well, so I killed the process manually and then gitlab-ci-multi-runner start
now:
root@emma /home/bluescarni $ gitlab-ci-multi-runner status
gitlab-runner: Service is running!
Dario Izzo
@darioizzo
May 24 2016 12:02
indeed the pipelines are getting processed
Francesco Biscani
@bluescarni
May 24 2016 12:06
we might consider actually putting in private and deleteing all the extra members inherited from problem by the meta problems
Dario Izzo
@darioizzo
May 24 2016 12:07
bella merda!
Francesco Biscani
@bluescarni
May 24 2016 12:08
:D
well the methods were always there, they were just swept under the rug by not having documentation emitted for them
Dario Izzo
@darioizzo
May 24 2016 12:08
true
if we delete them in private sure they will not appear?
Francesco Biscani
@bluescarni
May 24 2016 12:09
I hope so, let me try
Dario Izzo
@darioizzo
May 24 2016 12:09
gradient is deleted, but is there ...
Francesco Biscani
@bluescarni
May 24 2016 12:10
not in decompose
it's not deleted in translate is it?
Dario Izzo
@darioizzo
May 24 2016 12:10
ah thats translate ...
now its even difficult to tell :)
Francesco Biscani
@bluescarni
May 24 2016 12:10
but so it means this works then
Dario Izzo
@darioizzo
May 24 2016 12:11
so I delete all .. ok?
Francesco Biscani
@bluescarni
May 24 2016 12:12
all that we do not want in the meta problems yes
I mean
stuff like extract I guess?
the set seed thingie and has_set_seed is still useful right?
Dario Izzo
@darioizzo
May 24 2016 12:13
boh they will exist in problem(translate) so .. no
I would delete everything
Francesco Biscani
@bluescarni
May 24 2016 12:13
right but problem enables the seed if translate has it
Dario Izzo
@darioizzo
May 24 2016 12:13
only the methods called via the static cast will stay
Francesco Biscani
@bluescarni
May 24 2016 12:14
if you erase the seed stuff problem will not expose it because as far as it is concerned translate does not expose any seed stuff
the get_nic/nec stuff can go for instance
get_nx/get_nf
get_nc
get_f/g/h_evals
gs_dim/hs_dim
is_stochastic
wait
nic/nec has to stay, these are part of the concrete problem interface
but the rest is all extra gook provided by problem, that's not needed for a concrete problem
Dario Izzo
@darioizzo
May 24 2016 12:18
I do not follow your logic
I can delete get_nic
then when a translate is used to construct a problem it gets the default value.
Francesco Biscani
@bluescarni
May 24 2016 12:19
translate(shitcock{}) then this will have no constraintt will it?
or am I misunderstanding?
Dario Izzo
@darioizzo
May 24 2016 12:20
np you are right ... I think it ois clearer for me to think about :
Francesco Biscani
@bluescarni
May 24 2016 12:21
it's because of the recursive nature of this: a problem contains all the interface of a concrete, user-defined problem, plus extra gook
Dario Izzo
@darioizzo
May 24 2016 12:21
        vector_double::size_type get_nobj() const
        {
            return static_cast<const problem*>(this)->get_nobj();
        }
Francesco Biscani
@bluescarni
May 24 2016 12:22
and we don't need the extra gook
Dario Izzo
@darioizzo
May 24 2016 12:22
and then only delete methods that are not calling a static_cast
rather than not implement get_nobj and rely on the hidden mechanism
Francesco Biscani
@bluescarni
May 24 2016 12:24
I think as a rule of thumb we need to delete everything that is not part of the user-defined problem interface plus extra stuff depending on the specific meta-problem (e.g., the gradient for the decomposed problem)
Dario Izzo
@darioizzo
May 24 2016 12:24
yep got it
Dario Izzo
@darioizzo
May 24 2016 12:42
have a look
Francesco Biscani
@bluescarni
May 24 2016 12:46
in translate it looks like we still have the gs/hs dim stuff
but otherwise it looks good
we need to revise the nomenclature though in the documentation
Constructs a pagmo::problem translating a pagmo::problem by a translation vector.
I think it should be more along the lines of Wraps a user-defined problem so that its fitness , bounds, .... etc. will be translated by a fixed amount. pagmo::translate objects can be used as user-defined problems in the construction of a pagmo::problem.
or something along these lines
Dario Izzo
@darioizzo
May 24 2016 12:51
Constructs a pagmo::problem which translates the whole search space of an input problem by a fixed translation vector
Francesco Biscani
@bluescarni
May 24 2016 12:51
it does not construct a pagmo::problem, the fact that we inherit from it is just an implementation detail to make our life easier
I wish we could hide this fact somehow
Dario Izzo
@darioizzo
May 24 2016 12:53
Wraps a user-defined problem so that its fitness , bounds, .... etc. will be shifted by a translation vector. pagmo::translate objects can be used as user-defined problems in the construction of a pagmo::problem.
Francesco Biscani
@bluescarni
May 24 2016 12:58
I mean, from the point of view of the user everythin should just work... given a user defined problem up, problem p{translate{up,{1,2,3}}}
p will have all the properties of up forwarded correctly
Dario Izzo
@darioizzo
May 24 2016 12:59
yes .... and this is the case as far as we know ... right?
Francesco Biscani
@bluescarni
May 24 2016 12:59
yes, barring bugs this is what we have know, and I think it's really cool
Dario Izzo
@darioizzo
May 24 2016 13:00
indeed ...
SO to open a pull request .. whats the workflow?
a merge request
whats with the WIP?
Francesco Biscani
@bluescarni
May 24 2016 13:01
you con on the merge request tab, click on "open a new merge request button" (green top right button), and select the base branch and the target branch
Dario Izzo
@darioizzo
May 24 2016 13:01
and the WIP ?
Francesco Biscani
@bluescarni
May 24 2016 13:01
it's just some convention from gitlab, it doesn't do something if the current descripption of the MR starts with WIP
Dario Izzo
@darioizzo
May 24 2016 13:02
k
Francesco Biscani
@bluescarni
May 24 2016 13:08
nice new MR :)
Dario Izzo
@darioizzo
May 24 2016 13:08
playing around ... but its cool
Francesco Biscani
@bluescarni
May 24 2016 13:08
you can keep it in sync with master (or any other branch) by doing periodic merges
from de_works: git merge master (after pulling the latest master changes)
Dario Izzo
@darioizzo
May 24 2016 13:09
I guess we do not touch master now
Francesco Biscani
@bluescarni
May 24 2016 13:09
yeah indeed... but maybe other MRs are merged in the meantime
Dario Izzo
@darioizzo
May 24 2016 13:09
from the other 23422 developers?
could be could be
Francesco Biscani
@bluescarni
May 24 2016 13:09
exactly!
@CoolRunning made an MR for you too :)
Dario Izzo
@darioizzo
May 24 2016 13:12
lol shame on you the red cross :)
Francesco Biscani
@bluescarni
May 24 2016 13:13
booo
Dario Izzo
@darioizzo
May 24 2016 13:13
@CoolRunning make a merge from master first... a few things were changed
or you did it @bluescarni already?
Francesco Biscani
@bluescarni
May 24 2016 13:13
no I just opened the MR
Marcus Märtens
@CoolRunning
May 24 2016 13:14
What is happening?
Dario Izzo
@darioizzo
May 24 2016 13:14
We are experimenting with merge requests .. they cool!
Marcus Märtens
@CoolRunning
May 24 2016 13:14
:worried:
Francesco Biscani
@bluescarni
May 24 2016 13:16
@CoolRunning you don't have to do anything special, just keep on working on your branch as usual
I can do the merges from master periodically
btw I got a beta key for the new docker version on windows
basically they replaced virtualbox with the windows native virtual machine https://en.wikipedia.org/wiki/Hyper-V and an alpine linux distro on top
supposedly it should be easier and more lightweight
but I have not tried it out yet
Dario Izzo
@darioizzo
May 24 2016 13:20
i had just set up docker on my windows ... :(
Marcus Märtens
@CoolRunning
May 24 2016 13:22
Okay, working on my branch and try to deny we are using git :D
I also have Docker on Windows - whats the problem?
Dario Izzo
@darioizzo
May 24 2016 13:23
apparently a new docker was released that does not use virtualbox and is more efficient ...
Francesco Biscani
@bluescarni
May 24 2016 13:23
supposedly the new version should work better performance wise and it should also be easier to use
Marcus Märtens
@CoolRunning
May 24 2016 13:23
Ah - true, you needed OracleVM
But this I already had, so it wasn't a bother
Francesco Biscani
@bluescarni
May 24 2016 13:32
@CoolRunning I merged master into the hypervolume branch, you will have to pull before making the next push
Marcus Märtens
@CoolRunning
May 24 2016 13:33
Thanks! I can't do it at work, but I wanted to code something later at home. Will do a pull.
Francesco Biscani
@bluescarni
May 24 2016 13:33
sure np
Dario Izzo
@darioizzo
May 24 2016 13:40
so on the discussed changes of the mutable members, what do we do? we delay to when we code the thread stuff?
so now I code de with a mutable m_e ?
Francesco Biscani
@bluescarni
May 24 2016 13:41
you mean for the engine and for the m_x in decompose?
Dario Izzo
@darioizzo
May 24 2016 13:41
m_z yes ...
Francesco Biscani
@bluescarni
May 24 2016 13:42
maybe we can start adopting the proposed solutions right now, and when the build breaks we try to fix the OSX mess?
or alternatively just add NOTE in those two spots
for the moment
Dario Izzo
@darioizzo
May 24 2016 13:42
pick one
Francesco Biscani
@bluescarni
May 24 2016 13:43
let's just do the NOTE for now
Dario Izzo
@darioizzo
May 24 2016 13:43
k
its a bigger change, at the moment we say:
* In PaGMO, all classes that contain a random engine (thus that generate
 * random numbers from variates), by default should contain something like:
 * @code
 * #include "rng.hpp"
 * class class_using_random {
 * explicit class_using_random(args ...... , unsigned int seed = pagmo::random_device::next()) : m_e(seed), m_seed(seed);
 * private:
 *    // Random engine
 *    mutable detail::random_engine_type               m_e;
 *    // Seed
 *    unsigned int                                     m_seed;
 * }
 * @endcode
 */
while it will be:
* In PaGMO, all classes that contain a seed (used to build random engines to generate
 * random numbers from variates), by default should contain something like:
 * @code
 * #include "rng.hpp"
 * class class_using_random {
 * explicit class_using_random(args ...... , unsigned int seed = pagmo::random_device::next()) : m_seed(seed);
 * private:
 *    // Seed
 *    unsigned int                                     m_seed;
 * }
 *
 * later in the methods where random numbers are used:
 * static thread_local detail::random_engine_type engine(m_seed);
 *
 * or
 * 
 * static thread_local detail::random_engine_type;
 * engine.seed(m_seed);
 * @endcode
 */
btw, this prevents (in the first use case) to reset the seed .....
no big deal I would argue
Francesco Biscani
@bluescarni
May 24 2016 13:48
to be honest I'd place this discussion in the tutorial, because from the point of view of the C++ API the seed method only deal with unsigned ints that are passed to the problem, but there's no mention of RNGs
but for now that'll do
Dario Izzo
@darioizzo
May 24 2016 14:03
The algorithm log will remain mutable, but deactivated in multithread things via forcing set_verbose(0u) OK?
I mean the log is only for the user to monitor the single thread algorithm flow ......
Or we could also make that static thread_local
Francesco Biscani
@bluescarni
May 24 2016 14:05
is there any necessity to make that thread safe?
it would not be used in pop init, are there concrete use cases?
Dario Izzo
@darioizzo
May 24 2016 14:06
the m_log is accessed and written during each evolve call.
I thought these things were worrying you ...
Then its just accessed via extract ...
Francesco Biscani
@bluescarni
May 24 2016 14:06
we don't expect to call multiple evolve on the same object at the same time do we?
Dario Izzo
@darioizzo
May 24 2016 14:07
I expect nothing at this point
its a bit like FP
Francesco Biscani
@bluescarni
May 24 2016 14:07
FP?
I mean if we don't have use cases let's do nothing, because otherwise soon we'll be trying to overengineer thread safety where it's not needed
Dario Izzo
@darioizzo
May 24 2016 14:07
would you expect that a particle can behave like a wave and a ball at the same time? or sometime like an elephant in a time machine?
Francesco Biscani
@bluescarni
May 24 2016 14:07
which is a huge pain
Dario Izzo
@darioizzo
May 24 2016 14:08
k
FP -> Fundamental Physics
Francesco Biscani
@bluescarni
May 24 2016 14:08
I am still amazed by the time travelling twist of GoT
don't talk me about time travel
hold the door
Dario Izzo
@darioizzo
May 24 2016 14:08
yeah ... super cool and unexpected .... but scary
is this going to go the LOST way?
like no fucking way to explain all this shit at this point
will it make sense?
Francesco Biscani
@bluescarni
May 24 2016 14:09
funnily enough, last episode's director was the guy from lost that used to make all the trippy time travel episodes
Dario Izzo
@darioizzo
May 24 2016 14:09
time travel is possible (even if via magic)? or this was a weird una tantum thing
?
really? o fuck
Francesco Biscani
@bluescarni
May 24 2016 14:09
well this was really cool and well done I think.. because it showed that even if you go in the past you cannot change it
Dario Izzo
@darioizzo
May 24 2016 14:10
but the present can change the past
Francesco Biscani
@bluescarni
May 24 2016 14:10
I think Bran will have to learn this time travelling shit, because it's basically his fault if Hodor became handicapped and then killed
I tihink it's a cool twist on the prophecy/destiny trope
Dario Izzo
@darioizzo
May 24 2016 14:14
but the Novikov stuff is violated right?
Bran goes back and changes Hodor into an handicapped ....
Francesco Biscani
@bluescarni
May 24 2016 14:15
I don't think so.. Bran going back was necessary for Hodor to be there and hold the door
it's like a closed timelike curve in GR
Dario Izzo
@darioizzo
May 24 2016 14:17
This message was deleted
Marcus Märtens
@CoolRunning
May 24 2016 14:21
Causality loop >.<
Marcus Märtens
@CoolRunning
May 24 2016 19:32
I know them - they are great :D