Перейти к содержанию
    

Базы данных компонентов в Library Manager'е

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

какие-то совсем некрасивые погрешности округления value - совсем нехило DxD пересчитывает!! как обычно у индийских програмеров плоховато с устным счетом. Или у них value тоже в дюймах и при пересчете туда-сюда накапливается погрешность? Или в пинтах каких-нибудь?

 

Глюк конечно, как обойти:

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

И перезапустить DxD.

post-200-1261139979_thumb.png

post-200-1261139994_thumb.png

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Глюк конечно, как обойти:

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

И перезапустить DxD.

 

В списке ошибка - там %f вместо %.f

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

В списке ошибка - там %f вместо %.f

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

 

ошибка не просто в списке (хоть и в списке тоже) - неужели при увеличении количества знаков дробной части величина должна меняться - ведь в базе четко задано (например 0.0000001 а не 0.000000100000186). Или это "типа компиляторы кривые"?

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

 

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

 

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

Итог: при создании своей базы данных желательно использовать для value тип данных "двойное с плавающей точкой". Тогда артефакты исчезнут.

post-200-1261365285_thumb.png

post-200-1261365632_thumb.png

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

В списке ошибка - там %f вместо %.f

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

Согласен.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Итог: при создании своей базы данных желательно использовать для value тип данных "двойное с плавающей точкой". Тогда артефакты исчезнут.

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

 

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

Изменено пользователем baken

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Я извиняюсь, но можно для тех, кто на бронепоезде?

Если у меня microsoft sql server, то какой тип данных ставить? Перепробовал все, что можно, но в каждом варианте свои проблемы.

При этом с access-ом все хорошо.

Нужно, чтобы нормально отрабатывала функция automatic magnitude, и при этом хранимые числа были от 0,000000000000001 (1фемто) до "как можно больше".

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

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

Я лично, думаю, что в номинале нужно хранить номинал, т.е. основную характеристику компонента. У меня номиналы вообще хранятся под истинными названиями, например "Resistance" для резисторов. При аннотации в схему происхдоит замена его на VALUE.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...