Question

SymPy est un excellent outil pour convertir des unités en Python:

>>> from sympy.physics import units
>>> 12. * units.inch / units.m
0.304800000000000

Vous pouvez facilement rouler le vôtre:

>>> units.BTU = 1055.05585 * units.J
>>> units.BTU
1055.05585*m**2*kg/s**2

Cependant, je ne peux pas implémenter cela dans mon application à moins de pouvoir convertir les degrés C (absolus) en degrés K en degrés F en degrés R, ou toute combinaison de ces options.

Je pensais que quelque chose comme ça marcherait:

units.degC = <<somefunc of units.K>>

Mais clairement, c’est le mauvais chemin à prendre. Avez-vous des suggestions pour implémenter proprement des conversions d’unités de type "offset" dans SymPy?

Remarque: je suis disposé à essayer d'autres modules de conversion d'unités, mais je ne connais pas d'autre Unum et l'a trouvé lourd.

Éditer: OK, il est maintenant clair que ce que je veux faire est d’abord de déterminer si les deux quantités à comparer se trouvent dans le même système de coordonnées. (comme les unités de temps faisant référence à différentes époques ou différents fuseaux horaires ou dB à une amplitude linéaire), effectuez la transformation appropriée, puis effectuez la conversion. Existe-t-il des outils généraux de gestion du système de coordonnées? Ce serait génial.

Je pars du principe que & F & 176 & C se réfèrent toujours à & 917; & 176; F & # 916; & # 176; C au sein d'une expression, mais à l'absolu en position debout seul. Je me demandais simplement s’il existait un moyen de transformer units.degF en une fonction et d’enfiler un property () décorateur pour traiter ces deux conditions.

Mais pour l'instant, je vais définir unités.C == unités.K et essayer de le préciser dans la documentation pour utiliser les fonctions convertCtoK (...) et convertFtoR (...) lorsqu'il s'agit d'unités absolues. (Je plaisante. Non, je ne le ferai pas.)

Était-ce utile?

La solution

J'aime personnellement quantités grâce à son NumPy , cependant, il ne fait que des températures relatives et non absolues.

Autres conseils

La documentation d'Unum explique très bien pourquoi c'est difficile:

  

Unum est incapable de gérer de manière fiable les conversions entre ° Celsius et Kelvin. Le problème est appelé «problème de fausse origine»: le 0 ° C est défini à 273,15 K. Il s'agit en réalité d'un cas spécial et gênant, car en général, la valeur 0 n'est pas affectée par la conversion d'unités, par ex. 0 [m] = 0 [miles] = .... Ici, la conversion Kelvin / ° Celsius est caractérisée par un facteur 1 et un décalage de 273,15 K. Le décalage n’est pas réalisable dans la version actuelle d’Unum.

     

De plus, il ne sera vraisemblablement jamais intégré dans une future version car il existe également un problème conceptuel: le décalage doit être appliqué si la quantité représente une température absolue, mais pas si la quantité représente une différence de températures. Par exemple, une augmentation de la température de 1 ° Celsius équivaut à une augmentation de 1 K. Il est impossible de deviner ce que l'utilisateur a à l'esprit, qu'il s'agisse d'une température absolue ou relative. La question des quantités absolues par rapport aux quantités relatives n’a pas d’importance pour les autres unités car la réponse n’a pas d’incidence sur la règle de conversion. Unum est incapable de faire la distinction entre les deux cas.

Il est assez facile de voir conceptuellement les problèmes liés à la représentation symbolique de la conversion de température absolue. Avec toute unité relative normale, (x unité) * 2 == (x * 2) unité : le calcul des unités est commutatif. Avec les températures absolues, cela tombe en panne - il est difficile de faire quelque chose de plus complexe que des conversions de température simples sans autres dimensions unitaires. Vous feriez probablement mieux de conserver tous les calculs en kelvin et de convertir en unités de température uniquement les points d’entrée et de sortie de votre code.

Exemple, comment cela pourrait fonctionner:

>>> T(0*F) + 10*C
T(265.37222222222221*K) # or T(47767/180*K)
>>> T(0*F + 10*C)
T(283.15*K)
>>> 0*F + T(10*C)
T(283.15*K)
>>> 0*F + 10*C
10*K
>>> T(0*F) + T(10*C)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for +: 'absolute_temperature' and \
'absolute_temperature'
>>> T(0*F) - T(10*C)
T(245.37222222222223*K) # or T(44167/180*K)
>>> 0*F - 10*C
-10*K

Le package natu gère les unités de température. Par exemple, vous pouvez faire ceci:

>>> from natu.units import K, degC, degF
>>> T = 25*degC
>>> T/K
298.1500
>>> T/degF
77.0000
>>> 0*degC + 100*K
100.0 degC

Les préfixes sont également pris en charge:

>>> from natu.units import mdegC
>>> 100*mdegC/K
273.2500

natu gère également les unités non linéaires telles que décibel , pas seulement ceux avec des décalages tels que degré Celsius et degré Fahrenheit .

En ce qui concerne le premier exemple que vous avez donné, vous pouvez le faire:

>>> from natu import units
>>> 12*units.inch/units.m
0.3048

BTU est déjà intégré. Vous pouvez modifier son afficheur en m ** 2 * kg / s ** 2, mais par défaut, natu simplifie l'unité à J:

>>> from natu.units import BTU
>>> BTU.display = 'm2*kg/s2'
>>> 1*BTU
1055.05585262 J
Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top