Shift bitwise e o maior inteiro no Bash

15

Esta é uma questão de exploração, o que significa que não estou completamente certo sobre o que é essa questão, mas acho que é sobre o maior número inteiro no Bash. De qualquer forma, vou defini-lo ostensivamente.

$ echo $((1<<8))
256

Estou produzindo um número inteiro mudando um pouco. Até onde posso ir?

$ echo $((1<<80000))
1

Não até agora, aparentemente. (1 é inesperado, e eu voltarei a ele.) Mas,

$ echo $((1<<1022))
4611686018427387904

ainda é positivo. Não isso, no entanto:

$ echo $((1<<1023))
-9223372036854775808

E um passo além,

$ echo $((1<<1024))
1

Por que 1? E por que o seguinte?

$ echo $((1<<1025))
2
$ echo $((1<<1026))
4

Alguém gostaria de analisar esta série?

ATUALIZAÇÃO

Minha máquina:

$ uname -a
Linux tomas-Latitude-E4200 4.4.0-47-generic #68-Ubuntu SMP Wed Oct 26 19:39:52 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
    
por Tomasz 22.11.2016 / 17:33

4 respostas

24

Bash usa intmax_t variáveis para aritmética . No seu sistema, eles têm 64 bits de comprimento, então:

$ echo $((1<<62))
4611686018427387904

que é

100000000000000000000000000000000000000000000000000000000000000

em binário (1 seguido por 62 0s). Mude de novo:

$ echo $((1<<63))
-9223372036854775808

que é

1000000000000000000000000000000000000000000000000000000000000000

em binário (63 0s), em aritmética de complemento de dois.

Para obter o maior número inteiro representável, você precisa subtrair 1:

$ echo $(((1<<63)-1))
9223372036854775807

que é

111111111111111111111111111111111111111111111111111111111111111

em binário.

Como apontado em / a / 325431/86440 "> answer , o deslocamento leva o módulo de deslocamento 64 em CPUs de 64 bits x86 (usando RCL ou SHL ), o que explica o comportamento que você está vendo:

$ echo $((1<<64))
1

é equivalente a $((1<<0)) . Assim, $((1<<1025)) é $((1<<1)) , $((1<<1026)) é $((1<<2)) ...

Você encontrará as definições de tipo e os valores máximos em stdint.h ; no seu sistema:

/* Largest integral types.  */
#if __WORDSIZE == 64
typedef long int                intmax_t;
typedef unsigned long int       uintmax_t;
#else
__extension__
typedef long long int           intmax_t;
__extension__
typedef unsigned long long int  uintmax_t;
#endif

/* Minimum for largest signed integral type.  */
# define INTMAX_MIN             (-__INT64_C(9223372036854775807)-1)
/* Maximum for largest signed integral type.  */
# define INTMAX_MAX             (__INT64_C(9223372036854775807))
    
por 22.11.2016 / 18:09
4

Do arquivo CHANGES para bash 2.05b:

j. The shell now performs arithmetic in the largest integer size the machine supports (intmax_t), instead of long.

Em x86_64 máquinas intmax_t corresponde a inteiros assinados de 64 bits. Então você obtém valores significativos entre -2^63 e 2^63-1 . Fora dessa faixa, você acaba de se envolver.

    
por 22.11.2016 / 18:12
4

O deslocamento de 1024 gera um, porque a quantidade de deslocamento é efetivamente medida pelo número de bits (64), portanto, 1024 === 64 === 0 e 1025 === 65 === 1 .

Mudar algo diferente de 1 deixa claro que não é um pouco de rotação, já que os bits mais altos não ficam no limite mínimo antes que o valor do deslocamento seja (pelo menos) 64:

$ printf "%x\n" $(( 5 << 63 )) $(( 5 << 64 ))
8000000000000000
5

Pode ser que esse comportamento dependa do sistema. O código bash que Stephen associou mostra apenas uma mudança clara, sem qualquer verificando o valor da mão direita. Se bem me lembro, os processadores x86 usam apenas os seis bits inferiores do valor de deslocamento (no modo de 64 bits), portanto, o comportamento pode ser diretamente da linguagem de máquina. Além disso, acho que mudanças em mais do que a largura de bits não estão claramente definidas em C ( gcc avisa para isso).

    
por 23.11.2016 / 14:06
2

producing an integer by shifting a bit. How far can I go?

Até que a representação de número inteiro seja envolvida (o padrão na maioria dos shells). Um inteiro de 64 bits geralmente envolve 2**63 - 1 .
Isso é 0x7fffffffffffffff ou 9223372036854775807 no dec.

Esse número "+1" se torna negativo.

Isso é o mesmo que 1<<63 , assim:

$ echo "$((1<<62)) $((1<<63)) and $((1<<64))"
4611686018427387904 -9223372036854775808 and 1

Depois disso, o processo é repetido novamente.

$((1<<80000)) $((1<<1022)) $((1<<1023)) $((1<<1024)) $((1<<1025)) $((1<<1026))

O resultado depende do mod 64 do valor de deslocamento [a] .

[a] De: A contagem é mascarada para 5 bits (ou 6 bits se em 64- modo de bit e REX.W é usado). O intervalo de contagem é limitado a 0 a 31 (ou 63, se o modo de 64 bits e o REX.W forem usados). .

Além disso, lembre-se de que $((1<<0)) é 1

$ for i in 80000 1022 1023 1024 1025 1026; do echo "$((i%64)) $((1<<i))"; done
 0 1
62 4611686018427387904
63 -9223372036854775808
 0 1
 1 2
 2 4

Então, tudo depende de quão perto está o número para um múltiplo de 64.

Testando o limite:

A maneira robusta de testar qual é o número inteiro positivo máximo (e negativo) é testar cada bit um por vez. Em menos de 64 passos para a maioria dos computadores, não será muito lento.

bash

Primeiro, precisamos do maior inteiro do formulário 2^n (conjunto de 1 bit seguido de zeros). Podemos fazer isso mudando para a esquerda até o próximo turno tornar o número negativo, também chamado de "contorno":

a=1;   while ((a>0));  do ((b=a,a<<=1))  ; done

Onde b é o resultado: o valor antes do último turno que falha no loop.

Em seguida, precisamos tentar cada detalhe para descobrir quais afetam o sinal de e :

c=$b;d=$b;
while ((c>>=1)); do
      ((e=d+c))
      (( e>0 )) && ((d=e))
done;
intmax=$d

O inteiro máximo ( intmax ) resulta do último valor de d .

No lado negativo (menos de 0 ), repetimos todos os testes, mas testamos quando um bit poderia ser feito 0 sem envolver.

Um teste completo com impressão de todos os passos é este (para bash):

#!/bin/bash
sayit(){ printf '%020d 0x%016x\n' "$1"{,}; }
a=1;       while ((a>0)) ; do((b=a,a<<=1))              ; sayit "$a"; done
c=$b;d=$b; while((c>>=1)); do((e=d+c));((e>0))&&((d=e)) ; sayit "$d"; done;
intmax=$d
a=-1;      while ((a<0)) ; do((b=a,a<<=1))              ; sayit "$b"; done;
c=$b;d=$b; while ((c<-1)); do((c>>=1,e=d+c));((e<0))&&((d=e)); sayit "$d"; done
intmin=$d       

printf '%20d max positive value 0x%016x\n' "$intmax" "$intmax"
printf '%20d min negative value 0x%016x\n' "$intmin" "$intmin"

sh

Traduzido para praticamente qualquer shell:

#!/bin/sh
printing=false
sayit(){ "$printing" && printf '%020d 0x%016x\n' "$1" "$1"; }
a=1;       while [ "$a" -gt 0  ];do b=$a;a=$((a<<1)); sayit "$a"; done
c=$b;d=$b; while c=$((c>>1)); [ "$c" -gt 0 ];do e=$((d+c)); [ "$e" -gt 0 ] && d=$e ; sayit "$d"; done;
intmax=$d
a=-1;      while [ "$a" -lt 0  ];do b=$a;a=$((a<<1)); sayit "$b"; done;
c=$b;d=$b; while [ "$c" -lt -1 ];do c=$((c>>1));e=$((d+c));[ "$e" -lt 0 ] && d=$e ; sayit "$d"; done
intmin=$d       

printf '%20d max positive value 0x%016x\n' "$intmax" "$intmax"
printf '%20d min negative value 0x%016x\n' "$intmin" "$intmin"

Executando o acima para muitos shells,
todos (exceto bash 2.04 e mksh) aceitaram valores até ( 2**63 -1 ) neste computador.

É interessante informar que o shell do att :

$ attsh --version
version         sh (AT&T Research) 93u+ 2012-08-01

imprimiu um erro nos valores de $((2^63)) , mas não no ksh.

    
por 26.11.2016 / 13:24