Из-за чего может быть такая неточность во float?

Есть таблица Sal, в ней столбцы: snum, sname, city, comm.
Поле 'comm' типа float, length=8, precision=53, scale=0.
В поле 'comm', запись перва я- число=0,15 запись вторая - число=0,1
В Query Analisere выполняю запрос: SELECT comm FROM Sal
Выдает:

comm
-------------------
0.14999999999999999
0.10000000000000001

(2 row(s) affected)

Почему не 0,15 и не 0,1 ?
Из-за чего это и как этого избежать ?

0

Это беда представления вещественного числа в машинном виде (фактически в виде 1.[мантиса]*e^[показатель], хотя может вместо 'e' должна стоять '2', сейчас не помню). Применяй тип numeric с указанием кол-ва позиций после десятичной точки.

Там можно задавать length, precision и scale.
Как, указав тип numeric, задать length, precision и scale, чтобы получился тип аналогичный float ?
В литературе я не нашел, что означает scale - что за масштаб ?
А length - длина всего числа ? до запятой ? после ?
И точтость (precision) - что за число.
Просвятите пожалуйста :-)

0

BOL
'Precision is the number of digits in a number. Scale is the number of digits to the right of the decimal point in a number. For example, the number 123.45 has a precision of 5 and a scale of 2.'

Теперь о float
Тот же BOL
'float and real
Approximate number data types for use with floating point numeric data. Floating point data is approximate; not all values in the data type range can be precisely represented.' Т.е. данный тип данных заранее предназначен для хранения приблизительных данных с заданной пользователем точностью (например, числа П или результата дроби 1/3)
Это первое.

Второе. Т.к. начальное значение 0.15 имеет 2 знака после запятой, то если полученное число 0.14999999999999999 округлить дл 2-х знаков, то получим теже 0.15 Дело здесь в том, что 0.15 воспринимается как decimal, а не float, поэтому происходит неявное преобразование типов. Поэтому и при извлечении данных нужно преобразовывать типы, но уже явно.

И третье. Тип float может содержать дл 15 знаков после запятой. А у данного числа 0.10000000000000001 'ошибка' в 17 знаке. так что это просто особенность QA

Резюме. Правильный совет вам дал VVK - используйте decimal или numeric. Ну или сами явно преобразовывайте данные одного типа в данные другого типа, иначе за вас это будет делать сервер.

0

Ок, пытаюсь использовать decimal = numeric.
Есть хранимая процедура, получающая такой параметр, и пишущая его в БД. Дальше вызываю эту процедуру из ASP через ADO.
Выставляю соответсвующий тип данных в ADO.
Получаю ошибку. Не хочет он передавать decimal в процедуру!
Видимо оттого, что VBS не понимает этот тип.
Как бороться?

0