Таблицы Google Docs и нелинейная математика

Посмотрите здесь чтоли...

В ответ на: Или у них другая арифметика, не по Магницкому?

После Магницкого еще можно почитать учебники по дискретной математике. Они к компьютеру - а вы пользуетесь именно компьютером - имеют большее отношение.

При экспорте в Excel результат получается нормальный, 184,2
Видимо, дядя Билл не такой продвинутый, как Серега Брин.

В ответ на: При экспорте в Excel результат получается нормальный, 184,2
Видимо, дядя Билл не такой продвинутый, как Серега Брин.

Это вам только кажется.
Если бы вы потрудились почитать приведенную мною ссылку - то увидели бы аналогичные примеры для MS Excel.
В общем случае - добавьте в Excel количество отображаемых знаков после запятой и удивитесь.

Верно. Увеличил разрядность, тоже единица в 12 разряде возникает
Добавил тот же ряд чисел в столбец, просуммировал. По прежнему единица, там же, но не двойка. Умножил еще на два. Единица превратилась в тройку.
Получается, если сложить несколько триллионов, поиграв с запятыми, а потом их же отнять, получится остаток в несколько единиц? Я думал, такая ерунда только при делении получается

Неужто нынче в школах не рассказывают о точности вычислений и возможных проблемах при переводе из десятичной системы в двоичную (и обратно)?

Точность расчета в формулах Excel
Как изменить точность вычислений в формулах Excel?
Научно-познавательно
Расчеты в Excel - пределы точности

В приведенных Вами ссылках говорится о пределе точности в 15 значащих разрядов, что понятно.
Но там нет ни слова, о том, что неточности могут возникнуть при операциях с 5-6-разрядными числами, которые в моем примере.
Я-то в школе давно учился давно, Эксель не изучал. Но вот, судя по ссылке от KSergei, даже для программиста было открытием, что результат вычисления 37.48-37 меньше 0.48, а 31.48-31 - больше.

В ответ на: даже для программиста было открытием

Одно слово тут написано с ошибками во всех буквах, догадайтесь какое )

В ответ на: ...нет ни слова, о том, что неточности могут возникнуть при операциях с 5-6-разрядными числами... даже для программиста было открытием...

Для программиста не должно быть открытием, что вполне "пристойное" в десятичной системе вещественное число в двоичной может превратиться в бесконечную дробь (во времена развитого социализма это разъяснялось, хотя никаких "Ёкселей" ещё и в помине не существовало) - ежели я не ошибаюсь, 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% точности решения.

Заметьте, формула, дающая "52% точности решения" (формулировка эта прекрасна сама по себе) написана вами лично. Однако виноваты, понятно, другие.
Всё как обычно, ничего нового.

В ответ на: Программеры сего продукта наслаждаются своим сакральным знанием, но не принимают никаких действий к исправлению ситуации, почему?

В общем все как обычно: инженеры (те самые) делают добротный, универсальный инструмент. В частности - MS Excel.
Но, увы, грамотно пользоваться этим инструментом некоторые не хотят учиться. Предлагаю вернуться к калькулятору.

А в MS Excel все продумано.

Идем в Сервис -> Параметры (это для 2003 версии, про 2007 не знаю где, но точно где-то есть)
Переключаемся на вкладку "Вычисления", включаем галочку "Точность как на экране".

Наслаждаемся. Правда, это относится ко всем расчетам, так что если где-то из-за округлений что-то "потеряется" - извините, вы сами этого хотели. Как сделать по другому - см. ссылки.

Ссылки по теме (найдено гуглем, намекаю на то, что доступно каждому):
http://www.sql.ru/forum/actualthread.aspx?tid=866975
http://www.firststeps.ru/msoffice/r.php?23

В ответ на: ...А в MS Excel все продумано...включаем галочку "Точность как на экране"...если где-то из-за округлений что-то "потеряется"...

Таки в том и проблема, что учёт ошибок/округлений вычислений - дело очень сложное, начинающее интересовать пользователей только после получения результата, явно отличного от ожидаемого

В ответ на: Заметьте, формула, дающая "52% точности решения" (формулировка эта прекрасна сама по себе) написана вами лично.

Допустим, не мной, но разница не велика!
Я конечный пользователь продукта Excel (вовсе не программист) и этот самый инструмент (продукт) должен отрабатывать на 100%, а не как сейчас на 52%.
Я должен его использовать, а он должен при этом работать всегда правильно, что в данном кокретном примере НЕ наблюдается при правильной логике построения - этого быть не должно.
Это всё-равно, что бы вам машину сделали с тормозами, работающими только на половине возможных скоростей и вам же ставили в вину, что вы хотите ездить с точностью до 0,1 км/час, не учитывая особенности сконструированного авто. Инженеров такого авто признали бы идиотами безоговорочно, а в отношении программеров, сделавших аналогичное у вас есть какие-то возражения?

В ответ на: А в MS Excel все продумано.

Идем в Сервис -> Параметры (это для 2003 версии, про 2007 не знаю где, но точно где-то есть)
Переключаемся на вкладку "Вычисления", включаем галочку "Точность как на экране".

Вы бы сначала проверили, что выдаёт Excel после выполнения ваших рекомендаций и нажатия "пересчёт листа".
Подсказываю - результат аналогично неправильный в данном примере
Есть ещё доводы в пользу такого инструмента?

Выкиньте каку и поставте LibreOffice, там проблем с округлением нет .)

Я проверил тот пример, который показал Cel, в LibreOffice. Он дает ожидаемый результат: везде "НЕ равно"

В ответ на: Вы бы сначала проверили, что выдаёт Excel после выполнения ваших рекомендаций и нажатия "пересчёт листа".

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

В ответ на: Есть ещё доводы в пользу такого инструмента?

Зачем вы себя мучаете?

Подозреваю, что вы под мелкомягкой платформой пробовали .)

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

В ответ на: ...Это всё-равно, что бы вам машину сделали с тормозами...

Сомнительно, чтобы кто-то предъявлял к тормозам требование работы в режиме 0/1 (полная свобода/полная блокировка колёс), без учёта пожеланий водителя

Аналогично в Excel'е (и вычислениях в общем случае): имеется множество функций округления, и их надлежащее использование - проблема не Excel'я, но квалификации пользователя, для которого понаписано множество статей вроде

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

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

точно представлять существующие стандартные методы округления,
уметь по расчету Excel или другому <эталонному> расчету определять использованные в нем методы округления,
уметь воспроизводить желаемый способ округления средствами языка, используемого для разработки...

Не следует винить молоток (или Excel) в постоянном попадании по пальцам

В ответ на: Не следует винить молоток (или Excel) в постоянном попадании по пальцам

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

В ответ на: ...удар у такого инструмента получается через раз...

Плохому танцору вечно пол мешает.
Всего-то делов - придумать математику/систему счисления, в которой в принципе было бы невозможно появление бесконечных дробей
Есть, конечно, частичное решение - обязать изготовителей выпускать процессоры с десятичной системой, но дорого будет, и Microsoft к этому отношения не имеет (ну если только тот научится создавать программы, предугадывающие возможные потребности пользователя).

Cel,
вы уже покажете ваш xls-файл с примером или так и будете картинки показывать и про кривые руки, пользующиеся "неправильным" молотком рассказывать?

В ответ на: Плохому танцору вечно пол мешает.

Это вы про те отмазки, почему этого нельзя сделать?
Подходит.

В ответ на: обязать изготовителей выпускать процессоры с десятичной системой

Вы не в ту сторону забурились. Всё намного проще - реализовать отрабатывание функции правильно с учётом особенности счисления процессоров (она ведь заранее известна).

В ответ на: Cel, вы уже покажете ваш xls-файл с примером

Во вложении.

В ответ на: ...Во вложении.

Как-то сразу не сообразил, что здесь имеет место некорректное использование логической функции
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'ю этого не нашёл (во всяком случае, сразу) - пожалуй, это можно отнести к серьёзному упущению, хотя не знаю, насколько это часто встречается.
Относительно "автоматизации" - таки невозможно, ибо неизвестен характер проводимых вычислений/требуемая точность (грубый пример - те же тормоза: ступенчатое срабатывание в каких-то случаях может быть полезно, в каких-то безразлично, но может и привести к проблемам, потому делается "на усмотрение пользователя" ).

В ответ на: хорошо видно, откуда берётся "странный" результат

Да откуда берётся всё понятно и 100 раз расписано по ссылке на первой странице.
Вопрос то в том почему? он вообще имеет право там появится. (Не имеет)
Нам же не конкретный пример надо решить, а иметь универсальный инструмен, дающий одинаковые результаты при математических вычислениях с одинаковыми алгоритмами, составленными с математической логикой.

В ответ на: сравнивать не разницы вида "(RC[-4]-RC[-3])", но их округлённые (до нужного числа знаков) значения
...
Относительно "автоматизации" - таки невозможно, ибо неизвестен характер проводимых вычислений

Опять же тут косяк Excel. Если следовать логике с неизвестным характером, то почему промежуточный результат, занесённый в ячейку без всяких ухищрений с округлением со стороны пользователя безжалостно округляется, независимо от "характера". При этом в данном примере сравнение результатов из ячеек (с большим количеством знаков после запятой) уже даёт правильный результат. Разве не следует вышепомянутую функцию сравненя реализовывать аналогично, с заданной точностью вычисления?
Ведь всем известно, что "от перемены мест слагаемых сумма не меняется", а вот у Майкрософта получается по другому.

Можно долго оправдывать отсутствие логики тем, что это тоже своеобразная "логика", но результаты-то получаются неверными. Да и логика должна быть человеческой, а не машинной. С чего и начинал свои посты в этой теме.

В ответ на: ...иметь универсальный инструмен, дающий одинаковые результаты при математических вычислениях...

...Разве не следует вышепомянутую функцию сравненя реализовывать аналогично, с заданной точностью вычисления?...

Нельзя создать абсолютный универсальный инструмент - хотя бы по причине принципиальной невозможности вести вычисления с бесконечной точностью; заданную же точность кто-то должен задать, что и входит в обязанности конкретного пользователя
Для компьютера не существует чисел вида "123,45"/"12,345" (чисто человеческая выдумка для "красоты") - в каждом случае это "0,12345E(соответствующая степень)": автоматически ограничить можно только количество значащих цифр, что способно привести к интересным эффектам вида 1000. - 1. = 1000.; при этом для целых чисел результат будет-таки 999
Из простых примеров - результат (1/3)*3 равен единице только в том случае, если "вычислителю" известна формула; умножая на 3 полученное (откуда-то) число 0,3333, пользователь должен самостоятельно решать, следует ли результат округлить до единицы, или же оставить как есть, поскольку такое решение может существенно сказаться на некоем окончательном результате вычислений; никакой Microsoft ничего не изменит без патентованных предсказателей (вернее, без придания Excel'ю способностей предсказания).

Гипер-Excel, умеющий решать подобные проблемы, не будет нуждаться в нелепом биологическом придатке для давления кнопок

В ответ на: Во вложении.

Хм, "точность как на экране" и впрямь не помогает почему-то.
Надо посмотреть.

В ответ на:

В ответ на: Во вложении.

Хм, "точность как на экране" и впрямь не помогает почему-то.
Надо посмотреть.

Сколько можно судить, "точность как на экране" определяет количество десятичных разрядов
support.microsoft.com ("Результаты арифметических операций с плавающей точкой в Excel могут быть неточными"):

В ответ на: ...дробь 1/10 может быть представлена в десятичном формате как 0,1. Однако это же число в двоичном формате становится повторяющимся двоично-десятичным числом
0001100110011100110011 (и т.д.)...

Логическая операция выполняется применительно как раз к этим битам, плюс к этому (в приведённом примере) над результатом выполнения некоей арифметической операции, и Microsoft не случайно упоминает о функции округления (см. ссылку).

Я, признаться, думал, что в MS Excel таки есть режим "для бухгалтеров". Но как-то не попадается пока.

В принципе, какой-то "упрощённый" вариант вычислений не был бы лишним, хотя ошибок в операциях прихода/расхода возникать не должно, а что сложнее - то от лукавого

Приход/расход как раз настраивается, беда с операцией сравнения. Похоже она не учитывает настроенные параметры расчетов в Excel.
Решается, понятно, своей функцией на VBA

На последнего.

1. Операции с типов FLOAT (это то, что делал топикстартер и работает на обычных и variant типах Excel) - страдают проблемой перевода "туда-сюда-обратно" и неточностью операций сравнения. Это то, что здесь обсуждалось выше. Они везде страдают - это просто свойство таких чиселок...

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

2. Excel в частности (в пятом было точно, позднее - не знаю) имеет возможность выбора типа чисел в ячейках, там есть такой тип как Currency (кажется так), который представлялся (не знаю как сейчас) ДЕСЯТИЧНЫМИ числами и НЕ страдал от ошибок округлений или "приблизительным" сравнением... специально предназначен был для точных вычислений... в частности денежных... Там должон быть цельный раздел хелпа по этому поводу.

3. "Васик" завсегда имел вычисления в виде двоично-десятичного формата... щас - не так? о-о-о...

В ответ на: ни понятно о чем стока копий...

До сих пор непонятно?
Именно о том, что "программисты - знают все", но ничего не сделали, чтоб это работало правильно в их инструменте во всех вариантах, а не специально подогнанных пользователем!!!
Это всё равно, что прежде, чем крутить гайки ключом его нужно было подточить напильником.
Если вы смотрели пример, то там формат ячеек именно числовой, но в логической операции на промежуточные значения ничто не влияет - ни выставление точности расчёта в настройках, не "как на экране".
Это сродни, если бы вам приходилось каждый раз при переключении канала ТВ подстраивать его частоту, т.к. цифровая память тюнера не может помнить точно её аналоговое значение.

Если значения результатов промежуточной операции выводить в ячейки с заданной точностью 12-15 знаков после запятой (в настройках соответственно настроить), то они будут одинаковы.
Так какого рожна эта точно не прменяется, если результаты не пишутся в ячейку?
Вот именно про такие косяки программеров и споры. Большинству (из новых) просто не понять в силу ограниченности, что с прогой работаю обычные люди, а не программисты.
Курирую один софт - мозоли можно заработать написанием баг-репортов.
За 4 года они не исправили все понаписанные ошибки, которые отсутствовали в его ДОС-версии
Пример из известного: если в ДОСе никак нельзя было повлиять на стандартное английское сообщение про "any key", то тут они тупо переводят как "любую кнопку", а это дополнительные 80-100 звонков за год, а можно было просто написать "пробел" или "ESC", чтоб не пудрить мозги.
Так ведь ещё и упираются.

В ответ на: ..."любую кнопку", а это дополнительные 80-100 звонков за год, а можно было просто написать "пробел" или "ESC", чтоб не пудрить мозги.
Так ведь ещё и упираются.

Пользователям извилины на бигуди накручивать тоже программисты должны?
Excel - это инструмент, которым, как и любым другим инструментом, нужно уметь пользоваться. Универсально решить, нужно ли пользователю зачение "пи" 3.1, или требуется точность до двадцатого знака, невозможно, как и выпустить спички, которые загорались бы только в руках взрослого человека. Предусмотрены все средства для решения возможных проблем, тупость пользователя относить на счёт программистов представляется некорректным.

В ответ на: Именно о том, что "программисты - знают все", но ничего не сделали, чтоб это работало правильно в их инструменте во всех вариантах, а не специально подогнанных пользователем!!!

Вам уже сказали: работает правильно. Как именно - производитель подробно расписал в справке (ссылка была выше, спасибо за нее).
То, что вам эти правила неизвестны - ваши личные проблемы.

В ответ на: Это всё равно, что прежде, чем крутить гайки ключом его нужно было подточить напильником.

Аналогия ваша в корне ошибочна.
Правильной аналогией будет знание какой ключ надо применить (формы и размера) в данной ситуации, и как именно правильно применить, с каким усилием затягивать.
А то ведь можно все и плоскогубцами крутить, а потом возмущаться, что отвалилось.

В ответ на: За 4 года они не исправили все понаписанные ошибки, которые отсутствовали в его ДОС-версии
Пример из известного: если в ДОСе никак нельзя было повлиять на стандартное английское сообщение про "any key", то тут они тупо переводят как "любую кнопку", а это дополнительные 80-100 звонков за год, а можно было просто написать "пробел" или "ESC", чтоб не пудрить мозги.
Так ведь ещё и упираются.

Как это относится к теме? наболело?
Для этого есть другие разделы форума.

Ну про аналогию с ключом - меня опередили. Пра-авильно ведь написал KSergey!

Добавлю лишь то, что Excel - как хороший набор "слесаря сантехника" предлагает просто офигительный комплект этих самых ключей.

Другое дело, какой из них прогеры Мелкософта подсовывают "по умолчанию"... соглашусь с вами - да, часто самый не нужный (тоже частенько бесит)... но это, действительно знания и умения, навык и опыт конкретного юзверя этого самого "набора сантехника"...

про то что "наболело" - лучше не надо... ДОСовский софт в подавляющем большинстве случаев писан на пару порядков качественнее. И это - понятно почему. Не так давно, поднял старую ДОС-овскую игруху, которая на 286 пересчитывала ход около 3минут... летает аж сил нет...

Добавлю, что бывают случаи, когда все намного грустнее еще. Например, выражение (1/3) * 3 - 3 по математике должно быть в точности равно нулю. Но в реальном компьютере оно может быть равно нулю, меньше нуля (что всего вероятнее), да и больше нуля тоже. Очень часто это принципиально, ибо во множестве матметодов принципиально важно, равно число нулю (или другому числу), болше него, либо меньше. К примеру, в линейной алгебре. Из-за этого на компьютере нифига не работает метод Гаусса, метод определителей (Крамера) и еще дофига разных теоретически безупречных матметодов. Проблема философская, математика хороша, но, падло, с реальностью совпадает не всегда.

Не вижу ничего грустного, акромя неумения и нежелания учиться правильно(!) пользоваться плоскогубцами, пардон инструментом.

(1/3) * 3 - 3 == -2 или около того, смотря КАК считаем. Уж нулю оно точно НЕ равно, а больше нули и подавно быть не могет. Ни в какой типовой системе кодирования.

Если вы имели ввиду это:
(1/3) * 3 - 1 == 0, >0 или <0 --, то оно сильно зависит от примененной системы кодирования чисел и методик округления.

Так, к примеру вычисления будут приближенными во всех широкоупотребимых системах, акромя хранения чисел в виде рациональной дроби. При ряде соглашений - будет нормально считаться в дв-десятичных и др. типовых системах.

Очень часто это принципиально, ибо во множестве матметодов принципиально важно... и далее

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

Торопилсо... (1/3)*3 - 1. Признаю....

В ответ на: Очень часто это принципиально, ибо во множестве матметодов принципиально важно... и далее

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

Хм... если вы будете решать систему уравнений методом определителей, а уравнений и неизвестных будет поболее десятка, то вам никакая теория вычислительных методов не поможет. Слишком много умножений. А между тем, именно этот метод во всех курсах математики для ВУЗов. Я об этом. О том, что с точки зрения математики метод определителей работает, а в реальности - нет.

Даже больше того, (1/3)*3 - 1 = -1 . А вот (1./3.)*3. -1. будет где-то около нуля.

Вообще-то выч.методы, в отличие от аналитической математики, как раз и оперируют приближенными значениями (в лучшем случае -- с машинной точностью). И при их использовании просто нужно это учитывать.

В ответ на: Хм... если вы будете решать систему уравнений методом определителей, а уравнений и неизвестных будет поболее десятка, то вам никакая теория вычислительных методов не поможет. Слишком много умножений.

А что вам мешает использовать целочисленные вычисления, лень или незнание/неумение применять теорию на практике ?

В ответ на: Даже больше того, (1/3)*3 - 1 = -1 . А вот (1./3.)*3. -1. будет где-то около нуля.

С какого перепугу будет -1 ?

В ответ на:

В ответ на: Даже больше того, (1/3)*3 - 1 = -1 . А вот (1./3.)*3. -1. будет где-то около нуля.

С какого перепугу будет -1 ?

Числа заданы без десятичной точки, следовательно, подразумеваются целочисленные вычисления. В этом случае 1/3=0, а дальше -- понятно. Такая логика во всех мне известных языках программирования.

А, нуда, затупил сутра .)

Значит Вам не так много языков известно. Целочисленное деление 1/3 в PHP например дает float 0.3333

The division operator ("/") returns a float value unless the two operands are integers

Собственно, ваш пост о том же: вычмлительные методы в компьютерах требуют грамотного использования. И только.

Да, с PHP не связывался. Но, учитывая такое его поведение, и не хочу
А по теме -- совершенно согласен. Если примененный вычислительный метод дает большую погрешность, значит, пользователь просто не знает, в какой ситуации какой метод нужно использовать.

В ответ на: К примеру, в линейной алгебре. Из-за этого на компьютере нифига не работает метод Гаусса, метод определителей (Крамера) и еще дофига разных теоретически безупречных матметодов. Проблема философская, математика хороша, но, падло, с реальностью совпадает не всегда.

Офигенное заявление. Особенно приплетение философии - это ваще 5.
Вы расскажите это тем, кто этими методами таки решает уравнения на компьютерах, а то они не в курсе, болезные, не ведают чего творят.
Ну и с вычислительной математикой познакомьтесь хоть немного: чего там и в каком порядке рекомендуют скрадывать/умножать, хотя бы в инженерном объеме познакомьтесь. Причем проработано досконально, и написано подробно в учебниках годов так 50..60-х прошлого века. Нынче, похоже, забылось, "за давностью"...

А то пока что вы, извините, несете ересь.

PS
Еще раз убедился, что философию начинают приплетать там, где не имеют фактических знаний. Это уместно на острие науки, на границе непознанного, но для давно известного человечеству - сие есть ламерство, без обид. Впрочем, граница познанного - у каждого своя, так что вам есть куда стремиться, удачи.

В ответ на: Значит Вам не так много языков известно. Целочисленное деление 1/3 в PHP например дает float 0.3333

Языки тут ни при чем. Если в результате операции деления получается значение с плавающей точкой - это уже никак не называется "целочисленным делением". Так что не надо обманывать и тасовать термины )

В ответ на: Языки тут ни при чем.

Эта, давайте всеже отличать статическую и динамическую типизацию языков. Деление то целочисленное (делим int на int), а тип переменной определяется полученным результатом (float), от такой фокус ,)

В ответ на: Эта, давайте всеже отличать статическую и динамическую типизацию языков. Деление то целочисленное (делим int на int), а тип переменной определяется полученным результатом (float), от такой фокус ,)

Тип переменной, куда будет помещен результат, вообще ни при чем. Это отдельный разговор.
Давайте ограничимся типом результата выражения.
В данном случае PHP (приведена была цитата) нам явно говорит, что операция обозначаемая "/" будет выполняться как деление чисел с плавающей точкой не зависимо от типа ее аргументов. Все.

В других языках правила интерпретации операции "/" другие, конечно.
(получается, зависит от языка? а чего я сказать-то тогда хотел? хм..)

Чего уж так сразу и "обманывать"? Я для чего цитату привел...

Целочисленное деление - это деление целых чисел, математический термин... какая нафиг разница как оператор пишется.

Но мы ведь видим, что приведенный язык PHP выполняет вовсе не целочисленное деление, верно? на и в приведенной цитате слова "целочисленное" - не наблюдается.

В ответ на: Целочисленное деление - это деление целых чисел, математический термин... какая нафиг разница как оператор пишется.

В моем понимании (в моём, как на самом деле - не знаю), целочисленное деление - это деление не просто целых чисел, но и вычисление результата только до целого числа (с отбрасыванием дробной части), вне зависимости от типа возвращаемой переменной. Как видим, PHP делает не так, потому и называю указанную в нем операцию - не целочисленным делением.

Э-э-э, позвольте! А как же "полиморфизм" в ООП? У операции есть операнды и результат... делим целое число на целое... и хто Вам сказал, что результат не строка в кодировке "мумба-юмба"?

... но тем не менее, перекрыта какая операция? Угу. Целочисленное деление.

В ответ на: делим целое число на целое... и хто Вам сказал, что результат не строка в кодировке "мумба-юмба"?

Документация в данном случае дает однозначный ответ относительно типа результата.