Полигон-2

Сопр не умеет считать на 8-ми битах. Равно и на 16, на 32... Заложена в него способность вычислять на 80-ти битах, значит именно так он и будет работать, постоянно, независимо от разрядности входящих данных.
Теоретически, неиспользуемые разряды должны быть обнулены, однако на практике - это не всегда так. Особенно для сопра, разогнанного по частоте. И приведение результата счёта к требуемой разрядности тоже влияет, округлением до N-ного знака.

Поясню: случайная ересь в разрядах с 10-го по 80-й (при вычислениях) легко накрутит значение в 9-м разряде, с некоторым трудом - и в 8-мом. Округление до 8-го разряда дополнительно накрутит 8-й разряд.
Примерно таков механизм ошибок, если отвлечься от битности/разрядности.

i8088 написал:

[q]

FPU просто преобразует любое число в формвт расширенной точности,

[/q]

Вот на этом этапе и происходит дополнение нулями до нужного формата чисел. Токма в разогнанном сопре обнуление не всегда надёжно - появление самопроизвольных бит весьма вероятно, оно и вносит ошибки в вычисления.

Господа, вы уже спориите на абстрактные темы. Вы ушли от фактов и выхватываете верхушки, не анализируя связи.
Я отлаживал программу и столкнулся с погрешностью НА НЕРАЗОГНАННОМ 387SX ULSI. А во-вторых, ваши теории неверны, поскольку при делении погрешность не возникает. В-третьих, абсурдно предполагать, что какие-то биты не обнуляются. 299 раз обнулились, а на 300й нет?
Вот вернется у меня программисткое настроение, тогда проверю на разных процессорах, сопроцессорах и с разными форматами данных. Может, просто в компиляторе ошибка, как много их было в макросах Экселя 6.0

sanders написал:

[q]

Господа, вы уже спориите на абстрактные темы.

[/q]

Согласен, я люблю теорию!
Вполне возможно и ошибка в компиляторе, однозначно можно проверить
написав все на ассемблере. Кстати что за компилятор у Вас? Можно
попробовать откомпилировать другим компилятором или по крайней
мере другой версией компилятора.

С разными версиями компилятора(или компиляторы разных фирм) часто
требуется некоторая коррекция программы, но это решаемо.

Сейчас обратил внимание на Ваш алгоритм

[q]

- цикл от 1 до 255.
а(i):=X_случайное число умножить на Y_случайное число
b(i):=X_случайное число делить на Y_cлучайное число
конец цикла
- цикл от 2 до 255
если a(1)>>a(i) то аварийный останов с выдачей несовпадения a(1) и a(i)
если b(1)>>b(i) то аварийный останов с выдачей несовпадения b(1) и b(i)
конец цикла

[/q]

Те Вы пользуетесь функцией rnd для генерации случайное чисел? Может быть погрешность
возникает просто при некоторых сочетаниях операндов, поэтому и не сразу проявляется?

Проверьте на более современных FPU, там такое наблюдается? Надо поискать errata
документы для старых FPU, какие ошибки были найдены.

Хмм, интересно.
Давайте проверим на более современных CPU со встроенным FPU: 486, Pentium.