Я спросил вопрос ранее, который включал вытягивание больших простых чисел из текстового файла и помещение их в другой файл. Предполагалось, что каждый пробег до и включительно первого числа после 2 ^ 32, и по какой-то причине этот script перестает работать.
#!/bin/bash
n=4294967296
last=0
while read number
do
if [ $last -gt $n ]
then break
fi
echo $number
last=$number
done < primes.txt > primes2.txt
Это закончилось тем, что пронеслось через эти 11 чисел:
4232004449
4232004479
4232004493
4232004509
4232004527
4232004533
4232004559
4232004589
4232004593
4232004613
004437
В исходном файле не было 004437, а мой bash будет обрабатывать числа над 8999999999999999999
Кто-нибудь знает, почему это произошло?
64-разрядная Ubuntu 10.04, 16 ГБ ОЗУ, 8 ядер = 3,60 ГГц
GNU bash, версия 4.1.5 (1) -release (x86_64-pc-linux-gnu)
Update:
После загрузки и компиляции "фиксированного" bash, предоставленного jfgagne и связанного с ним в моем bash script, он был ошибочен в одном и том же месте. Используя значительно более быстрый perl-эквивалент из моего первоначального основного вопроса, я получил некоторые размеры файлов от ls -al:
11 next_prime (just to make sure this was counting bytes accurately)
2147483659 primes2.txt
2147483670 one_too_many
2147483659 = 2 ^ 31 + 11
Размер следующего простого (4232004631) равен 11 байтам
Это содержит все простые числа до 4232004613. Я также понял, что 004437 происходит от конца штриха в нижней части этого цикла ошибки (4232004437). Кажется, что-то пытается продвинуться, но застряло.
Нет, он не зависит от битрейта вашей ОС. Это зависит от простой декларации в глубине источников bash.
Это объявление __int64_t с 2002 года. С тех пор bash versions >= 3.00 всегда используют 64-битные целочисленные переменные, и это не зависит от архитектуры! Это зависит только от версии bash.
Предыдущие версии bash всегда использовали 32-битное целое число, даже на 64-битной ОС.