Пределы вычислений

[ALexey7ov]

Просчитайте на стандартном калькуляторе Windows или каком либо другом значение выражения 2^52 (2 в степени 52) и в LibreOffice Calc или в макросе. Почему выходит разница в арифметических вычислениях? Ведь результат должен быть одинаков, а Libre даёт ошибку. Также и в других вычислениях с большими числами.

[Yakov]

В Calc это сделано для совместимости с Excel.
Где-то даже баг был.

[ALexey7ov]

И как же сделать тогда так, чтобы в макросе было правильное число?

[rami]

Также и в других вычислениях с большими числами.

Это не проблема Basic. Очень большие числа начиная с определённой величины нужно округлять. LibreOffice (и Apache OpenOffice) делает это начиная с 999999999999997. Если ячейку с числом 999999999999997 растянуть вниз, можно увидеть округлённое отображение результата, но сам результат ведёт себя как точное число.

[JohnSUN]

И как же сделать тогда так, чтобы в макросе было правильное число?

А зачем оно нужно - правильное число пятьдесят второй степени двойки?
Вообще-то, ошибка вычислений возникает немного раньше, на пятидесятой степени. Для 2^49 мы еще можем получить правильное значение 562949953421312 (пятьсот шестьдесят два триллиона девятьсот сорок девять миллиардов девятьсот пятьдесят три миллиона четыреста двадцать одна тысяча триста двенадцать). А для 2^50 Сalc уже вместо ожидаемого 1125899906842624 выдаст 1125899906842620 (один триллион сто двадцать пять триллионов восемьсот девяносто девять миллиардов девятьсот шесть миллионов восемьсот сорок две тысячи шестьсот двадцать) - последнюю четвёрку уже "зажилит"... И чем дальше, тем больше будет врать. Гарантированная точность отображения результата - 15 цифр. Всё, что больше, будет просто дополняться нулями, "усекаться".
Скрипт на Пайтоне будет (по крайней мере, должен) выдавать точный результат. Но если этот точный результат в конце концов вывести, допустим, в ячейку таблицы, то опять получим нули вместо последних цифр...
Потому и интересуюсь - зачем?

[JohnSUN]

rami прав - картинка нагляднее...

[rami]

Вообще-то, ошибка вычислений возникает немного раньше, на пятидесятой степени.

Это не ошибка вычисления, а особенность отображения (ниже ты объяснил правильно)

Гарантированная точность отображения результата - 15 цифр. Всё, что больше, будет просто дополняться нулями, "усекаться".
Скрипт на Пайтоне будет (по крайней мере, должен) выдавать точный результат. Но если этот точный результат в конце концов вывести, допустим, в ячейку таблицы, то опять получим нули вместо последних цифр...

Попробовал вычисления с 2⁵⁰⁰ разделить на 2⁴⁸⁰ — результат точный

[JohnSUN]

Тем не менее, интересно - зачем?
"- И от злости она повесилась на собственной косе, потому что он точно посчитал, сколько капель в море, сколько песчинок в пустыне и сколько звезд на небе. Так выпьем же за кибернетику!" (с) "Кавказская пленница"

[ALexey7ov]

Ахахах, JohnSUN, интересная выдержка . Да, rami прав, это лишь особенность отображения, а не ошибка вычисления, как я решил сначала. Самый главный вопрос Зачем. Всё более прозаично и намного менее романтично красавицы повесившейся на своей косе. Конкретная задача - это формирование значения для использования в штрих-коде. Раз с вопросом о точности вычисления разобрались, осталось лишь одно узкое место, где остаются неясности. Это то, что при формировании значения штрих кода используются последовательные остатки от деления этого огромного ужасающего числа. Видимо, в этом и проблема. В Basic функция mod и для меньших чисел сразу же кричит о переполнении, поэтому решил написать свою ей замену для больших чисел: (Остаток от деления) = (Огромное ужасающее число) минус (Делитель) умноженный на целую часть ((Огромного ужасающего числа) делённого на (Делитель)). Пример: 5 mod 2 = 1, аналогично 5-2*(5\2)=1, где знак "\" деление нацело (берётся целая часть числа). Только с этим арифметическим оператором опять возникла проблема переполнения, поэтому было решено сердито заменить его на функцию fix. 5-2*fix(5/2)=1. На этот раз никаких ошибок выдано не было, но после сравнения полученного значения со значениями функций mid в calc и с функцией mid в том же самом калькуляторе было получено три совершенно разных результата. И это уже у функции mid в Calc, видимо не особенность отображения. Функция Fix в Basic, похоже, что тоже неприменима для данных огромных ужасающих чисел.
На основании сего опять понял, что и этот финт ушами не прокатил. Теперь вопрос: как вычислить остаток от деления, получаемый от этих Огромных ужасающих чисел?

[ALexey7ov]

Сейчас проверил предположение насчёт 15-ти знаков, действительно, верно. Для типа данных Double 15-ть знаков в сумме. Т.е., если целая часть состоит из 10-ти, то дробная из 5-ти, если целая из 7-ми, то дробная из 8-ми, потому и функция fix с самописной формулой вычисления остатка от деления не отрабатывают как надо. Но вопрос остаётся, как же для таких чисел в Basic найти остаток от деления?

[rami]

Теперь вопрос: как вычислить остаток от деления, получаемый от этих Огромных ужасающих чисел?

С Basic наверно не получится.

Попробовал Python, восемнадцатизначное число заглатывает не закусывая, и выдаёт и остаток и целую часть

[kompilainenn]

а Питон прикручивается к ЛО?

[Yakov]

В версии для Windows идёт уже прикрученный.

[rami]

а Питон прикручивается к ЛО?

Он не столько "прикручивается", сколько иногда "откручивается". Он был по крайней мере с третьей версии, но в предпоследних версиях (4.+) я не мог получить доступ к библиотекам питона в LO (не скажу, что настойчиво пытался), в пятой версии вернулось.

[Yakov]

Была ошибка с Python "из коробки"  в LO 3.3.0 под Windows, а в 3.3.1 - исправили.
В Linux же LO использует системный Python, и тут могут возникнуть проблемы,
например, если установлены Python 2 и Python 3.
Как с этим обстоят дела на Mac - не знаю.