Código Natural/Representação interna: mudanças entre as edições
(→Cache-length strategy: add requisitos) |
|||
Linha 49: | Linha 49: | ||
[[Código_natural/Requisitos_e_motivações#Requisitos_na_representação_interna|Requisitos satisfeitos]]: | [[Código_natural/Requisitos_e_motivações#Requisitos_na_representação_interna|Requisitos satisfeitos]]: | ||
:Requisito R1.1: sim, o hInt pode ser "enbutido" em inteiros de qualquer comprimento, e preserva a integridade da ''bitstring'' dentro do inteiro. A performance de ''encode''/''decode'' para ''bitstrings'' também é alta, justamente pelo uso do cache de comprimento. | :Requisito '''R1.1''': sim, o hInt pode ser "enbutido" em inteiros de qualquer comprimento, e preserva a integridade da ''bitstring'' dentro do inteiro. A performance de ''encode''/''decode'' para ''bitstrings'' também é alta, justamente pelo uso do cache de comprimento. | ||
:Requisito R1.2: sim, existe a função ''succ''(''hInt''), podendo ser aplicada a identificadores ou prefixos. | :Requisito '''R1.2''': sim, existe a função ''succ''(''hInt''), podendo ser aplicada a identificadores ou prefixos. | ||
:Requisito '''R1.3''': sim, permite a ordenação lexicográfica com alta performance, e ordenação por nível com acréscimo de apenas uma operação. | |||
:Requisito '''R1.4''': sim, é escalável. Novos sucessores podem ser acrescentados por simples concatenação aos IDs originais. | |||
Exemplificando R1.4. Um código originalmente em hInt16, p. ex. <code>0100.0001100</code> tem como prefixo <code>0100</code> e seu último sucessor é <code>0100.1111111</code>, quando copiado em hInt32 continua sendo o mesmo código, e o sucessor do seu último, <code>0100.11111110</code>, passa a existir, assim como <code>0100.111111100</code> e demais milhares de sucessores dentro do mesmo prefixo. <br/>PS: a eleição de novos IDs não pode usar apenas a função ''succ''(''ID''), deve-se "saltar" os IDs antigos, que estarão intercalados. | |||
===Exemplo mais completo=== | ===Exemplo mais completo=== | ||