Question

Dans notre application, nous vivons actuellement avec l'héritage d'une décision de stocker toutes les données d'ingénierie dans notre base de données dans SI.

Je crains que nous ne courions le risque de ne pas disposer de suffisamment de précision et d'exactitude dans notre base de données ou dans les types numériques .NET. Je crains également que nous ne puissions voir des artefacts de maths à virgule flottante (même s’il s’agit probablement d’une question à part entière).

Par exemple, les données source peuvent avoir été une quantité de pression exprimée (et extraite d’un service tiers) en psi (livres par pouce carré). Les ingénieurs auront choisi cette unité de mesure car (pour la quantité exprimée), elle aura tendance à donner des nombres faciles à digérer, lisibles par l'homme, sans exiger de notation scientifique.

Lorsque nous "normalisons" le nombre, c'est-à-dire que nous convertissons cette quantité pour notre propre persistance, nous pouvons le convertir en Pa (Pascals), ce qui nécessitera soit de multiplier ou de diviser le nombre par un autre nombre potentiellement important.

Nous finissons souvent par stocker des nombres très grands ou très petits et, pire encore, nous pouvons effectuer des calculs supplémentaires sur ces chiffres.

Nous utilisons actuellement ORACLE float et System.Double.

Qu'est-ce que les gens en pensent?

MISE À JOUR

D'autres recherches ont mis au jour Unités de mesure prises en charge dans le prochain langage F # (au format CTP au moment où j'écris).

Il semble que F # puisse comprendre les entrées utilisateur telles que:

9.81<n/s^2> // an acceleration

Nous serons également en mesure de créer nos propres unités dérivées et systèmes d'unités.

 créant une unité dérivée pour les newtons en F #
(source: msdn.com ) / sous>

Était-ce utile?

La solution

Gardez des chiffres significatifs à l'esprit - la précision de la mesure. Si l’on sait que le PSI ne contient que des livres entières, il ne reste plus qu’un chiffre significatif après conversion en Pa. Il y a 15 décimales.

La précision est différente de la précision, et les opérations en virgule flottante sur les unités d’ingénierie doivent en tenir compte au cours des opérations - ne stockez pas plus de précision que la précision de la mesure, n’utilisez pas plus de précision dans un calcul que est connue.

Modifier:

Vous pouvez également envisager d'utiliser NUMERIC(p,s) les domaines où précision (nombre de chiffres) et échelle (nombre de chiffres à droite de la décimale) peuvent être explicitement spécifiés.

Si ce n'est pas une option, envisagez de conserver l'exactitude d'une mesure particulière afin qu'elle puisse être rapportée et / ou utilisée dans des calculs.

Autres conseils

Je pense que tant que vous êtes en mesure de stocker exactement la même précision que vous en avez réellement, vous n'avez aucune raison de vous inquiéter.

En utilisant l'exemple que vous avez donné de convertir PSI en pascals (1 PSI = 6 894,75 pa), si je mesure 14,7 PSI et que je le convertis en pascals, je reçois 101 352,825. C'est trop de précision. Vous devez enregistrer 101 000 pour refléter la précision réelle de la mesure , et non le calcul .

N'oubliez pas que tous les chiffres que vous utilisez pour effectuer la conversion doivent être au moins aussi précis que vos mesures afin de ne pas perdre en précision lors de la conversion. Il est préférable d’avoir plus de chiffres de précision (au moins un de plus) dans vos facteurs de conversion que dans vos mesures.

Je pense que les données d'ingénierie ne sont généralement pas assez précises pour vous inquiéter de la différence. Vous connaissez l'expression de l'ingénieur & "Mesurer avec un micromètre, la marquer avec une craie, couper avec une hache &"; ça résume à peu près. S'inquiéter de la différence entre 8 chiffres significatifs ou 12 dans un calcul sur quelque chose qui est construit dans le monde réel à 2 chiffres significatifs, la tolérance n'a tout simplement aucun sens.

Pour éviter toute perte de précision due à la conversion d’unités, vous pouvez stocker toutes les données provenant de la mesure dans l’unité dans laquelle elles ont été mesurées. Bien sûr, cela signifie que vous pouvez vous retrouver avec certaines valeurs de pression stockées en Pa, d’autres en psi, ou même en mmHg. Vous devez décider vous-même si cela pose plus de problèmes qu'il n'en résout.

Et je suis d’accord avec les autres réponses: dans la plupart des cas, la précision offerte par un float Oracle est bien supérieure à la précision de la mesure elle-même.

Eh bien, cela dépend de la précision avec laquelle vous voulez être. N'oubliez pas qu'en matière d'ingénierie, il ne suffit pas de stocker le nombre 3.20, car 3.2 n'est pas la même chose que 3.20 en matière d'ingénierie. 3.20 implique une précision supérieure à 3.2, qui peut être 3.15 & Lt; = x & Lt; 3,25 .

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top