Есть расчет очень сложного, циклического алгоритма. После каждой итерации данные (типа double) записываю в БД Access. Использую Visual Studio 2005 & C#. При отладке по шагам в Visual Studio числа имеют длину 20 знаков после запятой, а при записи в Access они укорачиваются до 18 знаков... В принципе такая точность мне и не нужна, я бы ограничился 15 знаками. Но нужно делать "расчет с продолжением", т.е. нужно открывать файл БД, ранее расчитанный, из него считываю 2 последние строчки и продолжаю вычисления, основываясь на этих данных... Так вот эти считанные данные (ранее сохраненные) отличаются на 2 последних знака после запятой, поэтому расчет например 100.000 без продолжения (за раз) отличается от расчета например сначала 50.000, потом еще 50.000. Сначала разница ничтожна, но потом сказывается "лавинный эффект" и при большом количестве итераций разница уже существенна...

Подскажите, пожалуйста, что мне лучше сделать? Обрезать числа после каждого вычисления? Какие еще варианты есть?

Заранее благодарен.

mrHunter, к сведению: для вопросов по ADO.NET есть специальный раздел.

Какой тип поля используется в Access?

Добавлено через 11 минут и 27 секунд
И еще.
Вот выдержка из MSDN:

Так что в отладчике Вы обсчитались.

Сейчас проверил. Отладчик показывается 17 знаков после запятой.
В MSDN и про это написано:

Но я точно проверял, в отладчике 20 цифр.... Это точно! В Access то все-равно числа обрезанные приходят. Тив в Accessе - двойное с плавающей точкой...

Так ведь можно использовать строки для хранения чисел. А вопше если нужна такая большая точность и не совсем критична производителность, я тут лучше использовать длиную арифметику. Кстати есть еще такой тип как decimal (128 бит кажись), незнаю есть ли он в Access.

20 цифр после запятой? Не верю!
Скрины в студию.


Тип double в Access соответствует типу double в .NET, и у него 15 цифр после запятой.

Это сообщение отредактировал(а) Idsa - 22.7.2008, 05:54

Вот скрин:



Да реально, 20 цифр блин...

А в Accesse тоже 18 цифр после запятой, а никак не 15...

mrHunter, может, Вы все-таки используете не double, а decimal?

decimal никогда не использовал. Только double. Использование decimal удвоит количество занятой памяти и снизит скорость работы...

Вариант конвертации double в строку перед записью в БД -- наверное снизит скорость работы существенно... Должно же быть решение с double...

Не может быть, не может быть... Какая-то фигня...

Вот пример простенький, когда в отладчике можно увидеть 20 знаков после запятой:

Попробуй округлять значения при помощи Math.Round. Тут можно указать количество цифр после запятой. Хотя это наверное не многим лучше работой со string.

Это сообщение отредактировал(а) Wanderer2019 - 22.7.2008, 12:34