Windows vs Linux - Как десктоп , и игровая станция.

Цитата Smike @ 26.09.07, 19:21

А можно пример такого документа? Мне и самому было бы интересно попробовать

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

Цитата Cartilage @ 26.09.07, 19:36

А я попробовал:

Это точно результат операции с плавающей точкой? Что-то меня одолевают сомнения.

Cartilage,

dvk@dvk ~ $ python
Python 2.5.1 (r251:54863, Sep  7 2007, 23:27:33)
[GCC 4.2.0 (Gentoo 4.2.0 p1.4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> print "%.30f"%(1.0/2+1.0/3-5.0/6)
-0.000000000000000111022302462516
>>> print (1.0/2+1.0/3-5.0/6)
-1.11022302463e-16

Добавлено 26.09.07, 19:42

Цитата Cartilage @ 26.09.07, 19:36

1/2+1/3-5/6

Это ведь целочисленная арифметика

Сообщение отредактировано: mo3r - 26.09.07, 19:43

Цитата Smike @ 26.09.07, 19:29

Не беспокойтесь, у AMD она сделана по тому же образу и подобию

Думается мне, что кто-то кого-то где-то не так понял. Глюки в реализации вычислений с плавающей точкой у intel очень маловероятны (сейчас бы полмира на ушах стояло); даже если бы они были, то были бы пофиксены компиляторами. Скорее всего, члены офисного девелопмент-тима открыли для себя старую как мир истину - плавающая точка не годится для точных рассчётов.

Цитата wind @ 26.09.07, 19:45

Скорее всего, члены офисного девелопмент-тима открыли для себя старую как мир истину - плавающая точка не годится для точных рассчётов.

Ничего себе «точные рассчеты»: погрешность под 80%! Это они открыли какой-то революционный алгоритм округления. Назовем его алгоритмом Баллмера-Гейтца

Добавлено 26.09.07, 22:05

Цитата mo3r @ 26.09.07, 19:41

Это ведь целочисленная арифметика

Как обычно, Lisp победил всех:

(format t "~a~%" (- (+ (/ 1 2) (/ 1 3)) (/ 5 6)))
0

Ессно это потому что он умеет обращаться с рациональными числами

Цитата linuxfan @ 26.09.07, 22:03

Как обычно, Lisp победил всех:

Цитата wind @ 26.09.07, 19:38

Это точно результат операции с плавающей точкой?

Цитата Smike @ 26.09.07, 14:41

Ну я не думаю, что на 2007-ой так быстро перешли. А в предыдущих версиях этой ошибки НЕТ! Да и катастрофы мне кажется быть не должно, лично мне не приходит в голову, в каких случаях ROUND следует использовать напрямую в книге. В остальных же случаях ошибка или не проявится в общих суммах или легко заметится, как вероятно и случилось.

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

Цитата Smike @ 26.09.07, 14:41

Ну и в третьих, наши-то бухгалтера на калькуляторах считают, а иксель только как таблицу используют

Не знаю, как ваши, а у нас с ветки давно слезлию

Цитата Smike @ 26.09.07, 14:41

Не факт, что там нет чего похуже

Не факт что есть.

Цитата Smike @ 26.09.07, 14:41

Его ведь вообще толком никто не тестирует, и пользователей у него мало.

Эксель тестируют, резултат на лице.

Цитата Smike @ 26.09.07, 14:41

А ты не думаешь, что цифра ровно 100000 вызовет сомнения?

А ты думаешь вызовет? Вбиваются данные на одном листе, считаются на другом, важно сумма - вот тебе и ошибка. Или надо глазами проглядывать столбик из 1000 чисел на предмет поиска "подозрительных"? Ты, случаем, когда на калькуляторе счиаешь не проверяешь его? На счетах там, или столбиком?

Цитата Харрисон @ 26.09.07, 18:17

А европейцев - НЕТ. Не подходят. Для установленных задач при установленных ресурсах.

Для быдлокодерства, иными словами.

Цитата mo3r @ 26.09.07, 19:41

Это ведь целочисленная арифметика

Сорри, это я затупил. Пол-дня перед этим с Maxima игрался и вот результат на лице

Цитата linuxfan @ 26.09.07, 22:03

Как обычно, Lisp победил всех:
(format t "~a~%" (- (+ (/ 1 2) (/ 1 3)) (/ 5 6)))
0

Ессно это потому что он умеет обращаться с рациональными числами

Именно так Причем с рациональным числами бесконечной точности. Если бы эксель писался на лиспе, таких багов в нем принципе бы не было.
Кстати, так лучше смотрится:

(format t "~a~%" (+ 1/2 1/3 -5/6))
0

Добавлено 27.09.07, 07:14

Цитата wind @ 26.09.07, 22:07

Это точно результат операции с плавающей точкой?

Возникает вопрос, а нафига использовать плавточку, если можно посчитать все точно? Плавточку ведь не от счастливой жизни придумали.

Цитата wind @ 26.09.07, 22:07

Это точно результат операции с плавающей точкой?

Конечно нет, я же написал: это были рациональные числа.
А вот плавающая точка:

(format t "~e~%" (- (+ (/ 1. 2.) (/ 1. 3.)) (/ 5. 6.)))
0.0E+0

Да, Lisp еще относится к тем языкам, в которые нативно встроена поддержка больших целых чисел (bignum).

А на хаскеле с его ленивыми вычислениями можно организовать вычисления в плавточке с какой угодно точностью результата

Цитата Астарот @ 27.09.07, 06:18

Извини, а в написанных тобой приложениях когда ошибка всплывает ты ее правишь, или оправдываешь?

Я правлю, а оправдывают менеджеры

Цитата Астарот @ 27.09.07, 06:18

Не знаю, как ваши, а у нас с ветки давно слезлию

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

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

Кстати, не экселем единым, есть ведь еще 1С.

Цитата Астарот @ 27.09.07, 06:18

Эксель тестируют, резултат на лице.

Сколько существует чисел с плавающей точкой? В блоге одного из разработчиков Mathematica была цифра и имела порядка 18 нулей. Как прикажешь вылавливать ошибки в таких числах? Я уже говорил, что тот кто делал эту функцию мог бы конечно обратить внимание тестеров на диапазон чисел, с которыми могли возникнуть ошибки (а суть возникновения ошибки именно в диапазоне unsigned short наводит на некоторые мысли ). Кстати, проверить чтоли на long и unsigned long?

Цитата mo3r @ 27.09.07, 07:12

Возникает вопрос, а нафига использовать плавточку, если можно посчитать все точно? Плавточку ведь не от счастливой жизни придумали.

Еще раз снимаю шляпу перед гениальностью разработчиков Delphi. Они сделали специальный тип Currency, который на самом деле целый, но выводится как число с 2 знаками после запятой Идеальное и абсолютно точное решение для денежных рассчетов.

Добавлено 27.09.07, 11:13
Кстати, я как человек с геодезическим образованием могу тебе рассказать одно правило: любое значение рассчетов должно быть получено как минимум двумя разными способами. Если бы это правило не выполнялось, мы жили бы не в домах, а в груде камней от их падения

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

Цитата Smike @ 27.09.07, 11:11

Даже "продвинутые", которые делают отчеты в Экселе, проверяют их по десять раз на калькуляторе.

То есть, он настолько не надежен?

Цитата Smike @ 27.09.07, 11:11

Как прикажешь вылавливать ошибки в таких числах?

Есть методы.

Цитата Smike @ 27.09.07, 11:11

Еще раз снимаю шляпу перед гениальностью разработчиков Delphi. Они сделали специальный тип Currency, который на самом деле целый, но выводится как число с 2 знаками после запятой Идеальное и абсолютно точное решение для денежных рассчетов.

Это не их гениальность. Это везде используется.

Цитата Smike @ 27.09.07, 11:11

Я правлю, а оправдывают менеджеры

Скорее они отмазываются. И ошибку ты-таки исправляешь. И, скорее всего, тебе дают по яйкам за то, что ты привнес (а у нас именно привнесение) ошибку в рабочий функционал. И правильно, что дают!

Цитата Smike @ 27.09.07, 11:11

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

А ты думаешь нет? Не стоит все гос. органы считать сборищем старушек, это раз. Не стоит считать, что эксель юзается только там, это два.

Цитата Smike @ 27.09.07, 11:11

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

Как раз эито от ненадежности экселя. До первого необъяснимого косяка тетечки проверяют по десять раз только исходные цифры, но не результат.

Цитата Smike @ 27.09.07, 11:11

Кстати, не экселем единым, есть ведь еще 1С.

Ой, лучше не вспоминай.

Цитата Smike @ 27.09.07, 11:11

Как прикажешь вылавливать ошибки в таких числах?

Я - никак. Потому что не знаю. Но это не повод.

Цитата Smike @ 27.09.07, 11:11

Еще раз снимаю шляпу перед гениальностью разработчиков Delphi. Они сделали специальный тип Currency, который на самом деле целый, но выводится как число с 2 знаками после запятой Идеальное и абсолютно точное решение для денежных рассчетов.

А сложный процент ты тооже будешь считать с точностью до двух знаков? Таки в финансах надо использовать как минимум шесть знаков после запятой, а клиенту сообщать только от двух. Копейка рубль бережет-с