Тест либы

[Utkin]

Написал пару модулей для работы с длинной арифметикой - четырые операции + пару вспомогательных. Требуется тестирование, так как работа там хитрая и возможны скрытые баги.
- арифметика произвольной точности (число разрядов в числах зависит только от размера доступной памяти);
- все числа являются вещественными (то есть с дробной частью);
- импорт и экспорт в строки;
- классическое умножение и деление в столбик;
- для работы используются и не математические операции (игра с разрядами и т.д.);
- все функции документированы комментариями в исходных текстах;
- работа реализована в "старом" стиле, то есть без ООП - поэтому существует возможность переноса на различные Паскали.
По мотивам данной либы будет статья в журнал о том, как самому писать длинную арифметику под себя.

[Alex Cones]

(не рекомендуются для самостоятельного использования)

В чем тогда смысл помещать их в interface?

P.S. Вы бы хоть txt дали, с чего начать, поскольку там присутствуют функи типа Init

[Utkin]

Там есть тестовый пример деления для образца при создании формы. Показывается как вводить числа, делить и выводить числа. Все просто .

В чем тогда смысл помещать их в interface?

Предполагаю дальнейшее развитие. Данные функции могут быть полезны в случае, если Вы разберетесь в либе...

Новая версия, исправил баг в операции деления - проглатывал нули в середине числа .

[Alex Cones]

Нашел одну не то, чтобы багу.

При делении некоторых чисел друг на друга (Например 10 и 6) получается бесконечная периодическая дробь с шагом 1 и добавочным остатком:
1.666666666666666666667 ( 1.(6)7 ). Остаток библиотека не обрабатывает. Выводит 1.666666666666666666666. В чем соль фичи? Иногда при округлении используется этот остаток -
1.444444444444444444445 => 1.44444445 => 1.45 => 1.5
__________________________
При попытке деления 0 на 1 (0/1) зависает намертво.
__________________________
аналогично при делении 1/0. Ни ошибки, ничего. Зависание.

P.S. Если хотите проверить точность - вычисляйте Пи:


Все^W Большинство^W Часть цифр после запятой известна, поэтому можно проверять хоть до миллионного знака.

[Utkin]

Округления не реализовано . Но легко сделать самому. Смысл - при делении указываете операнды, количество разрядов в дробной части и куда пихать результат. Дело в том, что деление это единственная операция, которая может порождать бесконечное число разрядов. Вы просто указываете до каких пор продолжать деление. Меня интересовал собственно длинный результат - упор при разработке операции деления делался на точность данных. Это полезно например при астрономических расчетах.
Далее вопрос номер два - как округлять - в какую сторону - включать ли 5? Или считать ее отдельно?
Далее, 1,666 это конечно 1,67. Но как быть с 1,333? Это же не 1,34, но и не 1,33...

Насчет нулей щас решим .
Кстати, либа задмывалась, так что разделителем целой и дробной части может быть и точка и запятая.
Перевод числа из строки - функция, обратите на это внимание.


-----ДОБАВЛЕНО---------------
О нулях .
Ладно нуль мы поделим, как быть с делением на нуль?
Есть варианты:
1. Возвращать нуль (или не нуль - просто какое-либо число).
2. Генерировать ошибку

Лично я против второго варианта

----ДОБАВЛЕНО----------------

P.S. Если хотите проверить точность - вычисляйте Пи:

Да я знаю, что результат точен . Зачем мне его вычислять. Дело в том, что деление вычисляет результат точно, а не как принято при стандартном делении. Вы указываете до какого разряда делить... А текущая ситуация с округлением частично связана с тем, что используется арифметика плавающая - когда в недрах процессора разные, но близкие числа могут считаться и равными и различными. Здесь никаких двойных стандартов - если числа отличаются знаками и/или разрядами, то они не эквиваленты. Исключение допускается только для незначащих нулей.

----ДОБАВЛЕНО---------------

Решил баг с нулями. Деление на нуль пока выдает 0. Что предложите вместо?

от Sibedir
А с quan что? Поясни плиз.

Был косяк, возникает когда число надо домножать (то есть когда число которое нужно поделить меньше числа на которое нужно поделить ). Исправил, вот новая версия (пока тоже содержит ошибки)

Новая версия (специально не стал перезаливать, чтобы была возможность сравнить тексты) - опять проблема с результатом от деления - он отличался на 10^n. Теперь это исправлено.

[Sibedir]

    GetBigNum('9', y);
    GetBigNum('1', x);
    DivBigNumR(y, x, 8, f);

Зациклился.

    GetBigNum('9', y);
    GetBigNum('1.01', x);

Выдал +8.91908888
А надо +8.91089109
Вообще при делении чуть реже чем всегда ошибается
9854.654 / 2445.126 = +4.33256324 (+4.03032564)

[Utkin]

Ладно, проведу детальный разбор алгоритма и выложу новую версию . Все дело в волшебных нулях .

Пофикисл деление, вышеуказанные примеры работают как положено (вроде )

DivBigNumE - деление (на нуль с исключением)
DivBigNumN - деление (на нуль с очень большим числом)

[JTG]

Ну, есть куда расти.

uses Classes, SysUtils, BigNum, ByteSpace;

var x, y, z: TBigNum;
    s: string;
    st: TMemoryStream;
begin
    GetBigNum('2', y);
    GetBigNum('7', x);
    DivBigNum(y, x, 1000000, z);

  { s:=PutBigNum(z);
    With TMemoryStream.Create do
    begin
      Write(PChar(s)^, Length(s));
      SaveToFile('out.txt');
      Free;
   end;}
end.

Если раскомментить, в файл записывается 500003 байт, перл честно выдал 1000003

[Utkin]

JTG, помедленей, я записываю .
То есть косяк в том, что для больших результатов считает только половину заявленного?

[JTG]

Да, это с модулями из первого поста. Из №7 вообще не работает

    GetBigNum('2', y);
    GetBigNum('7', x);
    DivBigNumN(y, x, z, 100000);
    PutBigNum(z) возвращает '0'