Excel по сравнению с различиями в числе C#

Кто-либо может пролить свет на то, почему я мог бы видеть очень маленький (10^-08) различия в числе при использовании точно тех же чисел в Excel по сравнению с C#??

Я имею формулу и использую те же исходные данные. В Excel я получаю одно число - В C#, я получаю другого. Различие является крошечным.

Я использую, удваивается в C# и выполнении подразделения. Я попытался использовать десятичные числа, которые не имели большую часть значения

Править: Это сводит с ума меня - меня ahve, потраченный все утро на это - Какие-либо идеи??

6
задан Jack Kada 11 February 2010 в 13:28
поделиться

4 ответа

При таких небольших значениях разницы (10^-08, как вы заявляете) я подозреваю, что проблему вызывают промежуточные вычисления. Обратите внимание, что значения двойной точности 64-битные, но регистры могут работать с точностью 80 бит. Поэтому, если у вас есть последовательность кода, в которой компилятор будет хранить все промежуточные вычисления в регистрах, вы получите лучшую точность, чем если бы те же вычисления производились в разных местах кода, заставляя промежуточные результаты храниться в 64-битных местах хранения.

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

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

-- Майк

3
ответ дан 17 December 2019 в 04:46
поделиться

Разница заключается в разных правилах округления MidPoint в C # и Excel.

Попробуйте Math.Round (someNumber, precision, MidpointRounding.AwayFromZero);

2
ответ дан 17 December 2019 в 04:46
поделиться

Вы уверены, что видите все число в Excel?

Числа, отформатированные как "Общие", будут отображаться с точностью ~12 цифр (или меньше, если ширина столбца недостаточна для ~12 цифр). Например, если вы поместите формулу "=PI()" в ячейку с форматом "General" (по умолчанию в Excel) и сделаете столбец достаточно широким, вы увидите 3,141592654. Обратите внимание, что если столбец будет недостаточно широким, вы увидите еще меньше цифр точности.

Теперь отформатируйте эту ячейку с помощью пользовательского формата числа "0.000000000000000000000" и вы увидите 3.14159265358979000 (если столбец достаточно широкий).

Обратите внимание, что Excel на самом деле хранит значение =PI() с точностью более 15 знаков. Вы можете убедиться в этом, введя в ячейку "=(PI()-3.14159265358979)" - не забудьте включить в формулу круглые скобки.

Теперь, ради интереса, введите в ячейку "=PI()-3.14159265358979" и вы увидите, что получите ноль. В некоторых случаях, например, при сложении или вычитании, когда результат равен "почти нулю", Excel фактически преобразует результат в 0,0 (это может свести вас с ума, если вы не знаете, что это происходит).

0
ответ дан 17 December 2019 в 04:46
поделиться

Эта тема и раньше меня сводила с ума =).

Несколько лет назад я обнаружил, что функция Excel = ОКРУГЛ () дает другие результаты, чем функция VBA ОКРУГЛ () . Я также обнаружил, что VBA и MySQL версии 4.x (не могу вспомнить точную версию; до 5.x) использовали один и тот же алгоритм для округления типов чисел с плавающей запятой. Похоже, они использовали ошибочную версию «банковского округления». MySQL в конечном итоге изменил округление в будущих версиях, но кто-то указал, что сходство между способом, которым VBA и MySQL 4.x реализовали ROUND , вероятно, было связано с тем, что они оба полагались на способ, которым язык программирования C ( вероятно использовался для создания VBA и MySQL) реализован Round.

И VBA, и MySQL 4.x просто реализовали то, что C использовал для реализации округления. Однако многие современные языки программирования по разным причинам решили использовать собственные методы округления; иногда это должно соответствовать спецификации IEEE, а иногда соответствовать тому, что, по их мнению, ожидает пользователь. В случае VBA и MySQL 4.x пользователь никогда не ожидал ошибочной версии банковского округления (отсюда и ваше разочарование), поэтому будущие языки внедрили новые версии округления или предоставили альтернативы (например, десятичное ] на C #), чтобы пользователь мог получать ожидаемые значения и иметь больший контроль над всем процессом.

Вы можете попробовать просмотреть эту статью для дальнейшего разъяснения этого вопроса в отношении округления VBA: http: //www.vb-helper.com / howto_round_to_specified_digits.html

0
ответ дан 17 December 2019 в 04:46
поделиться
Другие вопросы по тегам:

Похожие вопросы: