Flick, la nuova unità di tempo inventata da Facebook

[Redazione di Hardware Upg]

Link alla notizia: https://www.hwupgrade.it/news/web/fl...ook_73701.html

E' pari a 1,41723356 nanosecondi e servirà per misurare la durata dei singoli frame nei video, e verificare la sincronia usando numeri interi. L'idea è stata avanzata già lo scorso anno

Click sul link per visualizzare la notizia.

[Cappej]

Grazie! ne avevamo davvero bisogno!

Oggi il mondo luogo migliore.

"Ma quello che sappiamo per certo è che un bel giorno, all'inizio del Ventunesimo secolo, l'umanità intera si ritrovò unita all'insegna dei festeggiamenti. Grande fu la meraviglia per la nostra magnificenza mentre davamo alla luce ... FLICK " [CIT. Matrix]



P.s. vediamo se qualcuno dei NS politici lo inserirà nella propria campagna elettorale! Dopo il reddito di cittadinanza, la flex tax, l'esenzione delle tasse da prima casa e prima auto... "PIU' FLICKs per tutti" ! !!!!

[jepessen]

Evidentemente chi fa dell'ironia non ha capito il concetto...

Non si vuole creare orologi in piazza basati sui flick... Si tratta semplicemente di una unita' di misura che permette di rappresentare intevalli di tempo all'interno di un computer utilizzando numeri interi invece che in virgola mobile. In questo modo e' possibile effettuare operazioni temporali sui frame basandosi su una aritmetica intera, che e' piu' accurata e piu' veloce rispetto a quella eseguita sui float o sui double, permettendo cosi' di effettuare elaborazioni video piu' velocemente e con minori artefatti dovuti ad approssimazioni numeriche. Il valore e' stato scelto per poter lavorare con le varie lunghezze di frame dei diversi standard...

Si tratta quindi di una convenzione utile ai programmatori, non ci vedo nulla di strano... Danno notizia e codice in maniera tale che la nuova unita' di misura sia piu' conosciuta possibile, e di conseguenza anche piu' adottata...

[PHØΞИIX]

Una cosa non mi è chiara. Perchè l'utilizzo del flick come unità di misura permetterebbe un calcolo utilizzando numeri interi, mentre l'utilizzo del nanosecondo no?

[Nui_Mg]

Originariamente inviato da Cappej

P.s. vediamo se qualcuno dei NS politici lo inserirà nella propria campagna elettorale! Dopo il reddito di cittadinanza, la flex tax, l'esenzione delle tasse da prima casa e prima auto... "PIU' FLICKs per tutti" ! !!!!

Ti sei dimenticato Grasso e la sua abolizione delle tasse universitarie.

Inoltre, la tassa sulla prima casa è tipica di un paese incivile, solo l'ignoranza grassa di tantissimi italiani la ritiene una cosa normale: infatti oltre-alpi o non esiste in alcuna forma, oppure esiste ma è annualmente risibile e fortemente rapportata al reddito di chi la abita (io lo so perché ho una casa di proprietà in Italia e un bilocale a Monaco).
Per esempio, un pensionato con pensione anche media che abita la casa di proprietà, non può e non deve pagare assolutamente niente.
Tralasciando il personaggio e i suoi enormi difetti, Berlusconi aveva fatto bene ad abolirla, anche se va detto che ancor prima di "Frodo" la prima abolizione su scala nazionale è stata a carico di un comune a guida leghista.

[Personaggio]

Originariamente inviato da PHØΞИIX

Una cosa non mi è chiara. Perchè l'utilizzo del flick come unità di misura permetterebbe un calcolo utilizzando numeri interi, mentre l'utilizzo del nanosecondo no?

Se misuri la durata dei frame nei casi in qui la freq sia: 24hz, 25hz, 30hz, 48hz, 50hz, 60hz, 90hz, 100hz o 120hz, avrai dei multipli di 1,41723356 ns se questa cifra la fai uguale a 1fl, per fare calcoli userai numeri interi e non multipli di 1,41723356

[Cappej]

Originariamente inviato da jepessen

Evidentemente chi fa dell'ironia non ha capito il concetto...

Non si vuole creare orologi in piazza basati sui flick... Si tratta semplicemente di una unita' di misura che permette di rappresentare intevalli di tempo all'interno di un computer utilizzando numeri interi invece che in virgola mobile. In questo modo e' possibile effettuare operazioni temporali sui frame basandosi su una aritmetica intera, che e' piu' accurata e piu' veloce rispetto a quella eseguita sui float o sui double, permettendo cosi' di effettuare elaborazioni video piu' velocemente e con minori artefatti dovuti ad approssimazioni numeriche. Il valore e' stato scelto per poter lavorare con le varie lunghezze di frame dei diversi standard...

Si tratta quindi di una convenzione utile ai programmatori, non ci vedo nulla di strano... Danno notizia e codice in maniera tale che la nuova unita' di misura sia piu' conosciuta possibile, e di conseguenza anche piu' adottata...

Diciamo che per me è un po' come se fosse antani e parasblinda, quindi sì ti confermo che il concetto non mi era chiaro per niente, quello che mi chiedevo era se vi è veramente necessità dell'ennesima unità di misura? A quanto ho capito si... quindi avremo i deci-flick... i k-flick... i mega-flick... spero non i nano-flick!

[DarthWiz]

L'idea alla base di questa unità di misura è proprio quella di non avere mai bisogno di frazioni. Quindi kiloflick e megaflick sì, ma deciflick no.

[palarran]

Effettivamente non è male, rimane qualche virgolina ma poca roba.. si parla di roba dopo 2 o 3 zeri, quindi millesimi di nanosecondo..

Però non torna per nulla se si usa 23,976 e 29,97 fps..

[Zenida]

Io la trovo invece una buona notizia (nonostante l'ideatore non mi vada particolarmente a genio), alla fine si tratta di risolvere il problema nato con gli Hertz, ovvero la frequenza di aggiornamento, che la natura ha stabilito non coincidesse con i nostri interi di nanosecondi.

Quindi assecondiamo la natura e creiamo il flick che può descrivere gli Hertz interamente.

Il tutto chiaramente porterà a creare una libreria apposita che i programmatori potranno richiamare alla bisogna, invece di ammazzarsi con le frazioni

[fano]

Originariamente inviato da palarran

Effettivamente non è male, rimane qualche virgolina ma poca roba.. si parla di roba dopo 2 o 3 zeri, quindi millesimi di nanosecondo..

Però non torna per nulla se si usa 23,976 e 29,97 fps..

Spero che questi kludge dell'NTSC vadano a morire con le produzioni native digitali... non ha proprio più senso!

[squalho]

Originariamente inviato da Zenida

Io la trovo invece una buona notizia (nonostante l'ideatore non mi vada particolarmente a genio), alla fine si tratta di risolvere il problema nato con gli Hertz, ovvero la frequenza di aggiornamento, che la natura ha stabilito non coincidesse con i nostri interi di nanosecondi.

Quindi assecondiamo la natura e creiamo il flick che può descrivere gli Hertz interamente.

Il tutto chiaramente porterà a creare una libreria apposita che i programmatori potranno richiamare alla bisogna, invece di ammazzarsi con le frazioni

Gli Hertz non c'entrano niente. 1 Hz = 1/1s per cui gli Hertz si accoppiano benissimo con i secondi. Un intervallo i 1ns corrisponde esattamente a 1GHz. Quello che invece c'entra e` il numero di frame per secondo, quello si` che e` arbitrario e non corrisponde a numeri sensati.

[squalho]

Giusto per spiegare un po' meglio come si arriva a quel numero. Il problema e` trovare il minimo comune multiplo per le durate dei frame rate piu` comuni. Siccome la durata di un frame e` uguale a 1/frame_rate, si cerca il minimo comune multiplo tra i frame rate. Facebook ha considerato i seguenti rate:
8, 16, 22.05, 24, 25, 30, 32, 44.1, 48, 50, 60, 90, 100, 120 fps.

Il minimo comune multiplo di quei numeri tecnicamente non si puo` fare perche` ha senso farlo solo con numeri interi. La cosa si risolve facilmente moltiplicando per 100:
800, 1600, 2205, 2400, 2500, 3000, 3200, 4410, 4800, 5000, 6000, 9000, 10000, 12000

Il MCM tra quei numeri e` esattamente 35.280.000. Moltiplicando per 2 (probabilmente per la questione 3D/VR) si ottiene 70.560.000. Non mi e` del tutto chiaro perche` poi Facebook abbia ancora moltiplicato per 10, ottenendo 705.600.000. Forse per rendere l'unita` di misura piu` simile a 1 nanosecondo. Si capisce l'utilita` del Flick andando a vedere la durata dei frame per la lista di sopra, misurata in secondi e in Flick:

In secondi (troncati a 15 cifre decimali):
0.125000000000000
0.062500000000000
0.045351473922902
0.041666666666667
0.040000000000000
0.033333333333333
0.031250000000000
0.022675736961451
0.020833333333333
0.020000000000000
0.016666666666667
0.011111111111111
0.010000000000000
0.008333333333333

In Flick (nessun bisogno di troncare):
88200000
44100000
32000000
29400000
28224000
23520000
22050000
16000000
14700000
14112000
11760000
7840000
7056000
5880000

Notare che non e` solo una questione di comodita`, ma anche di precisione. Ad esempio la durata di un frame a 24 fps non e` rappresentabile con un numero finito di cifre se espressa in secondi. Stesso discorso per tanti altri rate, com si vede sopra.

Non sono del tutto sicuro perche` quelli sono stati i frame rate considerati. La TV NTSC a colori va a 29.97 fps per cui un frame a colori NTSC non e` rappresentabile in numero intero usando i Flick.