Таблицы Google Docs и нелинейная математика
Неужто нынче в школах не рассказывают о точности вычислений и возможных проблемах при переводе из десятичной системы в двоичную (и обратно)? 
Точность расчета в формулах Excel
Как изменить точность вычислений в формулах Excel?
Научно-познавательно
Расчеты в Excel - пределы точности
Точность расчета в формулах Excel
Как изменить точность вычислений в формулах Excel?
Научно-познавательно
Расчеты в Excel - пределы точности
Для программиста не должно быть открытием, что вполне "пристойное" в десятичной системе вещественное число в двоичной может превратиться в бесконечную дробь (во времена развитого социализма это разъяснялось, хотя никаких "Ёкселей" ещё и в помине не существовало) - ежели я не ошибаюсь, 0.4 после преобразования "туда-обратно" должно превратиться в 0.3999(9), либо 0.400(0)1, в зависимости от способа округления, равно как и "честный" калькулятор после операции (1/3)*3 должен показать 0.999(9) [иные результаты лежат на совести программиста]. Любопытно, как контролируются ошибки такого рода при финансовых операциях - ведь в принципе за счёт округений неизбежных при вычислениях остатков в десятые доли копейки можно неплохо заработать 
(слышал когда-то такую легенду).
(во времена развитого социализма это разъяснялось, хотя никаких "Ёкселей" ещё и в помине не существовало) - ежели я не ошибаюсь, 0.4 после преобразования "туда-обратно" должно превратиться в 0.3999(9), либо 0.400(0)1, в зависимости от способа округления, равно как и "честный" калькулятор после операции (1/3)*3 должен показать 0.999(9) [иные результаты лежат на совести программиста]. Любопытно, как контролируются ошибки такого рода при финансовых операциях - ведь в принципе за счёт округений неизбежных при вычислениях остатков в десятые доли копейки можно неплохо заработать (слышал когда-то такую легенду).Любопытно, как контролируются ошибки такого рода при финансовых операциях - ведь в принципе за счёт округений неизбежных при вычислениях остатков в десятые доли копейки можно неплохо заработатьУ меня давным-давно в программе такое получилось, случайно. Потом мы с начальством посмеялись над тем, как в миллионных проводках "теряются" копейки, и я ушел переписывать программу. Основное средство - избегать операций с плавающей точкой.
Для программиста не должно быть открытием, что вполне "пристойное" в десятичной системе вещественное число в двоичной может превратиться в бесконечную дробьЕсли для них это не открытие, то как объясняется тот факт, что Excel до сих пор ошибается в вычислениях, никак не учитывая это "известное"? Могли бы и написать формулы, учитывающие такую особенность и не дающие 50% неверных ответов.
На вышеприводимом примере с десятичными числами (2 знака после запятой) - на 10 примерах 50% ошибок, на 100 примерах - 52% верных ответов.
=ЕСЛИ(((RC[-4]-RC[-3]) = (RC[-2]-RC[-1]));"равно";"не равно")
Т.е. таблицы считают ровно, как блондинка из анекдота про вероятность встретить динозавра на улицах города - 50/50 - либо встречу, либо нет.
Программеры сего продукта наслаждаются своим сакральным знанием, но не принимают никаких действий к исправлению ситуации, почему?
Это кто им такое сказал, компьютер?
Люди, считающие комп умнее себя, действительно не очень умные.
С таким подходом мир поработят роботы (коими такие прогеры отчасти и являются).
Да и кто их заставляет "на все случаи жизни"?
Достаточно в своём приложении сделать, чтоб решение отвечало логике, а не противоречило ей.
Если бы инженеры выполняли свои задачи с таким подходом (50/50 - сработает или нет), что бы было?
Так почему в простом приложении считается это позволительным?
Метод устранения этого нелогизма вполне прост, так почему не используется?
Вместо точности 99,9999999999%, обеспечиваемой компом, прогеры заложили алгоритм, дающий 52% точности решения.
Им бы за такое приговор выносить в стиле "казнить нельзя помиловать"
Люди, считающие комп умнее себя, действительно не очень умные.
С таким подходом мир поработят роботы (коими такие прогеры отчасти и являются).
Да и кто их заставляет "на все случаи жизни"?
Достаточно в своём приложении сделать, чтоб решение отвечало логике, а не противоречило ей.
Если бы инженеры выполняли свои задачи с таким подходом (50/50 - сработает или нет), что бы было?
Так почему в простом приложении считается это позволительным?
Метод устранения этого нелогизма вполне прост, так почему не используется?
Вместо точности 99,9999999999%, обеспечиваемой компом, прогеры заложили алгоритм, дающий 52% точности решения.
Им бы за такое приговор выносить в стиле "казнить нельзя помиловать"
Таки в том и проблема, что учёт ошибок/округлений вычислений - дело очень сложное, начинающее интересовать пользователей только после получения результата, явно отличного от ожидаемого 
Вы бы сначала проверили, что выдаёт Excel после выполнения ваших рекомендаций и нажатия "пересчёт листа".
Подсказываю - результат аналогично неправильный в данном примере
Есть ещё доводы в пользу такого инструмента?
Подсказываю - результат аналогично неправильный в данном примере
Есть ещё доводы в пользу такого инструмента?
Я проверил тот пример, который показал Cel, в LibreOffice. Он дает ожидаемый результат: везде "НЕ равно"
Сомнительно, чтобы кто-то предъявлял к тормозам требование работы в режиме 0/1 (полная свобода/полная блокировка колёс), без учёта пожеланий водителя
Аналогично в Excel'е (и вычислениях в общем случае): имеется множество функций округления, и их надлежащее использование - проблема не Excel'я, но квалификации пользователя, для которого понаписано множество статей вроде
Не следует винить молоток (или Excel) в постоянном попадании по пальцам
Аналогично в Excel'е (и вычислениях в общем случае): имеется множество функций округления, и их надлежащее использование - проблема не Excel'я, но квалификации пользователя, для которого понаписано множество статей вроде
Не следует винить молоток (или Excel) в постоянном попадании по пальцам
Плохому танцору вечно пол мешает.
Всего-то делов - придумать математику/систему счисления, в которой в принципе было бы невозможно появление бесконечных дробей
Есть, конечно, частичное решение - обязать изготовителей выпускать процессоры с десятичной системой, но дорого будет, и Microsoft к этому отношения не имеет (ну если только тот научится создавать программы, предугадывающие возможные потребности пользователя).
Всего-то делов - придумать математику/систему счисления, в которой в принципе было бы невозможно появление бесконечных дробей
Есть, конечно, частичное решение - обязать изготовителей выпускать процессоры с десятичной системой, но дорого будет, и Microsoft к этому отношения не имеет (ну если только тот научится создавать программы, предугадывающие возможные потребности пользователя).
Как-то сразу не сообразил, что здесь имеет место некорректное использование логической функции
IF фактически производит побитовое сравнение (что позволяет сравнивать, например, текстовые строки), для вещественных чисел проверка на равенство может быть проблематична - следует проверять на больше/меньше (тем более с учётом возможности появления машинного нуля).
Их возможных вариантов - сравнивать не разницы вида "(RC[-4]-RC[-3])", но их округлённые (до нужного числа знаков) значения, по принципу
IF((ROUND(A;2) - (ROUND(B;2)) = 0);"равно";"не равно")
где
A=RC[-4]-RC[-3]
B=RC[-2]-RC[-1]
соответственно. В общем случае следует думать, какую из имеющихся функций округления дОлжно использовать.
Если посмотреть результаты вычисления разницы с отображением достаточного количества знаков, хорошо видно, откуда берётся "странный" результат.
К сожалению, в help'е по Excel'ю этого не нашёл (во всяком случае, сразу) - пожалуй, это можно отнести к серьёзному упущению, хотя не знаю, насколько это часто встречается.
Относительно "автоматизации" - таки невозможно, ибо неизвестен характер проводимых вычислений/требуемая точность (грубый пример - те же тормоза: ступенчатое срабатывание в каких-то случаях может быть полезно, в каких-то безразлично, но может и привести к проблемам, потому делается "на усмотрение пользователя").
IF фактически производит побитовое сравнение (что позволяет сравнивать, например, текстовые строки), для вещественных чисел проверка на равенство может быть проблематична - следует проверять на больше/меньше (тем более с учётом возможности появления машинного нуля).
Их возможных вариантов - сравнивать не разницы вида "(RC[-4]-RC[-3])", но их округлённые (до нужного числа знаков) значения, по принципу
IF((ROUND(A;2) - (ROUND(B;2)) = 0);"равно";"не равно")
где
A=RC[-4]-RC[-3]
B=RC[-2]-RC[-1]
соответственно. В общем случае следует думать, какую из имеющихся функций округления дОлжно использовать.
Если посмотреть результаты вычисления разницы с отображением достаточного количества знаков, хорошо видно, откуда берётся "странный" результат.
К сожалению, в help'е по Excel'ю этого не нашёл (во всяком случае, сразу) - пожалуй, это можно отнести к серьёзному упущению, хотя не знаю, насколько это часто встречается.
Относительно "автоматизации" - таки невозможно, ибо неизвестен характер проводимых вычислений/требуемая точность (грубый пример - те же тормоза: ступенчатое срабатывание в каких-то случаях может быть полезно, в каких-то безразлично, но может и привести к проблемам, потому делается "на усмотрение пользователя"
).Нельзя создать абсолютный универсальный инструмент - хотя бы по причине принципиальной невозможности вести вычисления с бесконечной точностью; заданную же точность кто-то должен задать, что и входит в обязанности конкретного пользователя
Для компьютера не существует чисел вида "123,45"/"12,345" (чисто человеческая выдумка для "красоты") - в каждом случае это "0,12345E(соответствующая степень)": автоматически ограничить можно только количество значащих цифр, что способно привести к интересным эффектам вида 1000. - 1. = 1000.; при этом для целых чисел результат будет-таки 999
Из простых примеров - результат (1/3)*3 равен единице только в том случае, если "вычислителю" известна формула; умножая на 3 полученное (откуда-то) число 0,3333, пользователь должен самостоятельно решать, следует ли результат округлить до единицы, или же оставить как есть, поскольку такое решение может существенно сказаться на некоем окончательном результате вычислений; никакой Microsoft ничего не изменит без патентованных предсказателей (вернее, без придания Excel'ю способностей предсказания).
Гипер-Excel, умеющий решать подобные проблемы, не будет нуждаться в нелепом биологическом придатке для давления кнопок
Для компьютера не существует чисел вида "123,45"/"12,345" (чисто человеческая выдумка для "красоты") - в каждом случае это "0,12345E(соответствующая степень)": автоматически ограничить можно только количество значащих цифр, что способно привести к интересным эффектам вида 1000. - 1. = 1000.; при этом для целых чисел результат будет-таки 999
Из простых примеров - результат (1/3)*3 равен единице только в том случае, если "вычислителю" известна формула; умножая на 3 полученное (откуда-то) число 0,3333, пользователь должен самостоятельно решать, следует ли результат округлить до единицы, или же оставить как есть, поскольку такое решение может существенно сказаться на некоем окончательном результате вычислений; никакой Microsoft ничего не изменит без патентованных предсказателей (вернее, без придания Excel'ю способностей предсказания).
Гипер-Excel, умеющий решать подобные проблемы, не будет нуждаться в нелепом биологическом придатке для давления кнопок
Сколько можно судить, "точность как на экране" определяет количество десятичных разрядов 
support.microsoft.com ("Результаты арифметических операций с плавающей точкой в Excel могут быть неточными"):
Логическая операция выполняется применительно как раз к этим битам, плюс к этому (в приведённом примере) над результатом выполнения некоей арифметической операции, и Microsoft не случайно упоминает о функции округления (см. ссылку).
support.microsoft.com ("Результаты арифметических операций с плавающей точкой в Excel могут быть неточными"):
Логическая операция выполняется применительно как раз к этим битам, плюс к этому (в приведённом примере) над результатом выполнения некоей арифметической операции, и Microsoft не случайно упоминает о функции округления (см. ссылку).
В принципе, какой-то "упрощённый" вариант вычислений не был бы лишним, хотя ошибок в операциях прихода/расхода возникать не должно, а что сложнее - то от лукавого
До сих пор непонятно?
Именно о том, что "программисты - знают все", но ничего не сделали, чтоб это работало правильно в их инструменте во всех вариантах, а не специально подогнанных пользователем!!!
Это всё равно, что прежде, чем крутить гайки ключом его нужно было подточить напильником.
Если вы смотрели пример, то там формат ячеек именно числовой, но в логической операции на промежуточные значения ничто не влияет - ни выставление точности расчёта в настройках, не "как на экране".
Это сродни, если бы вам приходилось каждый раз при переключении канала ТВ подстраивать его частоту, т.к. цифровая память тюнера не может помнить точно её аналоговое значение.
Если значения результатов промежуточной операции выводить в ячейки с заданной точностью 12-15 знаков после запятой (в настройках соответственно настроить), то они будут одинаковы.
Так какого рожна эта точно не прменяется, если результаты не пишутся в ячейку?
Вот именно про такие косяки программеров и споры. Большинству (из новых) просто не понять в силу ограниченности, что с прогой работаю обычные люди, а не программисты.
Курирую один софт - мозоли можно заработать написанием баг-репортов.
За 4 года они не исправили все понаписанные ошибки, которые отсутствовали в его ДОС-версии
Пример из известного: если в ДОСе никак нельзя было повлиять на стандартное английское сообщение про "any key", то тут они тупо переводят как "любую кнопку", а это дополнительные 80-100 звонков за год, а можно было просто написать "пробел" или "ESC", чтоб не пудрить мозги.
Так ведь ещё и упираются.
Именно о том, что "программисты - знают все", но ничего не сделали, чтоб это работало правильно в их инструменте во всех вариантах, а не специально подогнанных пользователем!!!
Это всё равно, что прежде, чем крутить гайки ключом его нужно было подточить напильником.
Если вы смотрели пример, то там формат ячеек именно числовой, но в логической операции на промежуточные значения ничто не влияет - ни выставление точности расчёта в настройках, не "как на экране".
Это сродни, если бы вам приходилось каждый раз при переключении канала ТВ подстраивать его частоту, т.к. цифровая память тюнера не может помнить точно её аналоговое значение.
Если значения результатов промежуточной операции выводить в ячейки с заданной точностью 12-15 знаков после запятой (в настройках соответственно настроить), то они будут одинаковы.
Так какого рожна эта точно не прменяется, если результаты не пишутся в ячейку?
Вот именно про такие косяки программеров и споры. Большинству (из новых) просто не понять в силу ограниченности, что с прогой работаю обычные люди, а не программисты.
Курирую один софт - мозоли можно заработать написанием баг-репортов.
За 4 года они не исправили все понаписанные ошибки, которые отсутствовали в его ДОС-версии
Пример из известного: если в ДОСе никак нельзя было повлиять на стандартное английское сообщение про "any key", то тут они тупо переводят как "любую кнопку", а это дополнительные 80-100 звонков за год, а можно было просто написать "пробел" или "ESC", чтоб не пудрить мозги.
Так ведь ещё и упираются.
Пользователям извилины на бигуди накручивать тоже программисты должны?
Excel - это инструмент, которым, как и любым другим инструментом, нужно уметь пользоваться. Универсально решить, нужно ли пользователю зачение "пи" 3.1, или требуется точность до двадцатого знака, невозможно, как и выпустить спички, которые загорались бы только в руках взрослого человека. Предусмотрены все средства для решения возможных проблем, тупость пользователя относить на счёт программистов представляется некорректным.
Вам уже сказали: работает правильно. Как именно - производитель подробно расписал в справке (ссылка была выше, спасибо за нее).
То, что вам эти правила неизвестны - ваши личные проблемы.
Аналогия ваша в корне ошибочна.
Правильной аналогией будет знание какой ключ надо применить (формы и размера) в данной ситуации, и как именно правильно применить, с каким усилием затягивать.
А то ведь можно все и плоскогубцами крутить, а потом возмущаться, что отвалилось.
Для этого есть другие разделы форума.
То, что вам эти правила неизвестны - ваши личные проблемы.
Аналогия ваша в корне ошибочна.
Правильной аналогией будет знание какой ключ надо применить (формы и размера) в данной ситуации, и как именно правильно применить, с каким усилием затягивать.
А то ведь можно все и плоскогубцами крутить, а потом возмущаться, что отвалилось.
За 4 года они не исправили все понаписанные ошибки, которые отсутствовали в его ДОС-версииКак это относится к теме? наболело?
Пример из известного: если в ДОСе никак нельзя было повлиять на стандартное английское сообщение про "any key", то тут они тупо переводят как "любую кнопку", а это дополнительные 80-100 звонков за год, а можно было просто написать "пробел" или "ESC", чтоб не пудрить мозги.
Так ведь ещё и упираются.
Для этого есть другие разделы форума.
Не вижу ничего грустного, акромя неумения и нежелания учиться правильно(!) пользоваться плоскогубцами, пардон инструментом.
(1/3) * 3 - 3 == -2 или около того, смотря КАК считаем. Уж нулю оно точно НЕ равно, а больше нули и подавно быть не могет. Ни в какой типовой системе кодирования.
Если вы имели ввиду это:
(1/3) * 3 - 1 == 0, >0 или <0 --, то оно сильно зависит от примененной системы кодирования чисел и методик округления.
Так, к примеру вычисления будут приближенными во всех широкоупотребимых системах, акромя хранения чисел в виде рациональной дроби. При ряде соглашений - будет нормально считаться в дв-десятичных и др. типовых системах.
Очень часто это принципиально, ибо во множестве матметодов принципиально важно... и далее
Да ну? А может с теорией вычислительных методов чуток поближее познакомиться... хотя, теперь может оно и так. Раз уж даже спутник нормально запустить не шмогли...
(1/3) * 3 - 3 == -2 или около того, смотря КАК считаем. Уж нулю оно точно НЕ равно, а больше нули и подавно быть не могет. Ни в какой типовой системе кодирования.
Если вы имели ввиду это:
(1/3) * 3 - 1 == 0, >0 или <0 --, то оно сильно зависит от примененной системы кодирования чисел и методик округления.
Так, к примеру вычисления будут приближенными во всех широкоупотребимых системах, акромя хранения чисел в виде рациональной дроби. При ряде соглашений - будет нормально считаться в дв-десятичных и др. типовых системах.
Очень часто это принципиально, ибо во множестве матметодов принципиально важно... и далее
Да ну? А может с теорией вычислительных методов чуток поближее познакомиться... хотя, теперь может оно и так. Раз уж даже спутник нормально запустить не шмогли...