C'è un modo per usare le mezze punte?

Come molti sanno qui, usando 4 bit, siamo in grado di contare da 0 a 15 (0123456789ABCDEF in esadecimali). Ma se dovessimo contare solo fino a 9, utilizzeremmo comunque 4 bit e le cifre da A a F verrebbero sprecate.

Tuttavia, la pagina del codice QR di Wikipedia afferma che l'uso di sole cifre numeriche da 0 a 9 utilizza 3 bit per carattere, che è corretto dal punto di vista statistico. Eppure un terzo di un bit non è un oggetto fisico e l'invio di un numero compreso tra 0 e 9 utilizza almeno 4 bit per quanto ne so.

Esiste un modo per utilizzare le combinazioni sprecate per inviare in modo efficace un personaggio con frazioni di bit?

OK, lasciami fare un esempio: le due cifre "27" devono essere inviate. Con le normali tecniche di codifica, i bit inviati sarebbero 00100111. Potremmo quindi immaginare un sistema che sostituisca la cifra '2' con la cifra 'E' o 'F', a seconda del bit successivo; in questo caso il bit successivo è 0, quindi "2" è sostituito da "E". La stringa di bit risultante sarebbe quindi 1101 0 111. D'altra parte, se è necessario inviare le cifre "28", il primo bit dopo "2" è un 1, quindi viene invece sostituito dalla cifra "F", restituendo la stringa 1111 1 000.

In entrambi i casi, è stata effettuata un'economia di 1 bit, poiché un nibble è stato utilizzato per due caratteri diversi. In altre parole, vengono utilizzati tre bit e mezzo su ciascun carattere.

Non è possibile inviare mezzo bit, ma è possibile impacchettare effettivamente due mezze bit in un bit prima della trasmissione o della memorizzazione.

Fai un esempio tu stesso, quindi hai effettivamente risposto alla tua domanda con un SÌ.

Un modo forse un po 'più semplice è quello di codificare semplicemente il valore di due cifre decimali in 7 bit. (Ordinamento del doppio decimale con codice binario).

È possibile utilizzare la codifica huffman in modo che i numeri abbiano una lunghezza in bit variabile. se sei a conoscenza di una cifra che si verificherà più spesso di altre, sarà di aiuto.

esempio (con uguale occorrenza):

0 - 1111

1 - 1110

2 - 110

3 - 101

4 - 100

5 - 011

6 - 010

7 - 001

8 - 000

esempio di ricezione per ottenere il numero 1:

Il primo bit arriva e lascia solo 0 a 4 come opzioni.

arriva il secondo bit e lascia solo 0 a 2 come opzioni.

arriva il terzo bit e lascia da 0 a 1 come opzioni.

arriva il quarto bit e il numero in entrata è 1

Forse quello che stai cercando è la codifica aritmetica, che può codificare in modo efficiente una stringa di simboli, ognuno dei quali in linea di principio potrebbe richiedere un numero frazionario (non intero) di bit. (anche se il messaggio totale deve essere un numero intero di bit)

Citando Wikipedia :

La codifica aritmetica differisce da altre forme di codifica entropica come la codifica di Huffman in quanto piuttosto che separare l'input in simboli componenti e sostituendo ciascuno con un codice, la codifica aritmetica codifica l'intero messaggio in un singolo numero, una frazione n dove (0,0 ≤ n < 1.0).

Il nuovo IEEE P754 per l'aritmetica in virgola mobile ora definisce i formati decimali oltre al binario. Una delle codifiche propone di raggruppare cifre digitali da 3 a 10 bit.

la codifica da 0 a 999 utilizzando 10 bit = 1024 possibili codici è abbastanza efficiente e le cifre decimali sono spesso raggruppate per tre comunque.

Decimale densamente impacchettato : http://en.wikipedia.org/wiki/Densely_packed_decimal

Una corrispondenza 1: 1 di binario (o esadecimale) non è che un simbolo che codifica per i bit. Quindi sì, come hai dimostrato è possibile. Un altro posto in cui questo è usato è (ma leggermente diverso) è nella codifica / decodifica del traliccio nei sistemi di comunicazione in cui le transizioni di bit sono tenute più distanti per facilitare la decodifica. E naturalmente la codifica 8b / 10b e 64b / 66b ecc. Ecc. È un'idea simile, in cui uno spazio simbolico più piccolo è codificato in uno spazio leggermente più ridondante per ottenere i codici di bilanciamento DC, separazione dei simboli e controllo nelle sottobande.

La rappresentazione dei dati dipende dall'interpretazione data da te o dal tuo programma.

Potremmo inviare '27' anche come caratteri ASCII, ad esempio cedendo 0x3237 = 0b0011001000110111.

$x$$n(x)$${\lceil\log_2{n(x)}\rceil}$

$x_1,x_2$$n(x_1),n(x_2)$$\lceil\log_2n(x_1)\rceil+\lceil\log_2n(x_2)\rceil$bit. Tuttavia, se li memorizzi insieme, avrai solo bisogno$\left\lceil\log_2\left(n(x_1)\cdot n(x_2)\right)\right\rceil$ bit.

Nel tuo esempio con l'invio di due cifre, entrambe le cifre possono avere 10 valori diversi. Se le memorizzi separatamente, ti servono$2\cdot\lceil\log_2(10)\rceil=2\cdot4=8$bit. Se li conservi insieme, tuttavia, è necessario$\lceil\log_2(10\cdot10)\rceil=7$ bit.

Dipende sempre dall'applicazione, ma normalmente quando si "uniscono" le variabili come si suggerisce, costerà una maggiore potenza computazionale se si desidera eseguire operazioni su queste variabili. L'aggiunta e la sottrazione di operazioni su variabili "unite" sono più complesse del normale e possono richiedere più spazio nell'hardware o causare ritardi più lunghi.

Nota: $\lceil\dots\rceil$è la notazione per arrotondare .

Il solito modo per impacchettare i valori è moltiplicare ciascun valore con il suo intervallo, quindi si ottiene un numero elevato che è possibile rappresentare in modo efficiente in bit. Quando si disimballa si divide per intervallo, il resto è la cifra e il risultato sono le cifre impacchettate rimanenti.

Se hai 5 valori nell'intervallo da 0 a 2, puoi rappresentarlo in 8 bit (hai bisogno di almeno 7,92 bit per rappresentare i valori) invece dei 10 bit utilizzati dal modo ingenuo di utilizzare 2 bit per ciascun valore, facendo (((n ₁ * 3 + n ₂ ) * 3 + n ₃ ) * 3 + n ₄ ) * 3 + n ₅

In teoria, se sei disposto a spendere spazio nel circuito e potenza per il rivelatore ad alta impedenza, puoi inviare 3 stati lungo un filo digitale (1, 0 e alta Z). Disclaimer: funziona benissimo nel simulatore. Non so se il circuito abbia alcuni problemi che lo rendono poco pratico, come dire che non può davvero passare velocemente come una normale coppia di porte.

Il mio termine normale per una transizione del segnale da alta Z a segnale (in cui il segnale è solitamente macinato in silicio) è un segnale a mezzo bit.

Si desidera inviare una cifra decimale, che richiede 3⅓ bit. Ma dovrai usare 4 bit, perché non puoi inviare un terzo di bit.

Quindi, per scoprire cosa significano veramente i 3⅓ bit, sono necessarie due (o tre) cifre di 3⅓ bit ciascuno. Se si desidera inviare 2 (3) cifre decimali tra 0 e 9, ognuna delle quali richiede poco meno di 3⅓ bit, è possibile farlo utilizzando 7 (10) bit. La prova costruttiva è facile:

7 (10) bit consentono di codificare un numero compreso tra 0 e 128 (1023), ma saranno necessari solo da 00 (000) a 99 (999), che sono tutti possibili codifiche di due (tre) cifre decimali. QED

Penso che tu abbia frainteso cosa si intende nell'articolo wiki collegato. Ciò che si intende è che per una stringa di caratteri che è completamente numerico (senza spazi, virgole o periodi), utilizzando la compressione ideale, è possibile rappresentare ogni carattere con 3 ¹ / ₃ bit in media . In realtà, è un po 'meglio di così, dal momento che la matematica dice che puoi ottenere log ₂ (10) = 3.3219 bit / carattere nel lungo periodo.

Allo stesso modo, per l'insieme di caratteri alfanumerici più alcuni simboli (solo maiuscoli e 9 simboli), o 45 caratteri, è necessario il registro ₂ (45) = 5,4918 bit / carattere, che viene arrotondato per eccesso a 5,5 nell'articolo.

I bit / caratteri ridotti si ottengono utilizzando la compressione, con una codifica preimpostata o uno schema di compressione specificato dallo standard QR (non sono sicuro di quale sia utilizzato). Rappresenta il numero medio di bit di cui un carattere avrà bisogno per essere codificato, quindi un singolo carattere verrà codificato usando più o meno bit. Comprendi anche che i valori sopra elencati sono i valori ideali per stringhe infinite e casuali. È possibile ottenere rapporti di compressione migliori o peggiori per stringhe appositamente predisposte.