Логарифм макрос

[Владимир Ситников]

Убедили.
Новая версия, на этот раз только натуральный логарифм (как самый востребованный)
И точность, с ваших слов, почти до 1e-7

CD32 выдаёт "оценку логарифма снизу". Значит, на 2(y+y³/3) подаются числа больше 1. Будут ли все они меньше 1.1? Без понятия (==надо вдумчиво курить CD32), но по нескольким тестам все они оказываются меньше 1.1

Вот график ln(x)-2(y+y³/₃) (диапазон по вертикали: -1e-8 .. 1e-7):
Снимок экрана 2016-06-13 в 11.05.03.png

[AI!]

Будут ли все они меньше 1.1? Без понятия

да.
то что на входе 3ей итерации даёт ответ строго меньше 1/8,
т.е. на входе оной будет строго меньше 2^(1/8)~1,09050

PS может всё же вернуть на место 3ю итерацию?
а с помощью рядов считать 4ую, и на входе рядов будет меньше 2^(1/256)~1,0027

[AI!]

да.
то что на входе 3ей итерации даёт ответ строго меньше 1/8,
т.е. на входе оной будет строго меньше 2^(1/8)~1,09050

ещё подумал..... и просто сдвинул "ожидаемый ответ" от 3ей итерации с (0..1/8) на (-1/16..1/16)
т.е. на входе оной вместо (1;1,09050) будет (0,95760;1,04427), что ещё повысит точность...

[Владимир Ситников]

ещё подумал..... и сдвинул "ожидаемый ответ" от 3ей итерации с (0..1/8) на (-1/16..1/16)
т.е. на входе оной вместо (1;1,09050) будет (0,95760;1,04427), что ещё повысит точность...

Да прибавить 0.5 ко второму CD32 это правильно.

И ещё вопрос: в чём великая задумка fDIV(x, x) и последующего fMUL в самом начале? По-моему, эти блоки лишние.

[AI!]

И ещё вопрос: в чём великая задумка fDIV(x, x) и последующего fMUL в самом начале? По-моему, эти блоки лишние.

привычка программиста - отсекать неправильные значения... (т.н. "защита от дурака")
x/x=1 при x!=0, и в ПР x/x=0 при x=0
т.е. ещё когда не было ни строчки ниже первого блока, я вставил эту проверку, что бы обнулить выход когда x=0
(изначально я предполагал, что на выходе может быть случайное значение)

PS по этой же причине я делаю проверку x=1, и если это так, то умножаю ответ на 0

[Владимир Ситников]

привычка программиста - отсекать неправильные значения... (т.н. "защита от дурака") в ПР x/x=0 при x=0

Блин. Есть же стандарты на то, что должно получаться при 0/0.
Интересно, ОВЕН во всех своих приборах теперь будет воспроизводить багу с 0/0=0?
По-моему, выглядит хлипковато, даже, если и работает на текущем железе.

Ошибочные числа вида NaN / inf на общей схеме видно. А про 0 далеко не сразу скажешь, что это признак "ошибки".

Ну, выйдет какое-нибудь ПР440 на другом процессоре. Там тоже будет 0/0=0?
Если уж и делать "защиту от ln(0)", то лучше ставить всем понятное fGT(1e-37). Т.е., если исходное значение меньше 1e-37 (ну или чему там +0 равен), то возвращать -infinity. Всем понятно, и без завязок на конкретное ПР с его 0/0.

[AI!]

Блин. Есть же стандарты на то, что должно получаться при 0/0.

Уже обсуждался этот вопрос на этом форуме.
Народ ожидает что 0*x должен быть всегда 0, даже если x=∞, т.к. умножение часто используется как вещественное SEL.
То же самое и с делением.

PS скорее всего до этого всё работало так как Вы хотите....

PPS ещё в МК-61 была функция знак(х), на ПР её можно смоделировать как x/|x|
так что мне нравится текущее положение дел...

[Владимир Ситников]

да.
то что на входе 3ей итерации даёт ответ строго меньше 1/8,
т.е. на входе оной будет строго меньше 2^(1/8)~1,09050

PS может всё же вернуть на место 3ю итерацию?
а с помощью рядов считать 4ую, и на входе рядов будет меньше 2^(1/256)~1,0027

А смысл возвращать третью итерацию cd32? 1.09 вполне достаточно для ряда. А fpow 256 вряд ли положительно скажется на скорости.