Por que usamos muito o hex, quando há letras suficientes para usar a base 32? [fechadas]

-1

Você pode ter 0-255 em hexadecimal, armazenado em 2 caracteres, o que comprime os dados e é usado para todos os tipos de coisas, incluindo endereços de cores, IP e MAC.

Minha pergunta é por que eles pararam em 16 bits (ou por que é mais comumente usado)? Há letras suficientes no alfabeto para 32 bits, o que daria um intervalo de 0-65536 contido na mesma quantidade de espaço, potencialmente permitindo 280 trilhões de cores, em oposição a apenas 16 milhões. Se você fizer as maiúsculas e minúsculas e adicionar dois símbolos, poderá ir para 64 bits, permitindo que até 4,3 bilhões de valores sejam representados pelos dois caracteres.


Alguns exemplos de situações que eu acho que isso funcionaria:

O IPv4 está se esgotando. Eu sei que o v6 está sendo lançado, mas é muito longo e difícil de lembrar. Pegue o endereço 192.168.0.1, ele também pode ser armazenado como C0.A8.0.1. Usando hexadecimais de 64 bits, mas ainda mantendo no máximo 8 caracteres, você pode ter 280 trilhões de combinações em vez de 4 bilhões, e não teríamos esse problema.

Como mencionado acima, ele também fornece uma gama muito maior de cores. O formato de foto RAW registra em 32 bits por canal de cor em vez de 8, com o lado negativo de um aumento enorme no tamanho do arquivo. Se os valores RGB foram armazenados como hexadecimais, não deve haver alteração no tamanho do arquivo conforme você aumenta o intervalo de cores, pois ele ainda seria armazenado em 6 bits por pixel, mas com um número base mais alto. Em vez disso, ele é registrado como valores numéricos a 96 bits por pixel, o que é um aumento muito desnecessário de 1600%, deixando as fotos com mais de 20 MB (e de acordo com um video_fps.asp? width = 4096 & height = 2160 & fps = 24 & espaço = rgb444 & profundidade = 32 "> calculadora on-line , o vídeo 4K RAW com 32 bits de cor pode ir até 2,5 GB por segundo).


Esta parte não tem a ver com a questão, mas escrevi um script há algum tempo atrás, que pode converter os números em diferentes valores de base, variando de binário a base 88 (ficou sem símbolos depois disso) , o que mostra que é facilmente possível implementar coisas semelhantes. Como exemplo, aqui está a saída de 66000.
Base 2: 11111111111110000
Base 16: 101D0
Base 32: 20EG - Base 64: G7G
O código é aqui se alguém estiver interessado, ainda tem alguns bugs e eu só tentei de dentro do Maya. Um pouco fora do tópico, mas eu também notei que hex normal parece ser cerca de 20% menos bits que o número original, e a base 88 é quase 50% de redução.


Uma última pergunta: Alguém tentou a minha ideia de armazenar fotos como hexadecimais? Seria potencialmente funcionar se você usou hexadecimal de 64 bits e armazenou as fotos com dados como [64; 1920; Bgh54D; NgDFF4; ...]? Se não, eu posso tentar criar algo que possa fazer isso.

    
por Peter 20.02.2014 / 16:31

3 respostas

9

Se eu estou lendo a pergunta corretamente, você está dizendo que os dados "encolhem" quando você usa bases maiores, quando na verdade isso não acontece.

Veja o seu próprio exemplo: Base 2: 11111111111110000 Base 16: 101D0 Base 32: 20EG Base 64: G7G

Nós usaríamos 101D0 para isso, porque hex é padrão. O que aconteceria se usássemos a notação de base 64?

A resposta é: essencialmente nada, já que você ainda está armazenando e processando os dados em bits no seu dispositivo. Mesmo se você disser que tem G7G em vez de 101D0, você ainda está armazenando e trabalhando com 11111111111110000 no seu dispositivo. Imagine que você tenha o número 5. Se você colocar isso em binário, seria 101. 101 tem 3 dígitos e 5 tem um, e isso não significa que 5 é mais comprimido que 101, já que você ainda estaria armazenando o número como 0101 em seu computador.

Apenas para manter seus exemplos, a coisa do IPv6 ou os endereços MAC (para este exemplo, eles são a mesma coisa, strings de dois dígitos separados por pontos).

Temos, em hexadecimais, 00: 00: FF: 01: 01. É assim que você regularmente expressaria isso. Isso se traduz em binário como 0000 0000 0000 0000 1111 1111 0000 0001 0000 0001 (provavelmente você está começando a entender por que usamos hex agora). Isso é fácil, porque desde 16 = 2 ^ 4, você pode converter um dígito hexadecimal como 4 dígitos binários e apenas colocar o resultado juntos para obter a string binária real. Em seu sistema base 64, se tivéssemos algo como GG: HH: 01: 02: 03, cada letra seria traduzida para 6 bits.

Qual é o problema com isso então? O fato de os computadores trabalharem internamente com poderes de dois. Eles não se importam com a notação que você está usando. Em registradores de CPU, memória e outros dispositivos, você nunca verá dados divididos em grupos de 6 bits.

TL; DR: Hexadecimal é apenas uma notação para nos ajudar humanos a ver coisas binárias mais fáceis, já que um byte pode ser expresso como dois caracteres (0-F), o que é armazenado e processado no computador é o mesmo, não importa a notação você costuma ler.

    
por 20.02.2014 / 16:54
3

Hexadecimal significa literalmente 16.;)

Mas, além da resposta sarcástica, o hexadecimal (ou qualquer outro sistema de numeração de base de potência de 2) é simplesmente um formato mais compacto para representar dados binários. No nível mais baixo, os valores ainda são representados numericamente por bits . No nível mais baixo, esses bits são divididos em partes que a arquitetura de hardware pode manipular facilmente.

Tenha em mente que números hexadecimais não são representados como caracteres 0-9 e a-f - eles são literalmente armazenados como bits. Cada "dígito" não é, como você sugere, codificado como um caractere de 8 bits 0-255, em que apenas os primeiros 16 valores do sistema estão sendo usados.

Vamos comparar as representações da base 2 e da base 64 no seu exemplo.

base2: 11111111111110000 --> 17 "digits" with 1 bit per digit = 17 bits
base64: G7G --> need 3 "digits" with 6 bits per digit = 18 bits

Agora, considere uma codificação base64 em que cada "dígito" é representado por um caractere de 8 bits. Você ainda tem G7G, mas agora cada "dígito" requer 8 bits.

G7G --> 3 "digits" with 8 bits per digit --> 24 bits

Mesmo neste exemplo super simplificado, se você usar a base64 para representar tudo, poderá ter muito mais espaço livre (desperdiçado) do que um sistema de numeração que aloque espaço em partes menores.

Como eu disse, o exemplo anterior é uma simplificação excessiva e assume que você está lidando apenas com números não assinados (ou seja, sem números negativos). Na realidade, os dados serão armazenados em "palavras" cujo tamanho pode variar dependendo da arquitetura do hardware. Se você tiver uma palavra de 8 bits, deverá atribuir valores em blocos de 8 bits, portanto, o valor de 17 bits agora requer 24 bits para armazenar.

Portanto, embora seja trivial usar qualquer sistema de numeração de base de base como você sugere, isso não é comum. Isso pode ocorrer porque as arquiteturas de computadores modernas populares surgiram de arquiteturas de 16 bits em que o hexadecimal era literalmente a linguagem nativa do hardware.

    
por 20.02.2014 / 16:58
2

O Hex parece ser um bom compromisso entre binário e decimal.

  • É fácil converter em binário apenas olhando para ele.

  • Fácil de ler, escrever e se comunicar verbalmente, se necessário. Imagine tentar dizer a alguém uma string codificada em base64 pelo telefone.

  • Computadores de placa única nos anos 70 e 80 costumavam ter LEDs de 7 segmentos e nenhum outro mecanismo de exibição pronto para uso. Felizmente, A, B, C, D, E e F podem ser renderizados em um deles.

É claro que, quando falamos de quantidades de 64 bits, 128 bits e maiores, ou coisas como hashes, não é fácil se comunicar em hexadecimal, decimal ou qualquer outra coisa. Para mim, o "apogeu" do hexadecimal era quando as CPUs de 8 e 16 bits eram comuns, e também quando a programação de baixo nível era mais comum porque era mais necessária. Eu posso estar errado.

Não tenho certeza se o hex é de uso comum, exceto para expressar o endereço de ponteiros em C / C ++. Eu acho que hex é usado fora do hábito ou tradição, aqui, e também veio a ser um sinal de que algo é um valor "binário bruto" e não realmente qualquer "tipo".

Has anyone attempted my idea of storing photos as hex?

Qualquer arquivo, não importa o seu tipo ou conteúdo, é um grande pedaço de bytes. Já está em binário. Hex é apenas uma visão (muito minimamente) favorável ao ser humano disso.

Se você quiser ver os bytes de um arquivo no formato hexadecimal, há uma infinidade de editores hexadecimais e visualizadores que farão isso.

Se você pretende armazenar uma foto como um arquivo de texto contendo uma lista de números hexadecimais, eu acho que você poderia fazer isso se quiser, mas será maior e mais lento para processar do que o arquivo original.

    
por 20.02.2014 / 17:04