These are chat archives for bluescarni/pagmo_reborn

6th
May 2016
Francesco Biscani
@bluescarni
May 06 2016 13:04
@darioizzo you there?
Dario Izzo
@darioizzo
May 06 2016 13:42
olla
I am now ... @bluescarni
Francesco Biscani
@bluescarni
May 06 2016 13:44
oll
alcuni commenti/domande su population
Dario Izzo
@darioizzo
May 06 2016 13:45
dai
Francesco Biscani
@bluescarni
May 06 2016 13:45
allora ho messo un po' di check aggiuntivi sul push_back()
credo che probabilmente bisogna astrarli e condividerli con il set_x()
ma cmq l'idea e' di controllare non solo wrt problem dimension etc, ma anche che sia consistente con i vettori gia' esistenti nella popolazione
Dario Izzo
@darioizzo
May 06 2016 13:47
Non si puo dare per scontato visto che l' unico modo per inserire e' controllato?
Francesco Biscani
@bluescarni
May 06 2016 13:48
l'idea e' di fornire delle garanzie anche contro problemi pessimi
tipo problem::get_nobj() const { if (friday) return 1 else return 2;} :)
essenzialmente forniamo la strong guarantee che la population ha:
  • 3 vettori di dimensioni uguali,
  • m_x e m_f contengono tutti vettori delle stesse dimensioni
Dario Izzo
@darioizzo
May 06 2016 13:52
Si, pensavo solo gia' la stessimo garantendo. Take the problem dimension get_nx(), this returns the m_nx member which is defined at construction only and then it cannot be changed.
Francesco Biscani
@bluescarni
May 06 2016 13:52
non e' una garanzia, e' qualcosa che chiediamo all'utente
Dario Izzo
@darioizzo
May 06 2016 13:52
We check at each push back that the decision vector dimension is get_nx() -> hence they must all be the same
Francesco Biscani
@bluescarni
May 06 2016 13:53
tieni presente che da python possono succedere cose turche, tipo un utente novizio che pensa di storare una copia di una variabile dentro il problema, invece e' una reference a qualcosa di esterno che poi cambia
cose cosi'
Dario Izzo
@darioizzo
May 06 2016 13:54
Boh, non vedo come si possa violare al momento la costanza di m_nx ..... ma ok checks ridondanti potenzialmente non sono una issue in quella parte del codice
Francesco Biscani
@bluescarni
May 06 2016 13:55
metti che uno fa un push back quando il problema ritorna size 2, poi la volta dopo il problema torna size 1 e provi a fare un push back di 1
questo non darebbe errori se non c'e' il check di consistenza con gli altri vettori esistenti nella pop
Dario Izzo
@darioizzo
May 06 2016 13:56
Guarda che m_nx tornerebbe sempre 2
perche e un membro del problema fissato in costruzione
credo ...
linea 495
476 scusa
m_nx = bounds.first.size();
Francesco Biscani
@bluescarni
May 06 2016 13:57
in quale clasee?
Dario Izzo
@darioizzo
May 06 2016 13:57
pagmo::problem
problem.hpp
Francesco Biscani
@bluescarni
May 06 2016 13:58
ok quello non lo avevo visto.. ma non si fa per get_nf() pero'?
Dario Izzo
@darioizzo
May 06 2016 13:58
No, perche la dimensione dei bounds viene usata per determinare (in costruzione) la dimensione del problema ... ma non e' possibile per la fitness senza sprecare una fitness eval
Allora abbiamo deciso per questa asimmetria
Francesco Biscani
@bluescarni
May 06 2016 13:59
quindi la inconsistenza potrebbe esserci per nf se non ho capito male
Dario Izzo
@darioizzo
May 06 2016 13:59
Penso di si ....
fammi vedere
return get_nobj()+get_nic()+get_nec();
si questi sono implementati dall' utente
non c'e' garanzia siano costanti
se l' utente e ' pirla
Francesco Biscani
@bluescarni
May 06 2016 14:02
e se storassimo tutto in costruzione invece?
dentro problem intendo
Dario Izzo
@darioizzo
May 06 2016 14:02
come facciamo a determinare la dimensione della fitness?
Francesco Biscani
@bluescarni
May 06 2016 14:03
non c'e' un get_nobj()?
Dario Izzo
@darioizzo
May 06 2016 14:03
ah ok allora chiediamo all' utente di scriverlo ma lo "usiamo solo una volta quando costruiamo"
Francesco Biscani
@bluescarni
May 06 2016 14:03
ma credevo chiedessimo sempre di implementarlo?
Dario Izzo
@darioizzo
May 06 2016 14:04
Si pensavo che come per nx potessimo relax il requirment ....
Anyway .. si possiamo anche aggiungere m_nf e garantirne la costanza
Francesco Biscani
@bluescarni
May 06 2016 14:04
l'idea sarebbe che chiediamo qualcosa al problema concreto solo in fase di costruzione, poi lo tocchiamo solo per la objcfun
Dario Izzo
@darioizzo
May 06 2016 14:05
si, ha senso ne avevamo anche parlato rimandando la decisione ...
Ci evita di fare checks ...
Francesco Biscani
@bluescarni
May 06 2016 14:05
il problema non era la questione degli sparsity pattern che diventano troppo grandi da storare forse?
Dario Izzo
@darioizzo
May 06 2016 14:06
si, infatti credo potremmo limitarci a:
        // Problem dimension
        vector_double::size_type m_nx;
        // Expected dimensions of the returned gradient (matching the sparsity pattern)
        vector_double::size_type m_gs_dim;
        // Expected dimensions of the returned hessians (matching the sparsity patterns)
        std::vector<vector_double::size_type> m_hs_dim;
        // Expected dimensions of the returned fitness
        vector_double::size_type m_nf;
I primi tre gia ci sono aggiungiamo il quarto
Francesco Biscani
@bluescarni
May 06 2016 14:07
io metterei anche i bounds
Dario Izzo
@darioizzo
May 06 2016 14:08
quelli sono m_nx
perche duplicare?
Francesco Biscani
@bluescarni
May 06 2016 14:08
allora toglierei m_nx e metteri i bounds
perche' ogni volta che chiediamo i bounds potrebbe arrivarci spazzatura inconsistente
solito discorso
Dario Izzo
@darioizzo
May 06 2016 14:08
basta controllare che siano m_nx
        // Decision vector and bounds  dimension
        vector_double::size_type m_nx;
        // Expected dimensions of the returned gradient (matching the sparsity pattern)
        vector_double::size_type m_gs_dim;
        // Expected dimensions of the returned hessians (matching the sparsity patterns)
        std::vector<vector_double::size_type> m_hs_dim;
        // Expected dimensions of the returned fitness
        vector_double::size_type m_nf;
Francesco Biscani
@bluescarni
May 06 2016 14:09
bisogna controllare che i due vettori abbiamo stesse dimensioni, che non siano ub < lb, range, infinities, etc.
Dario Izzo
@darioizzo
May 06 2016 14:09
Ok quindi:
        // Problem bounds 
        vector_double m_lb;
        vector_double m_ub;
        // Expected dimensions of the returned gradient (matching the sparsity pattern)
        vector_double::size_type m_gs_dim;
        // Expected dimensions of the returned hessians (matching the sparsity patterns)
        std::vector<vector_double::size_type> m_hs_dim;
        // Expected dimensions of the returned fitness
        vector_double::size_type m_nf;
Francesco Biscani
@bluescarni
May 06 2016 14:11
anche nic/nec no?
Dario Izzo
@darioizzo
May 06 2016 14:11
Ed impediamo di cambiare i bounds. Il fatto e' che essere in grado di cambiare i bounds (non in dimensione, ma in valore) e' comodo
Francesco Biscani
@bluescarni
May 06 2016 14:12
possiamo fare un metodo per cambiare i bounds, basta mettere i checks
Dario Izzo
@darioizzo
May 06 2016 14:13
Pero' non mi piace molto poi avere un problema implementato con bounds diversi da quelli del problema costruito da esso
SIamo sicuri che non e' meglio laciare la responsabilita' all' utente?
Francesco Biscani
@bluescarni
May 06 2016 14:15
ma come cambieresti i bounds una volta che hai costruito il problem?
dovresti 1) fare l'extract (quindi non puoi farlo, e.g., dall'algoritmo)
2) mettere i bounds come mutable
Dario Izzo
@darioizzo
May 06 2016 14:16
si vero
nie e nec pero forse non servono
all fine cio' che conta e la expected dimension della fitness
nobj+nec+nic
Dario Izzo
@darioizzo
May 06 2016 14:23
Quindi ricapitolando, gli unici metodi implementati dall utente che chiameremo dopo la costruzione sono fitness, gradient, hessian, gradient_sparsity e hessian sparisty. Di tutti gli altri ne registriamo il valore ritornato in costruzione e poi usiamo quello. Giusto?
Francesco Biscani
@bluescarni
May 06 2016 14:24
in teoria... e poi metterei i checks dentro problem::fitness, gradient etc. che i valori ritornati dal problema concreto sono consistenti con i valori registrati all'inizio
Dario Izzo
@darioizzo
May 06 2016 14:25
Credo funzioni, dici che dia anche piu' garanzie?
Francesco Biscani
@bluescarni
May 06 2016 14:26
beh la questione sarebbe che a quel punto population/algorithm e soci sanno solo quello che problem dice loro, che sono informazioni registrate in costruzione...
e problem si assicura che le cose che chiede al problema concreto sono consistenti con le informazioni storate inizialmente
se non costa troppo?
Dario Izzo
@darioizzo
May 06 2016 14:27
name ed extra info li lasciamo stare immagino?
o vuoi garanzie anche li?
Francesco Biscani
@bluescarni
May 06 2016 14:28
non e' importante dal punto di vista della safety, visto che l'unica cosa che si fa con quelle cose e' stamparle a stream
Dario Izzo
@darioizzo
May 06 2016 14:28
ok ... fai tu?
Francesco Biscani
@bluescarni
May 06 2016 14:28
non vedo neanche grosse controindicazioni a storarle, a meno che no ci siano informazioni nell'extra_info che cambiano nel tempo
mi piacerebbe avere la consistenza
senza dover penasre a cosa si stora e cosa no
Dario Izzo
@darioizzo
May 06 2016 14:29
per quello chiedevo
daccordo
pero comunque abbiamo le eccezioni di sparsity ...
Francesco Biscani
@bluescarni
May 06 2016 14:30
dovremmo essere piu' consistenti con i commenti, sto leggendo la classe problem e sto facendo molta fatica a capire che succede e perche' abbiamo preso certe decisioni
Dario Izzo
@darioizzo
May 06 2016 14:30
Voglio dire che dei metodi documentati qui: https://europeanspaceagency.gitlab.io/PaGMOreborn/docs/problem.html quelli senza argomenti saranno tutti storati in membri di problema tranne gli sparsity
commenti -> tipo?
Francesco Biscani
@bluescarni
May 06 2016 14:31
tutta la questione di perche' storiamo m_gs_dim per esempio
e m_hs_dim
Dario Izzo
@darioizzo
May 06 2016 14:32
Stesso motivo che stiamo discutendo, per fare i check
        void check_gradient_vector(const vector_double &gr) const
        {
            // Checks that the gradient vector returned has the same dimensions of the sparsity_pattern
            if (gr.size()!=m_gs_dim) {
                pagmo_throw(std::invalid_argument,"Gradients returned: " + std::to_string(gr.size()) + ", should be " + std::to_string(m_gs_dim));
            }
        }
Francesco Biscani
@bluescarni
May 06 2016 14:33
si' ma perche' solo quelle proprieta' e non altro? mi ricordo vagamente che aveva a che fare con il fatto che non volevamo storare i pattern densi ma di questa cosa non ho trovato traccia
Dario Izzo
@darioizzo
May 06 2016 14:33
E dove dovremmo scriverla? Non ci sono i membri.
La ragione e quella. Se dovessimo storare in memoria il valore tornato, piuttosto di costruirlo ogni volta al volo, sarebbe uno spreco enorme
Francesco Biscani
@bluescarni
May 06 2016 14:34
il punto e' che se dopo 2 settimane che l'abbiamo scritta facciamo noi fatica (o io faccio fatic :) ) a capire che succede non promette bene
Dario Izzo
@darioizzo
May 06 2016 14:34
:)
Dove vorresti loggare queste design decision?
Francesco Biscani
@bluescarni
May 06 2016 14:35
per esempio attorno ai membri m_gs_dim
Dario Izzo
@darioizzo
May 06 2016 14:36
Comunque la logica e' la seguente al momento:
  • se l'utente non implementa la sparsity, viene ritornata di default un sparsita densa (ma non storata, c'e' un metodo che la calcola al volo)
Francesco Biscani
@bluescarni
May 06 2016 14:37
probabilmente sara' piu' chiaro una volta che scriviamo la user documentation
:)
Dario Izzo
@darioizzo
May 06 2016 14:37
  • la dimensione di tale sparsita' viene registrata in costruzione (come densa se non e stato implementato il metodo, altrimenti vale cio che l'utente vuole) e usata per i checks
Esattamente come vuoi fare adesso per la m_nf
Non so se l'utente deve sapere queste cose .... l' importante e' sappia cosa puo o non puo fare ...
Francesco Biscani
@bluescarni
May 06 2016 14:38
la sparsity viene checkata al momento anche quandi si usa quella densa di default?
Dario Izzo
@darioizzo
May 06 2016 14:39
Per le dimensioni, si.
This message was deleted
scusa sbagliato linee
Allora: la sparsita viene solo verificata aver senso in costruzione. Poi sarebbe troppo costoso.
Francesco Biscani
@bluescarni
May 06 2016 14:42
in altre parole, che garanzie diamo a pagmo::algorithm quando richiede una sparsity?
Dario Izzo
@darioizzo
May 06 2016 14:43
al momento nessuna
se l'utente e stronzo ci potrebbe essere garbage li
Francesco Biscani
@bluescarni
May 06 2016 14:44
e non possiamo mettere invece il consistency check ogni volta che la ritorniamo? dicendo all'utente che e' un'operazione costosa che va fatta una volta all'inizio dell'evolve?
Dario Izzo
@darioizzo
May 06 2016 14:45
Si, allora stai attento che il metdodo check_gradient_sparsity e misleading al momento perche all interno setta anche m_gs_dim
Si puo allora farne uno cha fa soloi check da ripeter e spostare il setting di m_gs_dim fuori
        sparsity_pattern gradient_sparsity() const
       {
            auto sp = m_ptr->gradient_sparsity();
            // CHECKS
            return sp;
        }
Francesco Biscani
@bluescarni
May 06 2016 14:49
tutte queste info di sparsity sono qualcosa che si puo' settare all'inizio dell'evolve e poi lasciare cosi' giusto?
Dario Izzo
@darioizzo
May 06 2016 14:50
si
Francesco Biscani
@bluescarni
May 06 2016 14:51
senti magari metto giu' su un gist del pseudo code di come si potrebbe ristrutturare la classe problem con queste cose?
Dario Izzo
@darioizzo
May 06 2016 14:51
ok
ho visto che ha messo appveyor da qualche parte .... ma dove?
nel gitlab-ci.yml non c'e' ne c'e' .appveyor
Francesco Biscani
@bluescarni
May 06 2016 14:52
non c'e' niente ancora per appveyor
ho solo registrato il progetto
Dario Izzo
@darioizzo
May 06 2016 14:52
e perche vedo una build fallita?
Francesco Biscani
@bluescarni
May 06 2016 14:52
perche' appveyor e' coglione
Dario Izzo
@darioizzo
May 06 2016 14:52
:)
Francesco Biscani
@bluescarni
May 06 2016 14:52
tenta di fare la build senza file di configurazione
Dario Izzo
@darioizzo
May 06 2016 15:07
should work
Francesco Biscani
@bluescarni
May 06 2016 15:21
questo ci cambia qualcosa per quanto riguarda i meta problemi? o per il set-seed e balle varie?
Dario Izzo
@darioizzo
May 06 2016 15:21
mi sembra ortogonale .... perche lo chiedi?
Francesco Biscani
@bluescarni
May 06 2016 15:22
non so non si sa mai :)