Please ignore secret bonuses. Secret tests do NOT award bonus. Max hw grade is 30+2 bonus efficiency

Do you need help?

Idee per velocizzare images.save in HW 6

p
p.carbone (900 points)
3 6 13
in HW6 by (900 points)
Studiando un pochino la libreria png.py ho letto questo:

  ''The array is expected to be a ``numpy`` array, but it can be any
    suitable Python sequence.  For example, a list of lists can be used:
    ``png.from_array([[0, 255, 0], [255, 0, 255]], 'L')``.  The exact
    rules are: ``len(a)`` gives the first dimension, height;
    ``len(a[0])`` gives the second dimension; ``len(a[0][0])`` gives the
    third dimension, unless an exception is raised in which case a
    2-dimensional array is assumed.  It's slightly more complicated than
    that because an iterator of rows can be used, and it all still
    works.  Using an iterator allows data to be streamed efficiently."

Facendo una piccola ricerca su internet ho letto che un Numpy Array facilita operazioni matematiche avanzate e che in genere tali operazioni vengono eseguite in modo più efficiente e con meno codice di quanto sia possibile utilizzando le sequenze integrate di Python.

Essendo scontato il fatto che non possiamo importare librerie al di fuori di images(e quindi anche png), immagino che importare numpy non sia possibile, è possibile ricavarsi una numpy array fai da te da inserire nel save?

Per quanto riguarda questo: "Using an iterator allows data to be streamed efficiently."

Ho già provato a trasformare la lista in iteratore ma mi riporta l'errore Error("len(a) does not work, supply info['height'] instead."). Idee per trasformare in iteratore la lista che facciamo ?
1.3k views
closed

2 Answers

Best answer
S
S3b4stian82 (2250 points)
4 6 27
by (2.3k points)
selected by

Essendo scontato il fatto che non possiamo importare librerie al di fuori di images(e quindi anche png), immagino che importare numpy non sia possibile, è possibile ricavarsi una numpy array fai da te da inserire nel save?

Non puoi importare librerie esterne, ma penso nessuno ti impedisca di incollare dentro program01.py tutto il codice che vuoi.

qui c'e il repo di numpy, divertiti

James_F (6070 points)
10 14 47
by (6.1k points)
il prof ci ha già ammonito una volta sul non farlo!
andrea.sterbini (207920 points)
750 1267 2373
by (208k points)

Ma che bella idea. angry

Metto numpy tra i file di cui esaminare la somiglianza e vi scovo subito

g
g.pascasi (530 points)
2 2 4
by (530 points)
Quindi non è legit modificare la funzione save per ottimizzarla (senza copiare librerie)?
andrea.sterbini (207920 points)
750 1267 2373
by (208k points)

No.......... (tutti gli anni la stessa storia crying)

Andrebbe bene solo se mi passi l'ottimizzazione così aggiorno images in modo che tutti possano usarla.

andrea.sterbini (207920 points)
750 1267 2373
by (208k points)

Ho provato ad usare numpy e PIL per reimplementare le due funzioni save/load per caricare/salvare le immagini e i risultati sono questi:

  • la vecchia load con png.py va circa 9 volte più lenta che con PIL/numpy
  • PIL/numpy va circa 3 volte più lento che con la vecchia save con png.py
Sono 4 righe di codice ma non migliorano i tempi di salvataggio (per ora)
G
Gian-duiotto (630 points)
2 4 8
by (630 points)
Se vuoi ottenere il bonus efficenza e stai cercando una soluzione per velocizzare il programma non considerare images.save come punto di riferimento. Nel senso non c'è bisogno di velocizzarlo :)
p
p.carbone (900 points)
3 6 13
by (900 points)
no in realtà ero il primo fino a ieri per l'efficienza nella leaderboard, il fatto è che una volta ottimizzato il codice iniziale il save va ad occupare il 98/99% del tempo totale, migliorarlo anche solo del 10 % ridurrebbe di un centinaio gli ms, il motivo per cui questo HW sembrerebbe essere molto più tosto per poter prendere i punti bonus è perche essendoci questo save che occupa in maniera fissa dai 2200 ai 2300 ms, la differenza che si viene a creare tra un programma efficiente e uno mediocre si riduce di molto. Facendo un esempio: un programma efficiente senza il metodo save permette di far ottenere in media per ogni test tra i 5ms e i 16ms(per quelli più pesanti), uno meno efficiente tra i 50 ms e i 100 o più(per i più pesanti) , ebbene sommando questi risultati ai 2300 fissi iniziali si ottiene: 2400 circa per un programma efficiente e 2 600 circa fino a un massimo di 3000 per i peggiori, una differenza veramente piccola considerando il fatto che i risultati variano sempre di un centinaio di ms casualmente, (rinviando il mio test sono passato da 2398 a 2470 senza alcuna modifica).
g
giac (2790 points)
10 14 27
by (2.8k points)
vabbe ma non è comunque una gara a chi è primo; se stai sotto i 2550 non rischi di perdere il bonus efficienza.

il margine casuale di caricamento riguarda tutti e se comunque il programma è scritto semibene la VM comunque non può impazzire, parliamo di differenze millesimali.

tanto più che alla fine i bonus si faranno sulle tempistiche del test integrato coi test segreti, quindi la classifica attuale è un'approssimazione, una proiezione, diciamo un exit poll.
p
p.carbone (900 points)
3 6 13
by (900 points)
edited by
Infatti non si tratta di gara, si tratta di capire, la leaderboard incita anche a questo, a dare di più, e ti assicuro che dando di più si impara tantissimo, a mio parere anche di più di chi punta semplicemente al 30.

Si è un approssimazione dove però si basano i punti bonus di esame che ti ricordo vanno a quelli che stanno 1/2 più in cima, non è un discorso totalmente banale diciamo...

Ah come se non bastasse, stesso codice mi ha tolto 2 punti bonus adesso ahah, da 2400 a 2600, 0 modifiche, il problema è molto più serio.
Fulminetor5000 (400 points)
1 2 5
by (400 points)
edited by
Non ha senso, visto che per tutti gli esercizi riusciti images.save() ci mette gli stessi millisecondi, la differenza tra un buon codice e un codice mediocre rimane la stessa.

|(es1 + x) - (es2 + x)| = |es1 - es2| = differenza di tempo tra due codici.

La questione della vm, che non è molto precisa e che anche ricaricando lo stesso file si possono avere tempi diversi, è un altro discorso.
p
p.carbone (900 points)
3 6 13
by (900 points)
no... non ci mette gli stessi millesecondi... il tempo varia oscilla tra + o - 100 ms, in un esercizio del genere in cui l'ordine di grandezza tra un compito efficiente e uno mediocre si aggira sui decimi di ms succede che per sola fortuna o meno può capitare che un programma meno efficiente superi quello più efficiente
Fulminetor5000 (400 points)
1 2 5
by (400 points)
Come fai a dire che sia save() ad alterare il risultato di un codice? Hai qualche elemento da cui possiamo dedurre che la maggior parte delle oscillazioni della vm sia dovuta a save()?

In caso contrario, dobbiamo considerare che tutto il codice ha la stessa probabilità di subire oscillazioni di tempo;
Quindi, anche fosse save() di 0 ms, i tempi finali dei codici sarebbero minori ma avrebbero in proporzione le stesse oscillazioni.

Se conosci un modo più preciso per calcolare il tempo di un codice (e che ad esempio, anche ricaricandolo più volte, calcoli sempre gli stessi ms),
dovresti aprire un thread e suggerire di adottarlo per la vm, così da rendere più precise le classifiche.
p
p.carbone (900 points)
3 6 13
by (900 points)
edited by
L'elemento per verificare questo sono il profilier, puoi farlo tu stesso, se non ti convince la cosa prova a far girare il tuo programma commentando images.save e guarda le differenze. Con un minimo di affinità è possibile anche tirar fuori le percentuali di differenza tra una funzione, un metodo o una quasliasi altra operazione col tuo programma, facendo cosi ho ottenuto che save mi occupa circa il 96.580988445 % del tempo totale per i test più pesanti, ancora di più se aumento la complessità da 3 a 5 per esempio: 98% e così via.

solo save varia sempre di 100- 200 ms e anche di più per ogni prova(pesante tipo mat 16-25) che giri (controllalo tu stesso sul profilier), tutte le altre cambiano anch'esse (rapportate) più o meno alla stessa maniera ma essendo di ordini di grandezze più piccole le loro differenze sono trascurabili
Fulminetor5000 (400 points)
1 2 5
by (400 points)
Avevo già fatto alcuni test prima di risponderti oggi pomeriggio utilizzando il file dei test del prof, facendo alcune esecuzioni e la loro media, altre esecuzioni e la loro media, tendenzialmente si ha un risultato simile;
Se si fa la stessa cosa ma stressando il pc solo per un gruppo di esecuzioni, c'è uno sfasamento rilevante.
La stessa cosa succede anche togliendo la funzione save().

Il problema è come viene calcolato il tempo e la vm, non la funzione save (che a prescindere, per quanto si possa ottimizzare, dubito possa diventare anche solo il doppio più veloce).
p
p.carbone (900 points)
3 6 13
by (900 points)

controlla il primo della leaderboard..., il suo codice è poco efficiente e impiega 200 ms quando il mio ne impiega 30 su mat-16-25, il trucchetto che ha usato è stato quello di ridurre il save andando a inserire (invece che tuple contenenti i 3 colori rgb) direttamente tuple unite insieme con tutti i colori dentro..., ho modificato il mio riducendo il save a mia volta ed ora è molto più veloce, incredibile che ancora non si è capito questo concetto, non è la VM il problema, il tempo che impiega  (il margine di imprecisione) è costante in base al tempo complessivo dell'esercizio, è ovvio quindi che se metti un save che impiega il 90% del tempo il margine si ingrandisce andando a sovrastare e mascherare l'efficienza di un esercizio che è 1 ordine (quasi 2) di grandezza più piccolo, ora che hai modo di vederlo controlla i codici e magari capisci che intendo. Mi dispiace solo che non ha scritto qui sotto il metodo per migliorare il save visto che sto post l'anno letto in 400 e quindi probabilmente anche lui.(chissà se ha preso spunto proprio da questo). Morale della favola save si poteva migliorare, ed è stato fatto, ovviamente di nascostofrown, e ovviamente è stato l'elemento più importante per migliorare l'efficienza... 

Fulminetor5000 (400 points)
1 2 5
by (400 points)
Come precedentemente argomentato, migliorando la conta del tempo sulla vm o cambiando metodo di conteggio della velocità, non si hanno problemi a calcolare in modo corretto i tempi con il save originale.

Nel caso specifico che hai detto tu, la funzione save non mi sembra sia stata modificata, quindi ad occhio, è lecito farlo ed è anche un'ottima intuizione.

Detto questo, per valutare la bravura in una sfida bisogna rispettare delle precise condizioni, cambiando le condizioni cambia la sfida.

Se vuoi dimostrare chi corre più veloce, i 100 metri vanno fatti a piedi;
Se vuoi dimostrare chi arriva prima, i 100 metri puoi farli come vuoi.

Se la funzione save non va modificata e lo fai lo stesso,
non "vince" l'algoritmo che ha creato più velocemente l'immagine utilizzando la funzione save (cioè lo scopo dell'esercizio), ma quello che ha generato più velocemente l'immagine.

Praticamente è come aver svolto un altro esercizio.

Visto che in questa leaderboard vince la prima metà, fare punteggi particolarmente buoni è solo soddisfazione personale (io nemmeno sono iscritto al corso, li faccio solo per questo);
Non so quanta soddisfazione personale si possa avere barando.
andrea.sterbini (207920 points)
750 1267 2373
by (208k points)
Grazie per le info.

Scopo dell'esercizio non è ottimizzare il salvataggio.

Mi sa che qualcuno fallirà i test segreti
andrea.sterbini (207920 points)
750 1267 2373
by (208k points)
edited by

Vedete, secondo me vincere sporco non è rispettoso dei colleghi.
Se vedete spazio per migliorare il macchinario io sono ben felice di accettare i vostri suggerimenti.
Se aveste detto in tempo che c'è un modo di rendere più veloce caricamento e/o salvataggio delle immagini (come avevo chiesto qualche post fa) tutti ne avrebbero tratto giovamento.

Ora siamo dopo la scadenza ed il codice consegnato è quello che è, per cui qualcuno dovrà rifare lo HW6 (che per voi bravi è una passeggiata).

Per dimostrare che vi ascolto apro una Categoria BUG BOUNTY / IMPROVEMENTS in cui potete suggerire miglioramenti dei test e delle librerie usate (potrei benissimo passare ad usare PIL e numpy l'anno prossimo, ad esempio). Tutti i miglioramenti che verranno accolti verranno premiati.

iacopomasi (5230 points)
45 64 94
by (5.2k points)

Si fra l'altro nella mie lezione ho sottolineato di NON modificare i moduli di base per velocizzare l'esercizio, perchè sentivo parlare di modifiche durante la lezione.
Va bene apportare modifiche ai moduli di base ma "fuori" dall' HW nel thread specificato dal Prof. Sterbini.