Так это ж наверно, с учетом паразитарных

кстати, интересно, если в строке поиска задать =100nF, DxD найдет 100.0000011686nF - формально не должен, если только это не погрешности отображения на экране. Может быть кто-нибудь попробует?

Глюк конечно, как обойти:
в конфигурации на отображение поменять формат вывода вручную на %.3f (предлагаемые из списка %.f, %.10f, %.16f приводят к этой ерунде).
И перезапустить DxD.

В списке ошибка - там %f вместо %.f
Если поставите вручную %.f тоже получите искомый результат.

ошибка не просто в списке (хоть и в списке тоже) - неужели при увеличении количества знаков дробной части величина должна меняться - ведь в базе четко задано (например 0.0000001 а не 0.000000100000186). Или это "типа компиляторы кривые"?
И зачем там в списке вообще 10 знаков после запятой и тем более 16 знаков после запятой? Ну да ладно. Мелочи, но какие-то .. как в известном фильме "все это так непрофессионально..." (Мюллер, "17мгн. весны")

Это не компиляторы кривые - это реализация кривая. Они используют формат с плавающей запятой (float) для хранения значений. А теперь попробуйте представить 0.0000001 в двоичной системе - это бесконечная дробь (как 1/3 в десятичной системе), отсюда и получаем реальное значение, что хранится в базе равным 0.000000100000186. Возможно, со стороны пользователя это можно обойти если хранить значения как integer c единичным значением, соответствующим малой величине (например 1 мкОм, для резисторов)

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

исследуем дальше. Собственно все ясно. Скорее всего, представление value в DxD - плавающее с двойной точностью. А в sampleLib.mdb - плавающее с одинарной точностью. При изменении типа поля value в sampleLib.mbd на двойную точность все это и имеем.
Итог: при создании своей базы данных желательно использовать для value тип данных "двойное с плавающей точкой". Тогда артефакты исчезнут.

в этом случае дробная часть не отображается совсем (посмотрите, вместо 3.3uF отображается 3uF)

Согласен.

Вот, единственный человек, который наконец то разобрался в вопросе. Спасибо.

Сообщение отредактировал baken - Dec 24 2009, 07:07

Я извиняюсь, но можно для тех, кто на бронепоезде?
Если у меня microsoft sql server, то какой тип данных ставить? Перепробовал все, что можно, но в каждом варианте свои проблемы.
При этом с access-ом все хорошо.
Нужно, чтобы нормально отрабатывала функция automatic magnitude, и при этом хранимые числа были от 0,000000000000001 (1фемто) до "как можно больше".

А может, просто "string" - точность будет абсолютная до любого знака, и хранить можно номинал в любом виде, будь то он числовой, или в виде какого-то буквенно-цифрового кода.

можно, только поиск по "больше-меньше" работать не будет

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

Плюс еще вот что... Я например в номинале храню "разновидности" микросемы - например компонент TPS6220x, а номинал - TPS62207

Поиск по "больше-меньше" и по диапазону актуален, ибо база может использоваться не только разработчиками, но и логистами, бухгалтерами и т.п. Им может потребоваться создавать, например, запросы для оценки стоимости комплектующих и т.п.
Я лично, думаю, что в номинале нужно хранить номинал, т.е. основную характеристику компонента. У меня номиналы вообще хранятся под истинными названиями, например "Resistance" для резисторов. При аннотации в схему происхдоит замена его на VALUE.
Только вот проблема: как перевели базу на SQL SERVER, начали возникать описанные выше эффекты. Кто-нибудь использует такую же конфигурацию? Какие типы полей нужны для чисел?